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 handoff
A demo tool where every feature that serves the seller threatens the demo's credibility.
- The product: the eSIM profile purchase and activation journey replayed end to end, real identity verification and download included, rebrandable before each meeting.
- The research: 6 salespeople interviewed, then brought back to test, 10 guerrilla tests, an inverted purchase funnel.
- My role: Product Designer, sole designer, paired with a developer.
Nomad · fictional operator
The purchase journey on « Nomad », an invented operator
No real brand, client or interface. The sales-only screens are shown as diagrams further down.
Identity verification is cut from the video, because this component belongs to Thales. It sits between the plan and the payment (see « The key decision »).
Two users, one screen
Sales teams sell eSIM solutions to telecom operators. To show the product, they had slides and screenshots: the prospect had to imagine the journey.
The app replays it in real conditions, on the salesperson's phone: destination, plan, identity verification, payment, download of a real eSIM profile. It rebrands to the prospect's colours before the meeting.
The purchase journey already existed. The real subject: two users look at the same screen. The salesperson needs control to skip steps, reset between meetings or match a price to the prospect's catalogue. The prospect must see none of it: the moment they spot a reset button, they are looking at a mockup.
My role
Product Designer, sole designer, paired with a developer.
Research and synthesis, a functional architecture diagram validated with the PM before the first mockups, design of the screens and the branding system, prototype and testing, copy written with marketing, handoff and follow-through to implementation.
Every feature comes from the field
Six salespeople, one instruction: walk through their last client meeting minute by minute, rather than list the features they would like. Three constraints emerged that no specification mentioned:
- They chain meetings: a full reset is needed in seconds.
- They meet competing operators: the branding has to change before every meeting.
- Their speaking time varies: long steps must be skippable.
Every feature in the sales layer answers an observed constraint. That is what let us settle the scope with the PM: anything not tied to an observed need stayed out of the first version.
6
salespeople interviewed upfront, then brought back to test the prototype: the same people at the start and the end of design
The key decision: verifying identity before payment
In the original journey, users paid, then verified their identity. Salespeople and tests raised the same objection, almost word for word: paying without knowing whether verification will succeed is stressful. The money is gone while the service isn't guaranteed, and for a purchase made on the move, often just before a trip, that hesitation is enough to make people drop out.
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.
The cost: the heaviest step comes before payment, for a user who has invested nothing yet, and drop-offs move up the funnel. The gain: nobody pays for a service they may not be able to activate, and the operator avoids a refund and a lost customer.
Testing both orders, verification before or after payment, also showed which one engaged users more.
Two other decisions
A control menu placed where the prospect doesn't go.
The control features are grouped on a single screen, under « Admin » in the settings. Nothing in the purchase journey points to it, and the label means nothing to a prospect looking over the salesperson's shoulder.
I ruled out a secret gesture. A salesperson who can't find the reset in front of a client loses more than concealment gains.
The screen separates what is prepared before the meeting (operator, colours, logo), what is set during it (skipping onboarding or identity verification) and the reset, isolated at the bottom. The active operator and theme stay visible at all times: the worst case would be starting a demo in the colours of the competitor seen the day before.
1 · Settings
2 · Sales menu
A neutral theme, designed to be replaced.
The dark theme belongs to no operator: it is the base. The light theme shows the app dressed in a client's colours. Every component had to handle a change of colour and logo without breaking layout or contrast.
Only three variables are exposed: logo, primary colour, operator name. Below 4.5:1, labels on the primary colour automatically switch to dark: the salesperson cannot produce a non-compliant screen.
3 · Branding
Results
What was validated
8 / 10
people new to eSIM downloaded and activated a profile unaided, in guerrilla testing
strangers, not the salespeople
Recognition
Best of Thales Design
selected to represent my business unit
Status. In development, not yet rolled out to the sales teams. No real usage data so far.
What I took away
Research maps the users, not the platform. My six interviews described the sales job precisely, without saying anything about what the operating system imposes, or what happens to the app after three real profile downloads.
Three of the most structural features came out of handoff, raised by the developer: location permission, profile switching, the branding library. This project moved the point where I bring technology into design: from scoping onwards, not just at delivery.