Vodafone · TelecomLive3 min read

One purchase flow inside Mi Vodafone

Six squads had built separate checkouts while customers experienced one Vodafone journey. During lockdown, I led the journey design and alignment for a shared modular architecture.

Role: Senior Product Designer
Company: Vodafone Spain
Platform: iOS, Android & Web

App Store ↗Google Play ↗

Context

Six squad checkouts, one customer journey

I joined the TX Handsets squad within the Care Tribe of Mi Vodafone App as Spain entered COVID-19 lockdown. The brief asked for an in-app cross-selling and purchase flow with no store visits or redirects, plus an increase in average order value. We later received no average-order-value evidence, so I do not claim that outcome.

The existing purchase experience was six squad-specific implementations built for different sales scenarios. Customers did not see those ownership boundaries; they encountered one fragmented journey. I led journey design and cross-squad alignment, while each squad remained responsible for implementing its part within Vodafone's existing design system.

Mi Vodafone App home screen for existing customers, showing account overview, active plan summary, and entry points to device upgrades and add-ons — the starting surface for the cross-selling redesign — Existing customer home screen — starting point for cross-selling redesign.

The existing customer home screen inside Mi Vodafone, the starting point for the cross-selling experience we were tasked with redesigning.

Organizational chart showing the TX Handsets squad within the Care Tribe of Mi Vodafone App, with scope boundaries covering discovery, configuration, checkout, and post-purchase confirmation — TX Handsets squad scope within the Care Tribe.

TX Handsets squad scope within the Care Tribe. Our mandate was to own the full purchase journey from discovery to post-checkout confirmation.

Process

Alignment before pixels

Before any design work, I ran alignment sessions with the Product Manager, Product Owner, Business Analyst, and Technical Leads to surface constraints and map the problem space together. A team of that size with misaligned assumptions about scope is slow to move and expensive to correct later.

Facilitated a Miro session to map current and future flows using a modular "Lego pieces" approach, treating each screen as a composable module and giving every stakeholder a shared mental model of the new architecture before design began.
Built the first prototype in InVision, Vodafone's internal prototyping tool at the time, to test navigation logic before committing to visual design.
Ran remote user testing with 10 existing Vodafone customers via Lookback.io, mixed ages and genders, all active in-app purchasers. This small, remote sample identified usability issues but could not establish behavior across Vodafone's customer base.
Key insight from testing: users weren't confused by the new flow. They were confused by the lack of feedback between steps. We addressed this before a single line of production code was written.

Miro board showing full flow mapping using a 'Lego pieces' approach — each screen is a composable module arranged in horizontal lanes, giving stakeholders a shared mental model of the new cross-selling architecture — Miro flow mapping — each screen as a composable module.

Flow mapping session in Miro using a "Lego pieces" approach. Each screen treated as a composable module, giving stakeholders a clear mental model of the new architecture.

InVision clickable prototype screens showing early user testing flows — task-based navigation from product listing through configuration to checkout, tested remotely via Lookback.io with 10 existing Vodafone customers — First InVision prototype for remote user testing via Lookback.io.

First clickable prototype built in InVision for remote user testing via Lookback.io. Ten existing Vodafone customers helped identify flow and feedback issues before production; the sample was directional, not representative.

Design Goals

Six goals. Non-negotiable constraints.

Create a clear cross-selling entry point that works for intent-driven and passive discovery
Design a PLP → PDP flow that guides from browsing to configuration without dead ends
Build a flexible Nexus screen, a cross-selling hub between offer and checkout, that adapts to the customer's existing products
Unify checkout across every sales flow in the app. One architecture, not six.
Maximum 4 steps to purchase, minimum 1. No asking for data already on file.
Deliver entirely within Vodafone's existing design system, with no new components without justification

Solution

Two entry points. One unified checkout.

Dual Entry Points

Online Store for intent-driven browsing, and a Discover section serving personalized offers via banners, meeting customers wherever they are.

Online Store entry point within Mi Vodafone App — product listing page designed for scannability, showing device cards with pricing, availability badges, and quick-filter options for intent-driven browsing — Online Store entry point with intent-driven product listing.

Online Store entry point with intent-driven browsing and a product listing page (PLP) designed for scannability. Users land here when they already know they want to upgrade or add a product.

Nexus Screen

A cross-selling hub between the offer and checkout. Modular and customizable based on the customer's accumulated products and eligibility.

Nexus cross-selling screen placed between product detail and checkout — modular surface showing eligible upsells and complementary products adapted to the customer's existing plan and accumulated services — Nexus screen — configurable cross-selling hub between PDP and checkout.

The Nexus screen is a configurable cross-selling surface placed between the product detail page and checkout. Modules adapt based on the customer's existing products and eligible upsells, keeping the flow relevant without being intrusive.

Micro-flows

Configuration, association, and portability

After selecting a plan, customers needed to configure it by choosing a tariff, associating it to an existing number, or initiating a portability request from another carrier. These micro-flows had to feel lightweight without losing clarity.

Plan configuration micro-flow showing tariff selection and number association steps — each screen scoped to a single decision, with persistent pricing and progress indicators to reduce cognitive load — Plan configuration — tariff selection and number association.

Plan configuration flow. Users select their preferred tariff, then associate it to an existing line or request a new number. Each step is scoped to a single decision to reduce cognitive load.

Portability request micro-flow for customers switching from another carrier — linear sequence collecting ICCID, previous carrier details, and confirmation, designed to build confidence in the switch process — Portability micro-flow for carrier switching.

Portability micro-flow designed for customers switching from another carrier. Collects the minimum required data across a linear, reassuring sequence that builds confidence in the switch.

New Checkout

Maximum 4 steps. Minimum 1.

The unified checkout replaced a patchwork of flow-specific implementations across the app. A single architecture, adaptable by configuration, that handles any sales scenario: new line, upgrade, portability, or accessory add-on.

Unified checkout architecture showing the modular step sequence — steps expand or collapse based on transaction type (new line, upgrade, portability, accessory), never asking for data already on file — Unified checkout — shared architecture across all sales flows.

I led the shared checkout architecture and alignment across sales flows in Mi Vodafone. Squads implemented their respective scenarios; modular steps expand or collapse based on transaction requirements, avoiding requests for information already on file.

Challenges

Shared journey, distributed ownership

Challenge

Unifying checkout meant replacing six squad-specific implementations that had been built independently over years. Each squad owned their flow and had different assumptions about checkout behavior — different step counts, different data requirements, different error handling. Proposing a single shared architecture during full COVID-19 remote work meant coordinating across teams that had never aligned on a shared surface.

Tradeoff

We used a "Lego pieces" framework in Miro — treating each screen as a composable module — so every squad could see how their flow mapped to the shared architecture. This created a shared language before any code was written. Some squads lost flexibility they had before. The trade was predictability: one checkout that could be tested, measured, and improved as a single system rather than six independent ones.

Learning

A shared architecture did not create shared delivery ownership. Clear boundaries mattered: I led the end-to-end journey and alignment, while squads implemented and maintained their scenarios. Making that split explicit reduced the risk of presenting coordinated work as one designer's execution.

Results

Reported launch outcomes and evidence limits

Vodafone reported the conversion and step-count changes after launch. Mi Vodafone had 3M+ existing customers within reach of the redesigned experience; that figure does not mean all 3M used this flow. No average-order-value result was provided.

+19%

Reported cross-sell conversion change

−44%

Reported reduction in purchase steps

3M+

Existing customer base potentially reached

Reflection

The hardest part was designing one customer journey across six teams without pretending ownership had become centralized. I led the end-to-end model and alignment; squads made implementation decisions within their systems. Ten remote participants helped us catch usability problems, but that sample did not predict launch performance. I would now secure agreed measurement access—including average order value—before using a commercial goal in the brief as a design success criterion.