Prototyping

What this category covers

Making something clickable before anyone builds it: interactive mockups, state changes, flows people can actually try, and the testing that turns opinions into observations.

The overlap with design software is large, since most design platforms now include prototyping. Dedicated tools exist for the cases where interaction carries real logic, or where research needs recording and analysis attached.

Screen design and design systems sit in design. Full application building without code belongs in no-code and automation.

Fidelity is a decision, not a default

The most common waste in this category is building a beautiful prototype to answer a question that grey boxes would have settled.

Low fidelity tests structure: whether people understand the flow, what they expect next, where they hesitate. It is quick, cheap, and almost impossible to over-invest in.

High fidelity tests comprehension and confidence. Polish changes behaviour, and a rough screen makes people forgiving in ways a real product does not, so anything about trust or purchase needs to look finished.

Decide the question first, then choose the fidelity. Working the other way around is how three weeks disappear into animations nobody was asking about.

What separates the tools

• Interaction depth, from simple links to conditions and variables.
• State, so a screen remembers what was entered a moment ago.
• Components, reused across screens without duplicating work.
• Data, real or realistic, rather than the same placeholder everywhere.
• Device testing, on an actual phone rather than a scaled frame.

Variables and conditions are the dividing line. A prototype that can hold a form entry, branch on it, remember the choice and show a genuine error state answers questions the linked-screens approach cannot.

Realistic content matters more than people expect. Long names, empty lists, missing images and error messages are where designs break, and placeholder text hides every one of them.

Testing, which is the actual point

A prototype exists to be shown to somebody who was not in the room.

Moderated sessions produce reasoning: why a person hesitated, what they thought a word meant. Unmoderated testing produces behaviour at scale and lower cost, without the follow-up question. Both beat a review meeting where the loudest opinion wins.

Five participants per audience group finds most usability problems. Beyond that the return falls sharply, and the time is better spent fixing what was found and testing again.

Write the task before recruiting anyone. Watching somebody attempt a specific job is evidence, while asking for an opinion on a screen is a conversation about taste.

From prototype to build

The handover question is what survives.

Some teams treat the prototype as a specification: a record of every state, transition, empty case and edge case that would otherwise be argued about during implementation. That is where most of the value sits.

Generated code has improved and still needs rewriting for production. Treat any export as a starting sketch rather than a shortcut, and expect the real implementation to raise questions the prototype never faced, particularly around performance and accessibility.

Cost and practical constraints

Pricing is per editor per month, with viewers usually free, and dedicated research platforms charging per study or per participant instead.

The larger cost is time. A prototype that takes two weeks to build has cost more than the meeting it replaced, so keep the scope tied to the question. Testing services add a per-participant fee, sometimes with recruitment included, and that is normally money well spent compared with guessing. The broader pricing habits across software are described in what pricing pages hide.

Where prototypes earn their cost

Three situations reliably repay the effort of building one.

A flow with genuine complexity, where written descriptions produce different pictures in different heads and the disagreement only surfaces during implementation.

A decision with money attached, where a checkout, a pricing page or a signup path can be tested with real people before anybody builds it.

A pitch, internal or external, where showing something working changes the conversation from opinion to detail.

Outside those, a well-written description and a static screen often do the job. The discipline worth keeping is asking what question the prototype answers, and stopping as soon as it has been answered rather than continuing because the file is enjoyable to work in.