Design-to-code
eSIM Simple
Designing and coding a product end to end with AI, from the first screen to the shipped frontend.
- Thales
- Product Designer
- 6 months
A prototype built to be shown, and written to be kept.
- The product: a two-sided eSIM order management space, an operator back-office and a client area, designed and coded in 2 months. Seven weeks cut from the cycle, and a frontend that ships as it is.
- The validation: no upfront research: five demos, two of them in front of real clients, and a decision to industrialise at the end of it.
- My role: Product Designer, sole designer, in a team of six: a PM, an architect, a Scrum Master, two developers.
Nomad · opérateur fictif
Deux faces, une seule application
Le produit sert deux publics qui ne doivent jamais voir la même chose : l'équipe de l'opérateur, qui gère les comptes partenaires et les commandes, et le partenaire lui-même, qui consulte son catalogue de profils. Un sélecteur placé sur l'avatar du header fait passer de l'un à l'autre, sans déconnexion, sans écran de login, sans rupture au milieu d'une démonstration.
Demonstration prototype. Partners, codes and sites are fictional, Nomad is an invented operator.
Partner accounts
| Status | Actions | ||||
|---|---|---|---|---|---|
| Solaris Mobile | SOL-6690 | LYN | Draft | 11 mars 2026 | |
| Corvus Wireless | COR-8834 | PRTHMBGDN | Pending | 03 mars 2026 | |
| Verano Móvil | VER-5093 | LYNPRT | Active | 28 févr. 2026 | |
| Meridian Telecom | MER-4471 | LYNPRTHMB | Active | 14 févr. 2026 | |
| Kestrel Connect | KES-3318 | HMBPRTSEV | Active | 07 févr. 2026 |
Cliquez ou touchez l'avatar pour basculer. Reconstruction neutre sur « Nomad », un opérateur inventé : aucune donnée, aucune marque ni aucune interface réelles n'y figurent.
Neutral reconstruction on « Nomad », an invented operator: no real data, brand or interface appears here.
The project
eSIM Simple didn't start as a project. To test a new interface direction, I had built a small React prototype. The PM saw something other than an experiment in it, and management gave us a wider brief: run a product end to end, leaning on AI at every stage, from ideation through to development. Dedicated consultants helped us set up the tooling.
The product: an eSIM order management space. Two audiences from the framing stage onward, and that was no implementation detail. The operator back-office and the client area share the same objects — accounts, profile batches, orders — but not the same rights, nor the same reading priorities. Designing them separately would have produced two products; designing them together produced one system with two points of view.
That left the question of how to build it. A mockup would have illustrated screens well enough, but not answered the question at hand: does this hold up when you handle real data? A profile catalogue means hundreds of rows, states that contradict each other, edge cases nobody ever draws in a mockup. I carried on in code — and the prototype ended up serving three purposes at once: testing in a real environment, giving us something to show and have people react to, and giving developers a base to build from.
My role
Product Designer, sole designer, in a team of six: a PM, an architect, a Scrum Master, two developers.
Ideation, information architecture, screen design, prototyping directly in code, through to the shipped frontend.
The validation
This project involved no user research phase: the need was framed upstream, and the question sat elsewhere. Does the product hold up when you handle it?
The PM ran all five demos himself: to the sales teams, to management, and twice in front of real clients. The prototype was never distributed beyond that — it didn't need to be. It had to hold up in front of the right people, and settle what came next.
Which it did. The product is now rolling out.
The key decision
Prototype in code, not in Figma.
A mockup doesn't connect to real data. Prototyping in code let me iterate on actual cases rather than ideal states, and handle the product instead of describing it.
What it cost: far more work upfront to keep the AI in line. Left alone, it wrote code outside the design system — a table imported from Material here, a blue that isn't in the palette there. The system's rules were written down nowhere; they lived in the designers' heads. I opened a parallel effort to encode them. Teaching an AI a design system it has never read.
What it gained: seven weeks off the cycle, and a product that looks like what was designed.
Two more decisions
Writing a prototype built to ship rather than one built to be thrown away.
A demo prototype only has to survive one meeting. Mine was written as though it had to last: design system components, error states handled, responsive, accessibility held.
What it cost: time spent on things no demo makes visible, and the effort of steering the AI towards structured code rather than code that merely displays.
What it gained, first in time. The prototype stood in for the specification at handover. Five weeks of handoff and two of ideation disappeared from the cycle, and the effect spread beyond my own scope: nothing to translate, so nothing to interpret, no gap between intent and implementation to test against, and a user guide written in front of a product you can handle rather than describe.
What it gained, second in fidelity — and this matters more. On a mockup, technical constraints surface at delivery, and it's the design that bends to accommodate them. Prototyping in code, they surface during design, while there's still room to make a call. The product that ships looks like what was designed, not like what survived the negotiation.
A context selector in the header rather than two applications.
The product has two faces: a back-office for the operator, a space for the end client. The need showed up in use: every demo had to cover both within a single session, whoever the audience was.
The real user of this feature is therefore neither the operator nor their client — it's whoever is doing the demo. In production, each would have their own account and moving between the two faces wouldn't exist. But in a demo, logging out and back in front of a room costs thirty seconds and a login screen: the thread breaks. I put the switch on the header avatar.
What it costs: two contexts share a single application, and nothing stops you acting in the wrong scope. The side panel colour — light on the back-office, dark on the client side — is currently the only permanent signal, and that's not enough for an order management product. In production, this would be a matter of accounts and roles, not a button.
What it gains: you move between faces without a break, and the pattern — an account selector on the avatar — is ordinary enough in B2B products not to give the demo away. An audience that sees it sees a feature, not a mockup. It's the exact opposite of the reset button in Demo Kit, which had to be hidden. Incidentally, one codebase for the developers to maintain rather than two.
Results
What the prototype produced
7 weeks
cut from the cycle: 5 of handoff, 2 of ideation.
with dedicated consultants to set up the tooling
Zero handoff
the frontend written during the demos is the one that ships.
5
demos, two of them in front of real clients, behind the decision to industrialise.
run by the PM alone, never distributed beyond
Status. The product is rolling out and will be commercialised. No real usage data yet.
What I take from it
Design-to-code doesn't save time everywhere: it moves it. Upstream it costs — you have to write the rules the AI must follow, and discover along the way every rule nobody had ever needed to put into words. Downstream it gives a great deal back: where the handoff used to be, there is nothing left to translate.
Its limit sits exactly where its cost does. You can only encode rules that already exist. Wherever the design system was silent, the AI kept producing defaults that had to be settled by hand, one at a time. And a prototype written to last doesn't decide its own industrialisation — but it removes the main reason not to.