PRODUCTLens
A requirements document tells you what the system must do. It does not tell you what a person does. So I walked the agent's path myself, call by call, and drew that before anyone started building.
05 · VODAFONE UK · 2020–2023 · ROLE: LEAD UX DESIGNER
The screens Vodafone's support staff live in all day, made clearer and faster.
- Situation
- Vodafone agents answer customers inside Halo. Everything they need is on one screen, and it all shouts at once.
- Clarity
- I turned long requirement documents into screens agents could actually work in, using Vodafone's own design system.
- Shipped
- I designed the screens agents use all day, for things like accounts, billing, and trade-ins. After they went live, calls got about 20% faster.
Built forWeb
01 · The mess
A Vodafone agent has a customer waiting while the screen shows everything at once: the account, security checks, offers, billing, products, trade-ins, credit checks, delivery, the basket.
The requirement documents said what the system had to do. They did not say how a person should move through it.
That was my job, and it had to be done inside Vodafone's own design system, so it would still feel like their product and still work across every other journey the team was building.
- 01Dense Halo account state
- 02Business rules without clear interaction paths
- 03Established Bingo / EVO design constraints
- 04Multiple customer journeys in one workspace
- 05Every extra step increased AHT
02 · The work
Research
The design system was a fixed constraint, so the research went into the people rather than the interface: what agents actually do, in what order, while a customer waits.
- Watched recorded agent journeys, the real sequence, not the documented one
- Read the patterns and behaviours back against the existing design system
- Planned around easing the agent's interaction, on the theory that the customer feels it downstream
Iterations
My first proposal was to change the design system for the better. That is where I met the real constraint.
My first proposal
Adapt the design system to better principles
The system was old. Modernising it looked like the obvious move.
then the real constraint
What I had missed
Agents already knew this system. Moving it was the cost, not rebuilding it.
These are the screens support staff live in all day. Re-teaching a familiar interface would have cost the very thing the work existed to save.
What I did instead
Built the UX around the constraint
Harder than a redesign, and a better brief: reduce the friction without moving the furniture people navigate by.
Collaboration
This work sat between the business writing what it needed and four designers building it. Someone had to turn one into the other first.
Worked with
- Product manager
- The Halo team
- Developers
- 4 designers, led
From requirements to a sprint
01
Requirements arrive
Business requirements and rules, direction, not journeys
02
Broken down
What the UX actually has to do, and where the time is going
03
My own document
High-fidelity wireframes built against one target: reduce AHT
04
Presented for sign-off
To Vodafone's project owners and the Halo team, by me
05
Handed to the team
Split into UX the four designers could take into user stories
The middle three are the core UX work, the document says what the business needs, not what the screen should do. Someone has to turn one into the other before four designers can start.
03 · The big calls
SYSTEMSLens
Vodafone already had a design system, and agents already knew it. Inventing new patterns would have made them relearn their own job. So I built almost everything from parts they recognised, and only drew something new when the task truly needed it.
EXECUTIONLens
I set the direction and drew the first detailed screens myself. Then I split the rest across four designers, sprint by sprint. Doing the hard screens first meant everyone after me had something solid to follow.
04 · The build
FIG 05.1≈20% AHT REDUCTION
FIG 05.2
FIG 05.3
FIG 05.4
FIG 05.5
From requirements to a buildable flow
1
Business requirements
business rules & requirements, direction, not journeys
2
UX gap analysis
what the document doesn't answer for the agent
3
Flows & hi-fi wireframes
concrete paths, states and decision points
4
Sprint-ready delivery
split across a team of 4 designers
Everything inside the established design systemBingo → EVOExisting patterns firstNew states only when the task demands
FIG 05.6
The agent journey, before and after
Before9 steps · 4 open decisions
After5 steps · 1 decision, pre-answered states
≈20%lower average handling time, clearer decision points, fewer open questions mid-call (diagram illustrative; figure approximate, as reported)
Problem → part
- Business requirementsSprint-ready agent flow
- Dense Halo account stateModular Account Overview sections
- Customer security requirementsDPA / OTAC / ID verification states
- Trade-in business rulesStepper, basket, payment, and delivery flow
- Long handling pathClearer agent decision points
- Agent uncertaintyCalls about 20% shorter
05 · The facts
★ Ryan Soni
Case 05 · VODAFONE UK · 2020–2023
≈20%
AHT reduction
4
Designers led
2020–23
Timeline
- Client
- Vodafone UK. The system their own support staff use, not the one customers see
- Platform
- Halo
- Role
- Lead UX Designer
- Team
- I led four designers and worked directly with the product owners
- Design system
- Vodafone's own, called Bingo at the time and later renamed EVO
- What I made
- I read the requirements, found where they broke down for a real person, then drew the screens and flows
- Product areas
- Accounts and security, billing and payment, and the whole trade-in path from quote to delivery
· Outcome ·
Calls got about 20% shorter. Agents had fewer decisions to make and less hunting to do
The real Halo screens cannot be shown. Everything here is rebuilt, and every name and number on them is made up
06 · The takeaway
Inside a big company the hard part is never making a screen prettier. It is that people already know the old one. This is what I do about that.