Demo tool
Demo Kit
Replaying an eSIM purchase journey in real conditions, on a salesperson's phone.
- Thales
- Product Designer
- 8 months, from initial request to development handover
A demo tool where every feature that serves the seller threatens the credibility of the demo.
- The product: the purchase and activation journey for an eSIM profile, replayed end to end, real identity verification and download included, re-brandable before every meeting. Selected to represent my division at Best of Thales Design.
- The research: 6 salespeople interviewed then brought back to test, 10 guerrilla tests, one inversion of the purchase funnel.
- My role: Product Designer, sole designer, paired with one developer.
Nomad · fictional operator
The purchase journey on « Nomad », an invented operator
No real brand, client or interface appears here. The configuration screens reserved for salespeople can't be shown: they are rendered as diagrams, in the « Two more decisions » section.
Identity verification is cut from this recording. That component belongs to Thales and can't be published. It sits between the plan and the payment, at the position decided in « The key decision ».
The project
Sales teams sell eSIM solutions to telecom operators. To show what the product looked like, they had slides and screenshots. The prospect had to imagine the journey instead of seeing it.
The app replays it in real conditions, on the salesperson's own phone: choosing a destination, selecting a plan, verifying identity, paying, downloading a real eSIM profile. It re-brands to the prospect's colours before the meeting.
The subject wasn't the purchase journey, which already existed. It sat in a contradiction: two users looking at the same screen. The salesperson needs control — to skip steps when time is short, start from scratch between two meetings, change a price to match the prospect's catalogue. The prospect must see none of it. The moment they spot a reset button, they're no longer looking at a product, they're looking at a mockup.
My role
Product Designer, sole designer, paired with one developer.
Research and synthesis, a functional architecture diagram validated with the PM before the first mockups, screen and branding system design, prototype and testing, copy written with marketing, handover and follow-through to implementation.
The research
Six salespeople, one instruction: walk me through your last client meeting minute by minute, rather than describe the features you'd want.
What the field made visible appeared in no specification. They run several meetings in a day, so a full reset has to take seconds. They travel to competing operators, so the branding has to change before every meeting. Their speaking time varies from one client to the next, so long steps have to be skippable.
No feature in the seller layer comes from a hunch. Each answers an observed constraint, and that's what made it possible to settle scope with the PM: anything not tied to an observed need didn't make it into the first version.
6
salespeople interviewed upfront, then brought back to test the prototype: the same people at the entrance and the exit of the design process
The key decision
Verify identity, then take payment.
In the original journey, the user paid, then verified their identity. The same objection came back from the salespeople and from testing, phrased almost identically: paying without knowing whether verification will succeed is unsettling. The perceived risk is asymmetric — the money is gone while the service isn't guaranteed. On a product bought on the move, often just before departure, hesitation is enough to cause abandonment.
I swapped the two steps.
Key decision · inverting the purchase funnel
Click a step to see what it costs and what it returns.
Two journeys compared. Original journey, in order: destination, plan, payment, identity verification, profile download. Delivered journey, in order: destination, plan, identity verification, payment, profile download. The payment and identity verification steps have been swapped.
BeforeOriginal journey
AfterDelivered journey
Two steps swapped, nothing else: the same objection came back from all six salespeople and from guerrilla testing. Paying without knowing whether verification will succeed is unsettling.
Identity verification
The heaviest step in the journey. Placed before payment, it pushes drop-off further up the funnel, onto a user who hasn't yet invested anything.
What this call cost: the heaviest step in the journey now comes before payment, on a user who hasn't yet invested anything. Drop-off moves up the funnel. What it gained: nobody pays for a service they may not be able to activate, and the operator doesn't have to absorb a refund and a lost client afterwards.
Two more decisions
A control menu filed where the prospect won't go.
The control functions are grouped in a single screen, reachable from the app's settings under the label « Admin ». The pattern is the one internal tools use: no back door, but a location nothing announces in the purchase journey, and a label that means nothing to a prospect watching over the salesperson's shoulder.
The opposite choice existed: hide the entry point entirely behind a secret gesture. I ruled it out. A salesperson who can't find their reset in front of a client loses more than the concealment gains. Reliable access beats camouflage, and the residual risk is a technical label in a settings list.
The screen separates what gets prepared before the meeting (operator, colours, logo) from what gets adjusted during it (skip onboarding, skip identity verification) and from what is destructive — the reset, isolated at the bottom. The active operator and theme stay permanently visible: the worst case for this product is a salesperson opening a demo in the colours of the competitor they saw yesterday.
1 · Settings
2 · Sales menu
A neutral theme, designed to be replaced.
The dark theme belongs to no operator: it's the default base. The light theme is the demonstration of what the app becomes dressed in a client's colours. Every component had to survive a change of primary colour and logo without a single screen breaking, in layout or in contrast.
Only three variables are exposed: logo, primary colour, operator name. Below 4.5:1, labels sitting on the primary colour switch automatically to dark. The salesperson cannot produce a non-compliant screen.
3 · Branding
Results
What was validated
8 / 10
people downloaded and activated an eSIM profile unaided, in guerrilla testing with people new to eSIM
strangers, not the salespeople
6
salespeople interviewed upfront, then brought back to test the prototype: the same people at the entrance and the exit of the design process
Status.In development. The app isn't yet deployed to the sales teams: no real usage data to date.
What I take from it
Research maps users, not platforms. My six interviews described the sales role precisely, and said nothing about what the operating system imposes, nor what happens to the app once it has actually downloaded three profiles. Three of the product's most structural features — location permission, profile switching, the branding library — came out of the handover, raised by the developer.
This project moved, for me, the point at which technical reality enters design. It doesn't arrive at delivery: it belongs to the framing.