Adiy Bin Yunus — Product Designer

Designing a faster service platform to replace legacy tools

Consolidating 10+ legacy tools into one platform for 22,000 agents handling 86 million customer contacts a year — and rebuilding the structural foundation to make it actually work at scale.

Role:

UX / Strategy

Year:

2022-2024

Context

From MVP validation to operational platform

The MVP proved the core workflows could live in one platform. The next phase was harder. Agents had spent years working across legacy tools they knew by muscle memory, in shops, call centres, and the field. Consolidation only worked if the new platform earned its place in their day, not just on the org chart.

Context

From MVP validation to operational platform

Scale

Deutsche Telekom handles 86 million support calls a year across Germany, served by 22,000 agents working across shops, call centers, and the field.

Scale

Deutsche Telekom handles 86 million support calls a year across Germany, served by 22,000 agents working across shops, call centers, and the field.

Friction

To resolve a single customer interaction, agents moved between 10 legacy tools. The systems were slow, fragmented, and couldn't be extended with anything new, including AI.

Friction

To resolve a single customer interaction, agents moved between 10 legacy tools. The systems were slow, fragmented, and couldn't be extended with anything new, including AI.

Goal

Bring every Telekom agent onto one platform. Take MagentaView from an MVP to a full 360° desktop covering every service and sales journey, starting in Germany and built to scale across Europe.

My role

End-to-end ownership of the platform's structural core

My role

End-to-end ownership of the platform's structural core

Dashboard Redesign

I led the dashboard redesign initiative — the effort that surfaced navigation as the platform's most critical structural problem. I drove the exploration, facilitated across designers to gather perspectives, and made the call on scope.

Mandatory dashboard detours

To get anywhere, agents had to return to the dashboard first. No direct path between sections. Agents looped Dashboard → Section → Back dozens of times in a single call.

Navigation Architecture

I owned navigation architecture end to end, from research through to shipped product. This meant holding the line against competing module priorities for nearly a year until it launched.

Two completely different environments

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

Customer Authentication

I owned authentication across both call centre and retail environments — two fundamentally different access models that had to live in a single interaction framework.

Two completely different environments

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

UX Consistency

I started the team's weekly UX pattern calls. What began as a way to catch inconsistencies became a team-driven practice. I personally defined patterns for navigation states, notification types, and dialog's.

Two completely different environments

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

Eight designers, no shared ground

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

Feature Work

Beyond the structural work, I designed across several customer-facing modules including document transfer, order overview, and agent-to-customer communication (email and SMS).

A tool agents didn't trust yet

Adoption was the real metric. If the platform slowed agents more than the old tools, consolidation would fail — regardless of how well individual features were designed.

Problem

More platform, more friction.

Problem

More platform, more friction.

Mandatory dashboard detours

To get anywhere, agents had to return to the dashboard first. No direct path between sections. Agents looped Dashboard → Section → Back dozens of times in a single call.

Mandatory dashboard detours

To get anywhere, agents had to return to the dashboard first. No direct path between sections. Agents looped Dashboard → Section → Back dozens of times in a single call.

Two completely different environments

Call centre agents can view customer data before authentication. Retail agents cannot. They are face to face with the customer. One platform had to handle both without building two separate products.

Two completely different environments

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

Eight designers, no shared ground

Call centre agents can view customer data before authentication. Retail agents cannot, they're face to face with the customer. One platform had to handle both without building two separate products.

A tool agents didn't trust yet

Adoption was the real metric. If the platform slowed agents more than the old tools, consolidation would fail, regardless of how well individual features were designed.

A tool agents didn't trust yet

Adoption was the real metric. If the platform slowed agents more than the old tools, consolidation would fail — regardless of how well individual features were designed.

Challenge

How do you build a tool that 22,000 agents choose to use, across environments and ability levels, when the foundation holding it together is nobody's problem?

Design principles

The filters behind every decision

These came directly from the research reframe. Not values to aspire to. Filters we used to reject directions that didn't hold up.

Design principles

The filters behind every decision

These came directly from the research reframe. Not values to aspire to. Filters we used to reject directions that didn't hold up.

Foundation before features

More functionality might have driven short-term adoption. A faster tool drives durable adoption. We chose task speed over feature breadth.

Evolve, don't replace

Agents had built habits around the MVP. Where patterns worked, we kept them. Rewiring muscle memory has a real cost.

Consistency over novelty

At scale, every one-off pattern is a future maintenance problem. We established patterns early so teams had something to build on, not re-solve.

Earn trust, then extend

Agents wouldn't trust a tool that slowed them every day. Speed of task resolution was the prerequisite to every other ambition the platform had.

Accessibility as design input

10% of the workforce uses assistive technologies. That wasn't a constraint handled at the end. It changed how the flows were structured from the start.

Growing Pains

What the old experience actually felt like.

The MVP moved core workflows onto one platform. But the structure hadn't caught up. Agents who knew exactly where they wanted to go still couldn't get there directly.

Growing Pains

What the old experience actually felt like.

The MVP moved core workflows onto one platform. But the structure hadn't caught up. Agents who knew exactly where they wanted to go still couldn't get there directly.

Old navigation — dashboard as mandatory waypoint

Getting anywhere meant going through the dashboard. Not by design. Because there was no other path.

Every unnecessary navigation loop happened in real time while a customer was on the line.

Retail agents had a different problem entirely. Same platform, completely incompatible data visibility requirements.

Agents working across modules had no stable mental model of how the platform would behave.

The insight

Agents weren't lost. The architecture was.

I spent time observing agents in both environments before redesigning anything. One quote from a call centre session changed how I saw the project.

The insight

Agents weren't lost. The architecture was.

I spent time observing agents in both environments before redesigning anything. One quote from a call centre session changed how I saw the project.

"I keep going back to the dashboard even when I know where I want to go."

Usability session participant

"I keep going back to the dashboard even when I know where I want to go."

Usability session participant

That one sentence reframed everything. The problem wasn't a UI that was hard to read. It was a UI built for the wrong job entirely.

We translated what we heard into Jobs To Be Done and scored each one across user value, business impact, and feasibility. It gave us a shared way to make decisions and a principled reason to say no to things that didn't serve the core need.

The insight

They weren't managing devices. They were checking for intruders.

That one sentence reframed everything. The problem wasn't a UI that was hard to read. It was a UI built for the wrong job entirely.

The Hard Call

A strategic disagreement with management

The organisational pressure was to ship more: sales journeys, new modules, more coverage. Management's argument was reasonable, more functionality would drive adoption faster.

We disagreed. Agents wouldn't trust a tool that slowed them every day.
Our case: fix the foundation first, make agents faster, and adoption would follow.

The Hard Call

A strategic disagreement with management

The organisational pressure was to ship more: sales journeys, new modules, more coverage. Management's argument was reasonable, more functionality would drive adoption faster.

We disagreed. Agents wouldn't trust a tool that slowed them every day.
Our case: fix the foundation first, make agents faster, and adoption would follow.

What we gave up

Several sales journeys were delayed to resource this work. That was a real cost, and management felt it. The bet was that usability improvements would drive more durable adoption than feature volume.

What it actually took to ship

The navigation shell was owned by the design system team. Every module team had to rebuild their secondary pages and wire into the new structure. Each team had their own roadmap and engineering constraints. Navigation isn't owned by any one team, which means everyone deprioritises it unless someone holds the line. We held the line. It took almost a year from decision to launch.

Introducing

Navigation

The dashboard became a starting point, not a mandatory waypoint. Persistent tabs gave agents direct access to every customer section. Modules built on this structure from day one.

Introducing

Navigation

The dashboard became a starting point, not a mandatory waypoint. Persistent tabs gave agents direct access to every customer section. Modules built on this structure from day one.

Direct access to every section from anywhere in the platform. No return trip to the dashboard required.

Every new module inherits the same structure. No one-off navigation to learn or maintain as the platform grows.

Task continuity holds across a full call. Agents stop losing their place mid-interaction.

Introducing

Authentication

Call centre and retail agents authenticate customers in completely different conditions. The work reflected that. One was an evolution. The other was a redesign from scratch.

Introducing

Authentication

Call centre and retail agents authenticate customers in completely different conditions. The work reflected that. One was an evolution. The other was a redesign from scratch.

In call centres, authentication was already working. The job here was to evolve it cleanly into the new navigation structure and add one meaningful capability: a post-authentication summary card. Once a customer is verified, agents can access a snapshot of the reason for the call, IVR data, and AI-collected context. Agents no longer spend the first minutes of every interaction re-establishing what they already should know.

The insight

In call centres, authentication was already working. The job here was to evolve it cleanly into the new navigation structure and add one meaningful capability: a post-authentication summary card. Once a customer is verified, agents can access a snapshot of the reason for the call, IVR data, and AI-collected context. Agents no longer spend the first minutes of every interaction re-establishing what they already should know.

Retail was a different problem. In a shop, agents work on tablets directly in front of the customer. Data stays hidden until the customer is verified. The old fallback options were SMS OTP and birthdate verification. Both assume the customer remembers something. Many of the customers who walk into a Telekom shop are older, not digitally active, and don't have their customer ID to hand. When OTP failed and the birthdate didn't match, the agent had nowhere to go.

Smart authentication solved that dead end. The customer doesn't need to remember anything. They hand over their German ID card.

Retail: Smart Authentication

The insight

In call centres, authentication was already working. The job here was to evolve it cleanly into the new navigation structure and add one meaningful capability: a post-authentication summary card. Once a customer is verified, agents can access a snapshot of the reason for the call, IVR data, and AI-collected context. Agents no longer spend the first minutes of every interaction re-establishing what they already should know.

Smart authentication solved that dead end. The customer doesn't need to remember anything. They hand over their German ID card.

Retail: Smart Authentication

Call centre agents now land on a summary card after authentication. Reason for call, IVR data, and AI-collected context, visible before the first question is asked.

In retail, a modal lets the agent choose the authentication method. Smart Authentication or SMS OTP, depending on what the customer has with them.

Introducing

Patterns

Eight designers, multiple engineering teams, no agreed foundation. Weekly alignment calls turned emerging inconsistencies into owned, documented patterns before they scaled.

Introducing

Patterns

Eight designers, multiple engineering teams, no agreed foundation. Weekly alignment calls turned emerging inconsistencies into owned, documented patterns before they scaled.

Navigation state behaviour, notification types, and authentication state feedback. Each defined, owned, and documented.

New modules build on what the team already solved. The same problem doesn't get re-solved six times.

Agents working across modules now encounter consistent feedback, regardless of which team built the module.

Real Constraints

Accessibility, compliance, and things that didn't ship cleanly

Approximately 10% of Telekom's call centre workforce relies on assistive technologies. This shaped structural decisions. The authentication flow is one example. For screen reader users, each step needed explicit state feedback and a clear focus path. Compliance wasn't retrofitted. It changed how the interaction was built.

Not everything shipped on time. Critical edge cases caught late, backend issues, and API performance problems caused delays after launch. Real costs of building at this scale. A reminder that design decisions don't exist in isolation from engineering constraints.

Real Constraints

Accessibility, compliance, and things that didn't ship cleanly

Measuring Success

What changed when agents trusted the tool.

We tracked what agents actually experienced: how long calls took, and whether the platform was earning enough trust to replace the tools they'd used for years.

Measuring Success

What changed when agents trusted the tool.

We tracked what agents actually experienced: how long calls took, and whether the platform was earning enough trust to replace the tools they'd used for years.

12.5%

Reduction in average call handling time

10.3k

Active users, up from 2.9k at MVP

37

Agent NPS up from 24, tracked post-launch

The NPS movement was the number that mattered most. It meant agents weren't just using the platform. They were choosing it.

Reflection

What two years on one project leaves behind.

Two years on one project leaves a mark. Some of what I take away is what I'd do differently. Some of it changed how I work for good. The four below are the ones I keep coming back to.

Reflection

What two years on one project leaves behind.

Two years on one project leaves a mark. Some of what I take away is what I'd do differently. Some of it changed how I work for good. The four below are the ones I keep coming back to.

Alignment is the work

Sales, service, product, engineering, and the design system team all had a different version of what "done" looked like. Translating between them took more of my time than the design work itself. At this scale, that's not overhead. It's the work.

Accessibility changed how I design.

The requirements sounded like a constraint at first. They turned out to be one of the most useful design forces on the project. Designing state and sequence for screen readers made those flows better for everyone. Hearing from agents with visual impairments that they could use the tool confidently is one of the things I'm most proud of from this project.

Patterns need an owner or they won't exist.

I defined the notification pattern mid-project, after the inconsistency had already shown up. If I were starting again, system-level patterns would be the first thing I worked on once we had a few modules to learn from, not the thing I caught up to.

I held back when I shouldn't have.

With a team this big, I defaulted to looking for consensus on decisions I could have made myself. Next time, I want to be clearer earlier about which calls are mine to own.