Prototyping

A prototype is an artifact built to answer a question, and the discipline of prototyping is almost entirely about being honest with yourself about which question. "Can users find the export button?" needs a clickable mockup. "Does this animation feel right?" needs code. "Will the search return results fast enough on a million rows?" needs a real backend and no interface at all. Building the wrong fidelity means either wasting weeks or getting an answer you can't trust.

The failure mode on one side is over-building: a polished, near-production prototype that took a month and could have been replaced by five paper sketches. The failure mode on the other is under-building: testing a flow that depends on real data with static mockups and concluding it works. In between sits the useful rule — build the least you can that still answers the question.

There's also a third failure, common enough to name: the prototype that quietly becomes production. Code written to be thrown away rarely survives contact with real requirements, and the decision to keep it is usually made by default rather than deliberately.

TL;DR

Quick Example

The same feature at three fidelities, each answering a different question:

Note that the code prototype doesn't implement the edit dialog, the API, permissions, or error handling. It answers its question and nothing else — that restraint is what keeps it a prototype.

Core Concepts

The fidelity spectrum

Fidelity has several independent dimensions, and they don't have to move together:

The most useful combination is frequently low visual fidelity with high content fidelity — grey boxes containing real names, real product titles, real error messages. Visual polish invites feedback on colors; real content surfaces that your card breaks at 60 characters and that half your users have no avatar.

Matching fidelity to the question

The last two are worth dwelling on. A Figma prototype cannot be navigated with a screen reader or a keyboard in any meaningful way, so accessibility questions require code. And willingness to pay is answered by asking for money, not by showing someone an interface.

Throwaway vs. evolutionary

Both are legitimate. The problem is not deciding — a "quick prototype" with no tests, no error handling, and no architecture gets demoed, praised, and shipped, and then lives for five years as the code nobody can change.

Make the choice explicit and visible. If it's throwaway, say so in the README and the demo. If it might survive, build it with the structure it needs from the start and accept that it takes longer.

Prototyping in Figma

Figma's variables and conditional logic have made it capable of surprisingly stateful prototypes. The trap is that building them takes longer than writing the equivalent React — past a certain complexity threshold, code is both faster to build and more honest about behavior.

Prototyping in code

Worth it when the question is about feel, data, or performance. Keep it cheap:

Tools that lower the cost: Vite for instant setup, Storybook for isolated component prototypes, CodeSandbox and StackBlitz for shareable links, and AI code generation for a fast first pass at something disposable — which is genuinely one of its strongest use cases, precisely because the code doesn't need to be maintainable.

Wizard of Oz and fake backends

For features whose value depends on something expensive to build — a recommendation engine, a document parser, an AI feature — simulate it with a human or a hardcoded response.

This answers whether the feature is wanted before you build the hard part. Be careful about honesty with participants — you can withhold implementation details during a session and should debrief afterward, and you should never sell a manual process as automated to paying customers.

Best Practices

Write the question down before you build

One sentence: "Can a new user create their first project without help?" Everything in the prototype either serves that question or is decoration. This one habit prevents most over-building.

Use real content

Real names, real product titles, real error messages, real quantities. Lorem ipsum has uniform word lengths and hides the layout problems, truncation issues, and hierarchy failures that real content produces immediately.

Prototype the unhappy paths

Empty states, error states, loading, permission denials, and the case with 500 items. Prototypes almost always show the ideal flow, and the ideal flow is the part that was never in doubt.

Match visual fidelity to the feedback you want

A polished mockup gets feedback on color and typography. A grey-box wireframe gets feedback on structure and flow. If you're asking "does this make sense?", low visual fidelity gets you a better answer — people are more willing to criticize something that looks unfinished.

Test with users, not with stakeholders

Stakeholder review answers "does leadership approve?" User testing answers "does this work?" Both are necessary and they are not substitutes. See UX Research.

Timebox it

A day, three days, a week — decided in advance. Prototyping expands to fill available time, and the marginal value drops sharply once the core question is answered.

Label it clearly as a prototype

In the file name, the deployed URL, the README, and verbally in every demo. Prototypes get screenshotted, forwarded, and mistaken for commitments with remarkable speed.

Decide the disposal plan before you build

Throwaway or evolutionary, stated explicitly. If throwaway, delete it when the question is answered — a repository of undeleted prototypes is a repository of things someone will eventually copy from.

Common Mistakes

Building high fidelity to answer a low-fidelity question

Lorem ipsum

Only prototyping the happy path

Letting a prototype become production by default

Testing with the team

Prototyping past the answer

FAQ

Figma or code?

Figma for flow, navigation, comprehension, and visual questions — it's faster to build and faster to change. Code when the question involves feel (animation, gesture, latency), real data (search, sorting, volume), complex state, or accessibility. The tipping point is roughly when the Figma prototype's conditional logic becomes hard to reason about — past that, code is both faster and more truthful.

How long should a prototype take?

Hours for a flow question, a day or two for an interaction question, a week at the outside for something genuinely complex. Anything longer is usually a sign that the question is too broad or that you've started building the feature. Timeboxing before you start is the most reliable prevention.

Should prototypes use the design system?

For high-fidelity prototypes, yes — it's faster than building from scratch and produces something that looks like your product. For early exploration, no: the design system constrains you to existing patterns, which is exactly wrong when you're exploring whether a new pattern is needed.

Can AI generate prototypes?

Yes, and this is one of its better applications — v0, Bolt, Lovable, and general code generation produce a working interactive prototype from a description in minutes. The output is well-suited to throwaway prototyping specifically because maintainability doesn't matter. The risk is the same as ever, amplified: a prototype that looks production-ready is more likely to be shipped without the work that would make it so.

How do I stop stakeholders treating a prototype as a commitment?

Label it everywhere, show unfinished states deliberately, and use lower visual fidelity than you're tempted to. A prototype that looks like a screenshot of a finished product will be treated as one, no matter what you say in the meeting. Deliberately rough visuals are a communication tool, not just a time saving.

What about prototyping backend or infrastructure?

Same principle, different artifact. A spike that proves a query returns in acceptable time on realistic data volume, a load test against a candidate architecture, or a throwaway script that validates an API's behavior are all prototypes. Write down the question, build the least that answers it, and delete it — the discipline transfers exactly.

Related Topics

References