Internal Tools · 2020-2024
Retail X - Vodafone
End-to-end design of Vodafone's internal sales tool, used daily across ~500 stores: from a barely-built starting point, with the guided sale as its only premise, to a configurator that went from under 13% to 93% of sales.
Retail X — internal in-store sales tool
13%93%
of in-store sales went through the configurator
Internal product · ~500 stores · ~2,000–2,500 users · Daily use
Context
I worked as Senior Product Designer and the sole designer of Retail X. I coordinated occasionally with the company's design system team, which spanned the whole organization, when I needed a new component or an adaptation of an existing one, to keep consistency with the public website, the private area, and the app.
Client: Vodafone. Scope: ~500 stores, ~2,000–2,500 internal users, daily use, 4 years.
What I did
The entire product and design of Retail X, from fieldwork to definition and iteration.
What others brought
The design system team provided components; development built the tool and gave me the usage-monitoring data; business, PO, and PM were the stakeholders to align.
The Problem
When I joined the project, Retail X barely had anything built: limited development, no real design behind it, with the guided sale as its only premise. We were practically starting from scratch.
That guided sale was a linear, questionnaire-style flow: for a customer who only wanted a prepaid line, the tool kept asking things unrelated to that purchase, down to whether they had pets, to force cross-sell of every kind.
Reps were pressured to use it, because the guided sale was the tool's whole reason to exist: without it, the product had no purpose, the team lost its rationale, and the project was left hanging. The outcome was the opposite of the one intended: reps preferred to skip Retail X and go straight to the older system, cumbersome but direct, because they had usually already closed the sale talking to the customer and just needed to configure it quickly.
Put as a number: at the start of the project, under 13% of sales went through the tool, with what little was in production when I joined. The problem wasn't an interface to fix: it was building, from fieldwork, something that actually matched how they really sold.
Before · linear guided sale
Build the offer
Step 4 of 8
- Customer details
- Consumption profiling
- Home insurance
- Any pets?
Any pets at home?
YesNo
Unrelated to what the customer came in to buy
Rigid flow: even a prepaid line means walking through steps and questions that add nothing to that sale.
After · flexible configurator
Offer configurator
Add what you need, in any order
- Mobile plan+ Add
- Home fibre+ Add
- TV & content+ Add
- Device+ Add
- Device insurance+ Add
- Wearable+ Add
Offer in progress
Mobile planHome fibre
The order is set by the conversation with the customer, not the tool.
Free order: the rep builds the offer the way they actually sell.
Process
Fieldwork. I visited 3 stores, one of them Sol, among the busiest. I kept a continuous conversation going with reps throughout the project: the feedback was constant.
The same pattern across Spain. I gathered feedback from stores all over Spain (Madrid, Málaga, Seville, Asturias, Valencia…) to trace the common pattern. They all agreed on the same thing, which made clear the problem was structural and shared, beyond any one store or profile.
The hardest step: convincing leadership. Business, PO, PM, and development. The argument was uncomfortable: this couldn't be fixed with a visual facelift; whatever we did on top of what existed, usage wouldn't improve, because it wasn't what reps needed, and there was no middle ground. I backed it with a report and the testimonies of the agents I interviewed: why they didn't use it, what was missing, and what they needed for a tool that actually sped up their work.
The proposal. A sale adapted to how they really sell: in practice, an e-commerce-style configurator with all products, services, and devices laid out to build the offer fast.
Validate before building. Before committing development, I tested the model as a Figma prototype with several collaborating reps. The reception was good, but the change was so drastic compared to what they had that it slipped a few weeks: a lot of negotiation to show that the risk of staying on the current path, in losses, was greater than that of "starting over".
Monitoring as a compass. Development passed me usage data continuously. I used it to check with data whether the redesign was moving the needle.
Growing scope. Over the project, functions were migrated from the older system to speed up not just the sale but also line management, plan changes, and discount and device requests and renewals. We started from an MVP adapted to the real technical limitations and iterated whenever the project allowed.
Key Decisions
Propose a different direction instead of designing on top of what existed
With almost nothing built and the guided sale as the project's only premise, I proposed not following that path: replacing it as the core with a manual configurator, based on fieldwork. Trade-off: taking a different direction meant delaying the project and going against the premise it had been set up with, risking the team's own rationale. Continuing to add design on top of what was already defined would have been faster and safer. I chose to propose the change in direction because building on a premise that didn't work would only produce a better-dressed tool, not one people would actually use.
Design for how they really sell, over the ideal process
I made the manual configurator the primary use and kept the guided sale, revamped, as a second option for undecided customers helped by an inexperienced rep. Trade-off: I gave up the guided sale as the core, and the forced cross-sell business wanted, in exchange for real adoption. Keeping it as a secondary option was the compromise that stripped it of the prominence that made it useless, without losing its one valid use case.
Validate the drastic change with real users before developing
I tested the new model as a prototype with reps before committing a line of code. Trade-off: it added weeks of delay and negotiation, and it was tempting to go straight to building. But validating with real users was what gave me the ammunition to convince leadership and lower the risk of "starting over".
Start with an MVP within the limits, then iterate
I began with a v1 that accepted the real technical constraints, like managing the device catalog, and kept migrating functions and iterating. Trade-off: I accepted an incomplete first version instead of waiting for the ideal solution. In exchange, I delivered something usable early and improved it on real usage, which is what sustained the adoption curve.
