Adiy Bin Yunus — Product Designer

A redesign that turned passive visits into active engagement

5M+ users had access to a device management feature. Most weren't using it to manage their network — they were using it to check if someone had broken in. The interface gave them no help doing that.

Role:

UX / Strategy

Year:

2025

Context

A new way to understand your home network

Deutsche Telekom's OneApp is used by 5M+ broadband customers to manage their home network. The device section showed every connected device: phones, laptops, TVs, smart home gadgets. One of the most-visited screens in the app.

A new design system gave us the chance to rethink the experience from scratch. Not just how it looked, but what it was actually for.

Context

A new way to understand your home network

A new design system gave us the chance to rethink the experience from scratch. Not just how it looked, but what it was actually for.

Scale

One of the most-engaged screens in Telekom's app, used by millions of broadband customers each month.

Scale

One of the most-engaged screens in Telekom's app, used by millions of broadband customers each month.

Behavior

Customers were visiting the screen repeatedly and quickly. They were checking, not exploring.

Behavior

Customers were visiting the screen repeatedly and quickly. They were checking, not exploring.

Opportunity

A new Telekom design system gave us the chance to rethink the experience from the ground up

Opportunity

A new Telekom design system gave us the chance to rethink the experience from the ground up

Opportunity

A new Telekom design system gave us the chance to rethink the experience from the ground up

My role

End-to-end design ownership

I led the redesign from research and problem framing through to shipped product — owning the direction, the prioritisation decisions, and the final interaction design. I was embedded in a broader team of five product designers, one service designer, and one UX researcher.

The hardest part of my role wasn't producing designs. It was convincing stakeholders to stop solving for information completeness and start solving for user confidence. The JTBD scoring framework became the tool that made that argument stick.

My role

End-to-end design ownership

Problem

More data. Less understanding.

The interface had a straightforward problem: it was built for network admins, not for the people actually using it.

Problem

More data. Less understanding.

The interface had a straightforward problem: it was built for network admins, not for the people actually using it.

Wrong information surfaced

MAC addresses, IP addresses, signal strength. Technically accurate. Practically useless for most people.

Real use case ignored

People weren't visiting to manage devices. They were checking if someone unwanted had joined their network. The interface gave them no way to do that quickly.

No device identity

Everything showed up as a manufacturer string or a hardware ID. You couldn't tell your own phone from a stranger's.

Challenge

How might we help users instantly understand what's on their network and act confidently when something looks wrong?

Design principles

Five constraints that shaped 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

Five constraints that shaped 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.

Confidence over completeness

Users need to feel their network is safe. Not briefed on every technical detail.

Recognise before act

You can't take action on a device you can't identify. Recognition comes first.

Status at a glance

Is everything okay? That answer should be immediate. Not something you have to scroll to find.

Design for trust

The experience should provide enough context for users to make decisions confidently.

Build for what's next

Every foundational decision should open up future features, not create debt for them.

Growing Pains

The device list that wasn't working

The original interface was built around raw data. What it couldn't accommodate was the primary reason people were actually opening it.

Growing Pains

The device list that wasn't working

The original interface was built around raw data. What it couldn't accommodate was the primary reason people were actually opening it.

Connected device list without proper device identification and hierarchy

Device details before redesign

Device names defaulted to manufacturer strings or hardware IDs. Nothing a normal person would recognise.

Active and inactive devices looked identical. No way to spot something unusual at a glance.

New devices weren't called out. You had to remember what was there before to notice a change.

The insight

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

Sitting in usability sessions changed how I saw the project. People weren't browsing their device list. They were scanning it, anxiously, looking for something that shouldn't be there.

The insight

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

Sitting in usability sessions changed how I saw the project. People weren't browsing their device list. They were scanning it, anxiously, looking for something that shouldn't be there.

"I just want to know if anyone's on my network who shouldn't be."

Usability session participant

"I just want to know if anyone's on my network who shouldn't be."

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.

Introducing

Recognition

Device fingerprinting turned hardware IDs into real names and device types. For the first time, you could look at the list and actually know what you were looking at. New devices got a distinct visual callout so anything unfamiliar stood out without you having to hunt for it.

Introducing

Recognition

MAC addresses replaced with real device names and type icons people actually recognise.

The list is now readable at a glance. The scanning behaviour users had already developed finally works the way it should.

A network status summary answers the question users were actually asking before they even start scrolling.

Introducing

Trust

Active and inactive devices got distinct visual treatment. Status was visible at the row level, not something you had to tap into a detail page to find. Push notifications surfaced new connections as they happened, so people stopped having to remember to check.

Introducing

Trust

New devices get a visual badge so they're noticed immediately, without needing to remember what was there before.

Active and inactive states have different visual weight. Normal looks calm. Anomalies look different.

Notifications weren't in the original brief. I pushed for them because the usage pattern made the case: people were opening the app repeatedly to check if something had changed. That's a pull behaviour you can flip into a push. If the network tells you when something changes, you stop having to remember to check.

Introducing

Action

Rename, pause, schedule, restrict, remove. All of it moved into the list itself. You no longer had to navigate somewhere else to do something about what you were looking at.

Introducing

Action

Rename, pause, schedule, restrict, remove. All of it moved into the list itself. You no longer had to navigate somewhere else to do something about what you were looking at.

The detail page is now for depth. The list handles the common case without making you dig for it.

The "What if(s)"?

The direction didn't come easy. We ran multiple explorations before testing anything with users. Each one represented a different read on the same problem: what should a user see first, and how much control should be visible upfront.

The "What if(s)"?

[ Alternate directions ]

Measuring Success

More users, less effort, more trust

We measured across Customer Effort Score and monthly active users. The notification system drove most of the MAU growth. It brought people back when something happened, rather than waiting for them to remember to open the app.

Measuring Success

More users, less effort, more trust

4.5

CES — up from 3.6 at baseline

310k

MAU, up from avg of 256k

CES used task-based scoring. Users completed real scenarios before rating effort, so the 4.5 reflects how the redesign performed on actual jobs, not general satisfaction.

Takeaways

What I carry from this project

Takeaways

What I carry from this project

Dashboards can lie

The feature had strong usage numbers. Research told a different story. Data tells you a feature is being used. It won't tell you if the use is healthy. When something feels off, go watch people use it.

Dashboards can lie

Bring a framework to a feeling

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.

Bring a framework to a feeling

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.

The brief doesn't know what it needs

The most important shift in this project, the reframe from UI problem to wrong job entirely, wasn't in the brief. The work is staying open enough to catch it when it shows up.

The brief doesn't know what it needs

The most important shift in this project, the reframe from UI problem to wrong job entirely, wasn't in the brief. The work is staying open enough to catch it when it shows up.

The brief doesn't know what it needs

The most important shift in this project, the reframe from UI problem to wrong job entirely, wasn't in the brief. The work is staying open enough to catch it when it shows up.

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

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.

Next case study