Product design
Let them touch it first.
A picture asks the client to imagine the product. A working version lets them decide about it.
Every designer knows this meeting. You present a set of polished screens, the client nods through all of them, and the direction is approved. Six weeks later they see the same product moving in a browser for the first time and say, quietly, that it isn’t what they pictured. Nobody did anything wrong. The approval was given to something they had to imagine, and everyone imagined it differently.
For the last few months we have been closing that gap at the start instead of discovering it in the middle. In discovery, we now put a working version of the product in front of the client, not a picture of one.
A screen shows the route, not the ride.
Static frames and click-through prototypes are good at one thing: showing where a person goes. Tap here, land there. What they cannot show is what it is like to get there. How long a transition takes. Whether a list feels heavy or light under a thumb. What happens when someone types the wrong thing. Those qualities are hard to put in a deck, and they are usually what wins or loses a client’s confidence.
For years, showing that properly meant a developer’s time, and a developer’s time was booked for the build. So discovery ran on pictures and descriptions, and the feel of a product arrived late, when it was most expensive to change.
Wide and shallow, on purpose.
AI coding agents changed the economics. A designer who can direct one can now stand up a working version of the whole product in days: every main path present, real navigation, real states, real motion. It is wide and deliberately shallow. The final type scale, the long tail of error cases, the accessibility pass and the real data all come later, and we say so on the first slide.
Fig. 01Wide and shallow, on purpose
- Working in the prototype
- Later
- All a deck of screens would show
Later, and we say so on the first slide
The gain is not mainly speed. It is that the designer no longer waits in a queue to see an idea move. Our developers stop building throwaway demos and spend that time where they are worth most: telling us early which parts will be hard, slow or fragile to build for real.
The feedback gets sharper.
Hand someone a link instead of a slideshow and the conversation changes. Nobody asks whether they can picture it, because they don’t have to. The notes turn specific. This step can go. The filter should stay open. That confirmation is too slow. They are notes about the product, not about the presentation, and they arrive in the first meeting rather than the third.
It also changes who is in the room. A product owner, a marketer and an engineer on the client side can all click through the same thing and disagree about something real. Alignment that used to take several rounds of revised screens often happens in one sitting.
The prototype is not thrown away.
The part that surprised us most is what happens next. The prototype does not get archived when the project starts. It becomes the starting point. As each feature firms up, its components are named, its states and variants written down, its values turned into tokens. The design system grows out of the work itself instead of running as a separate track that has to be reconciled later.
By the time developers pick it up, they are reading something that already runs and already follows the rules, not translating pictures into code. There is still a handoff. There is far less lost in it. It is a close cousin of The deliverable is a tool now.
Where it can go wrong.
A working prototype is persuasive, and that cuts both ways. Clients can read polish as progress and assume the product is nearly done, so we are blunt about what is placeholder and what is decided. They can also fixate on a detail that was never meant to survive, a sample image or a stand-in label, and spend a meeting on it. Marking those clearly costs a minute and saves an hour.
And it makes a different budget conversation. When discovery produces the foundation of the build rather than a document about it, the two phases overlap. That usually shortens the project, but it means agreeing at the start that discovery is real production work, priced as such.
Fig. 02When the client first meets the product
A / Screens first
B / Prototype first
- Direction approved, from pictures.
- The client sees it moving for the first time: it isn’t what I pictured.
- The client meets the product, in the first meeting.
- Components, states and tokens carry straight into the build.
Show, then decide.
None of this replaces research, strategy or the slow work of getting a product right. It moves the moment a client first meets the product to the very beginning, which is where their judgement is cheapest to act on. If you are about to start something and would rather react to the real thing than to a description of it, tell us about it.
A description asks people to imagine. Something that works lets them decide.
Asked often.
What is an interactive prototype in product discovery?
A working version of the product, covering every main path with real navigation, states and motion but little final polish, built at the start of a project so the client reacts to how it behaves rather than to static screens.
How does AI change prototyping for designers?
AI coding agents let designers build working prototypes themselves in days, without waiting for development time, so the feel of a product can be tested in discovery instead of during the build.
Does a prototype replace the design-to-development handoff?
No, but it shrinks it. When components, states and tokens are documented as the prototype evolves, developers receive something that already runs and follows the system, so far less is lost in translation.