· 4 min
Telco UX Design for Scale
What a telecom purchase journey taught me about modular flows, shared architecture, and clarity at scale.
Telco is not one flow
At Vodafone, I worked on the Mi Vodafone app purchase experience for existing
customers. The brief sounded simple: help people discover, configure, and buy
products without leaving the app. In practice, the journey had to support new
lines, upgrades, portability, and accessory add-ons.
Each scenario had accumulated its own screens and assumptions. There was no shared
checkout, no common mental model, and no reliable way to know which steps were
required in each case. The user experienced this as inconsistency. The teams
experienced it as duplicated complexity.
The first lesson was straightforward: when many scenarios look similar, do not
design them as separate journeys. Find the structure they share.
Start with architecture, not screens
Before moving into detailed UI, I facilitated a flow-mapping session with the
Product Manager, Product Owner, Business Analyst, and Technical Leads. We used a
Lego-pieces approach in Miro: every screen became a composable module that could
be arranged into different sales scenarios.
A diagram can align people faster than a polished prototype. When every squad
can see how its part fits into the whole, conversations move from defending
existing screens to deciding which modules the system actually needs.
This was especially useful in a remote environment. The shared model gave product,
design, and engineering a common language before implementation began.
Make the system visible
A diagram can align people faster than a polished prototype. When every squad
can see how its part fits into the whole, conversations move from defending
existing screens to deciding which modules the system actually needs.
Modularity is not the same as adding options
A modular flow should not expose every possible choice to every customer. It should
adapt to the transaction while keeping the experience focused. The checkout had a
maximum of four steps, but some scenarios needed only one. The system expanded or
collapsed based on what was actually required.
That meant reusing customer data already on file, asking only for information that
mattered to the current purchase, and keeping price and progress visible while
configuring a plan. Modularity happened in the architecture. Clarity happened in
the interface.
Feedback matters more when the commitment is high
Testing with ten existing Vodafone customers revealed an important distinction.
People were not confused by the new navigation. They were uncertain because the
flow did not give enough feedback between steps.
That changed the priority. We focused on making progress, selections, and next
actions explicit before production code was written. In a telecom purchase, users
are configuring a plan, associating a number, or switching carrier. They need to
know what has happened, what remains, and whether they can still change their mind.
The redesigned experience reached more than 3M existing customers, increased
cross-sell conversion by 19%, and reduced purchase steps by 44%. The outcome was
not created by one clever screen. It came from removing uncertainty across the
full journey.
Clarity is a conversion tool
The redesigned experience reached more than 3M existing customers, increased
cross-sell conversion by 19%, and reduced purchase steps by 44%. The outcome was
not created by one clever screen. It came from removing uncertainty across the
full journey.
What telco taught me
A one-off flow can solve today’s requirement. A shared model gives future teams
somewhere sensible to put the next one.
Serving more scenarios does not mean showing more complexity. Good systems hide
irrelevant decisions and reveal only what the current context requires.
The most valuable artifact can be a shared map that helps teams make consistent
decisions long after the original designer leaves the room.
Design the rule before the exception
A one-off flow can solve today’s requirement. A shared model gives future teams
somewhere sensible to put the next one.
Scale requires restraint
Serving more scenarios does not mean showing more complexity. Good systems hide
irrelevant decisions and reveal only what the current context requires.
Alignment is a design deliverable
The most valuable artifact can be a shared map that helps teams make consistent
decisions long after the original designer leaves the room.