I stopped shipping screenshots
I stopped shipping screenshots
Closing the gap between design and engineering, back when a prototype was a picture and now that it's code. With a few live demos you can poke at, including a component X-ray.
How coding our prototypes closed the gap between design and engineering, and turned the prototype into a design-system adoption tool. Poke at the demos as you read.
For years the handoff looked like this. A designer finishes a screen in Figma. It gets thrown over the wall to engineering. Engineering squints at a flat picture and guesses at the parts the picture can't show: what happens when the field is empty, what a broker sees versus an admin, what the error state does. Everyone means well. The gap opens anyway.
I work across design and engineering on a large, regulated financial product, and that gap was the expensive part. Not the design. Not the build. The space in between, where a static mockup meets a real system and the two quietly disagree.
[Interactive demo: a renewals product dashboard with a customer/admin view toggle]
A picture can't answer the interesting questions
A mockup shows you one state. Products are made of states. Filled, empty, loading, error, this role, that permission, the edge case nobody drew.
Here is the shape of the problem, and where it gets solved.
[Interactive demo: the prototype as the bridge across the design and engineering gap]
Figma is still the source of truth for the look. That is not changing, and it should not. Plenty of designers are design-first and want to stay in Figma, and the moment you force them into a code editor you lose the thing that made them good. So Figma stays where the visual truth lives.
The truth about behaviour, though, lives somewhere else now.
AI moved prototyping into code, so I followed it there
Spinning up a coded prototype used to be a luxury you couldn't justify. It's not anymore. The cost of getting a real, clickable thing on screen has dropped through the floor, so the prototype stopped being a throwaway sketch and started being something closer to the product.
Once it's code, it can do what a picture can't: it can behave. And once it behaves, you can hand a stakeholder something that answers their questions before they ask them.
Take roles. Our product shows a completely different surface depending on who's logged in. In Figma that's three files to keep in sync forever. In a coded prototype it's one thing that changes.
[Interactive demo: a permission-driven UI that changes with the selected role]
Same prototype. The layout, the navigation, the permissions all follow the role. Nobody has to imagine the admin view. They click into it.
Then there's the boring stuff that quietly decides whether a prototype gets used. We have a lot of forms. If a tester has to fill twelve fields by hand every single time they want to reach the screen after the form, they stop testing. So the prototype prefills itself.
[Interactive demo: one-click prefilled form states]
One click, and you're testing the interesting screen instead of doing data entry for the tenth time today. Small thing. It's the difference between a prototype people actually open and one they don't.
The design system's real problem was never the design
Here's the part I'm proudest of, and it has nothing to do with how anything looks.
Design systems don't fail at design. They fail at adoption. You can build a beautiful, well-documented library and still watch engineers ship a one-off button because they didn't know the real one existed, or couldn't tell whether the thing on screen was the system component or somebody's copy of it.
So I built an X-ray. Flip a toggle on the prototype, hover any component, and it tells you what it is, whether it's published in the system, and whether it's actually in use. One hop to the Figma reference. One hop to the docs. The prototype teaches the design system while people use it.
[Interactive demo: an X-ray that names each component and shows whether it is published in the design system and in use]
That amber one is the whole point. An in-use component that never made it into the system is exactly the kind of drift you can't see in a screenshot and can't feel in a spec. Made visible, it becomes a five-minute fix instead of a slow rot.
It lives at one URL
None of this matters if it sits on my laptop. The prototype is served org-wide from a single link, so the PM, the engineers, the stakeholders, and QA are all looking at the same living thing instead of arguing over which version of which PDF is current.
[Interactive demo: the prototype X-ray in context — an inspector panel naming the PolicyCard component and showing its JSX]
A shared, behaving, self-documenting prototype turns out to be less of a design artifact and more of a piece of infrastructure. It's the one place design and engineering can stand together and point at the same reality.
The takeaway
Keep Figma as the source of truth for how things look. Let design-first designers stay there. But stop treating the prototype as a screenshot with delusions. Now that code is cheap, make it behave like the product: give it states, give it roles, give it prefill, and let it tell you the truth about your own design system.
I stopped shipping screenshots. I started shipping something people could actually use to make decisions. The gap got a lot smaller.
[Interactive demo: a closing card: a prototype your team can actually use]
This is the kind of work I did through Purple Luna — now an AI receptionist for appointment businesses, answering WhatsApp and booking appointments 24/7. The demos above are generic illustrations, not the real product.
This page requires JavaScript to view fully. The summary above is for indexing.