A unified security experience for Deutsche Telekom.
Every Telekom market sold security differently. Different products, different partners, different stories. We built one Security Hub to replace all of it. A single value proposition, one experience across markets, and an architecture that doesn't care which vendor powers it.
Role:
UX / Strategy
Year:
2025-2026
Context
Telekom sells security. Just not as one product.
Each Telekom market built its own security offering over the years. Different products. Different partners. Different stories told to customers. Poland sold one thing. Czech Republic sold another. Germany sold something else. None of it added up to a Telekom security experience.
The brief from the central team was to fix three things at once:
Context
Telekom sells security. Just not as one product.
Each Telekom market built its own security offering over the years. Different products. Different partners. Different stories told to customers. Poland sold one thing. Czech Republic sold another. Germany sold something else. None of it added up to a Telekom security experience.
The brief from the central team was to fix three things at once:
One value proposition
A single, clear story about what Telekom security is and why a customer should care, regardless of which country they live in.
One value proposition
A single, clear story about what Telekom security is and why a customer should care, regardless of which country they live in.
One experience across markets
Same Hub, same flows, same visual language for every customer. Local content where it matters. No more separate products per country.
One experience across markets
Same Hub, same flows, same visual language for every customer. Local content where it matters. No more separate products per country.
Vendor-agnostic by design
The experience shouldn't depend on which partner powers it underneath. Swap the vendor, the customer shouldn't notice.
Vendor-agnostic by design
The experience shouldn't depend on which partner powers it underneath. Swap the vendor, the customer shouldn't notice.
Vendor-agnostic by design
The experience shouldn't depend on which partner powers it underneath. Swap the vendor, the customer shouldn't notice.
A note on visuals. The Hub hasn't launched yet, so I'm not sharing the final designs publicly. Happy to walk through flows, decision rationale, and selected screens in an interview under NDA.
My role
Designing the system, not the screens
Product designer on the two-person central design team. I owned the Hub's state model across six customer segments, the activation and discovery journeys, the account-wide insights surface, and the modular content system.
My role
Designing the system, not the screens
Product designer on the two-person central design team. I owned the Hub's state model across six customer segments, the activation and discovery journeys, the account-wide insights surface, and the modular content system.
Business goals
What success looked like for the business
The Hub wasn't a brand exercise. It had four commercial goals baked into the brief, and every design decision had to defend itself against at least one of them.
Business goals
What success looked like for the business
The Hub wasn't a brand exercise. It had four commercial goals baked into the brief, and every design decision had to defend itself against at least one of them.
Grow ARPU.
Move customers from free baseline protection to paid add-ons. Identity monitoring, content filtering, scam call protection.
Grow ARPU.
Move customers from free baseline protection to paid add-ons. Identity monitoring, content filtering, scam call protection.
Lift the attach rate.
Get more existing Telekom customers, especially broadband, to take a security product alongside their core service.
Lift the attach rate.
Get more existing Telekom customers, especially broadband, to take a security product alongside their core service.
Reduce churn.
Customers who couldn't see their protection were cancelling it. Make the value visible. Keep them paying.
Reduce churn.
Customers who couldn't see their protection were cancelling it. Make the value visible. Keep them paying.
Reduce churn.
Customers who couldn't see their protection were cancelling it. Make the value visible. Keep them paying.
Problem
Four things were broken at once
The interface had a straightforward problem: it was built for network admins, not for the people actually using it.
Problem
Four things were broken at once
The interface had a straightforward problem: it was built for network admins, not for the people actually using it.
Many products. No proposition
Each market sold a different thing. A customer moving from one country to another would meet a new product, a new partner, a new value pitch. There was no Telekom story.
Sold as an add-on. Not an expectation
Security sat under "extras" in the app. Customers had to know to look for it. Most didn't.
Every market built its own version.
New features got rebuilt in each country, with each vendor. The cost of doing anything new multiplied across the footprint.New features got rebuilt in each country, with each vendor. The cost of doing anything new multiplied across the footprint.
Protection was invisible when it worked
The service blocks threats in the background. Customers paid for something they couldn't see. So they cancelled it.
Challenge
How do we make security a baseline part of the Telekom app — visible, trusted, the same everywhere — while staying flexible enough to swap vendors and scale to new markets?
The insight
Customers weren't asking for more security. They were asking for proof.
We ran research across three Telekom markets. The same thing kept coming up. Customers didn't need more features. They needed to see that what they were already paying for was doing something.
The insight
Customers weren't asking for more security. They were asking for proof.
We ran research across three Telekom markets. The same thing kept coming up. Customers didn't need more features. They needed to see that what they were already paying for was doing something.
"I want to know it's on. Not how it works."
Usability session participant
"I want to know it's on. Not how it works."
Usability session participant
That changed what the Hub had to be. Not a settings panel. A surface that made invisible protection visible, in plain language. Enough proof to build trust. Not so much it scared people.
The mental model shift we designed for: from "do I need to add security" to "I already have security, and I can see it working."
The insight
They weren't managing devices. They were checking for intruders.
That changed what the Hub had to be. Not a settings panel. A surface that made invisible protection visible, in plain language. Enough proof to build trust. Not so much it scared people.
The mental model shift we designed for: from "do I need to add security" to "I already have security, and I can see it working."
The bets
Four calls shaped the Hub
Each one had a sensible alternative we chose not to take. Naming the trade-offs out loud was how we got commercial and legal to commit.
The bets
Four calls shaped the Hub
Each one had a sensible alternative we chose not to take. Naming the trade-offs out loud was how we got commercial and legal to commit.
A default tile. Not a hidden add-on.
The Hub became a default surface for every customer, even pre-paid users with nothing active. Educational content and an upsell path lived inside it. The trade-off was screen real estate in an already-busy app. We took it because hiding security under "extras" was the reason nobody knew it was there.
A default tile. Not a hidden add-on.
The Hub became a default surface for every customer, even pre-paid users with nothing active. Educational content and an upsell path lived inside it. The trade-off was screen real estate in an already-busy app. We took it because hiding security under "extras" was the reason nobody knew it was there.
One model. Variable depth.
A pre-paid customer with no active service, a post-paid customer with one product, and a convergent customer with several services all needed the same Hub. We built a state model with six segment variants instead of separate products. More upfront work. Cheaper to scale to the next market.
One model. Variable depth.
A pre-paid customer with no active service, a post-paid customer with one product, and a convergent customer with several services all needed the same Hub. We built a state model with six segment variants instead of separate products. More upfront work. Cheaper to scale to the next market.
Vendor-agnostic by design.
The Hub had to work no matter which partner powered it underneath. We designed against a generic capability layer, not against any one vendor's features. Markets could plug in their existing partner, switch later, or run multiple. The customer experience stays the same.
Vendor-agnostic by design.
The Hub had to work no matter which partner powered it underneath. We designed against a generic capability layer, not against any one vendor's features. Markets could plug in their existing partner, switch later, or run multiple. The customer experience stays the same.
Proof before configuration.
The first screen showed what protection had done, not what it could do. Settings lived one layer deeper for users who wanted them. The alternative, a control-panel-first design, tested worse with caregivers and non-technical parents — the two groups that drive real adoption.
Proof before configuration.
The first screen showed what protection had done, not what it could do. Settings lived one layer deeper for users who wanted them. The alternative, a control-panel-first design, tested worse with caregivers and non-technical parents — the two groups that drive real adoption.
Proof before configuration.
The first screen showed what protection had done, not what it could do. Settings lived one layer deeper for users who wanted them. The alternative, a control-panel-first design, tested worse with caregivers and non-technical parents — the two groups that drive real adoption.
Takeaways
What I carry from this project
Takeaways
What I carry from this project
Multi-market products need a model. Not a layout.
Security is the cleanest example I've worked on of a product that fails when it works. The whole proposition was a bet on a behavioural shift: customers seeing protection, not just having it. Every design decision after the insight pointed at that one thing.
Multi-market products need a model. Not a layout.
Security is the cleanest example I've worked on of a product that fails when it works. The whole proposition was a bet on a behavioural shift: customers seeing protection, not just having it. Every design decision after the insight pointed at that one thing.
Make the invisible visible. Or it doesn't exist.
I knew early on what we should and shouldn't build. But intuition alone doesn't win alignment. The JTBD scoring framework gave everyone a shared way to decide. It made the argument stick.
Make the invisible visible. Or it doesn't exist.
I knew early on what we should and shouldn't build. But intuition alone doesn't win alignment. The JTBD scoring framework gave everyone a shared way to decide. It made the argument stick.
Design with the people who can say no.
Commercial. Legal. Go-to-market. Half the case study above is decisions that look like design but actually depended on someone in another function being willing to commit. I now find the people who can block me early, and design with them in the room.
Design with the people who can say no.
Commercial. Legal. Go-to-market. Half the case study above is decisions that look like design but actually depended on someone in another function being willing to commit. I now find the people who can block me early, and design with them in the room.
Final Notes
What this built toward
We solved device identification and network trust at the foundation on purpose. Without reliable names, a recognition layer, and a stable status model, anything built on top would have inherited the same confusion.
Final Notes
What this built toward
We solved device identification and network trust at the foundation on purpose. Without reliable names, a recognition layer, and a stable status model, anything built on top would have inherited the same confusion.
The fingerprinting model, the naming system, and the status architecture built here are what make household grouping, per-device scheduling, and parental controls possible next. We weren't just fixing a list. We were building the layer everything else connects to.