Every product starts as a guess. A prototype is that guess made tangible: an early version of the thing, built quickly and cheaply, whose only job is to answer a question before you commit real money and real months to it. Will users understand this flow? Does the idea feel right in the hand? Can this even be built?
The word gets stretched to cover everything from a paper sketch to a near-finished beta, and the stretching causes real damage. Teams demo a clickable picture, everyone nods, and engineering later discovers the picture promised things the system cannot do. Knowing what kind of prototype you are looking at, and what question it can honestly answer, is most of the skill.
This pillar collects our guides to prototyping as it works now, on canvases where the prototype runs:
Rapid prototyping
Build, test, and revise at the speed of a conversation: what rapid prototyping means when the prototype runs.
Prototype vs MVP
One exists to answer a question, the other to serve real users. Confusing them costs months.
Interactive prototypes
From clickable facades to prototypes that actually work, and why the difference changes what you learn.
What a prototype is for
A prototype earns its keep by answering exactly one kind of question well:
- Desirability. Do people want this? Watch someone use the prototype and you find out in minutes what a survey cannot tell you in weeks.
- Usability. Can people operate it? A flow that reads fine in a spec falls apart the first time a real hand tries it.
- Feasibility. Can we build it? Sometimes the only honest way to answer is to build the risky slice for real and see.
The discipline is picking the question first and building only enough to answer it. A prototype that tries to answer everything answers nothing, slowly.
The fidelity spectrum
Software prototypes climb a ladder of fidelity, and each rung trades speed for truth:
- Paper and whiteboard. Minutes to make, great for structure, silent on feel. This is wireframing territory, the natural step before any prototype.
- Clickable mockups. Screens wired together with hotspots. They look real and demo well, but every interaction is staged.
- Coded prototypes. Real code, often messy, running a narrow slice. Slower to make by hand, but what you learn is trustworthy.
- A working product slice. The feature, actually functioning, minus the hardening. The most honest prototype there is.
For most of the industry's history, teams stopped at clickable because coded was too expensive. That economic constraint, not any principle of design, shaped the whole discipline.
Why prototypes got a bad name
Ask an engineer about prototypes and you may get a wince. The clickable facade is why. It photographs like a product, so stakeholders treat it as one. It cannot fail, so user tests flatter it. And it makes no contact with the hard parts, so it hides exactly the risks a prototype should surface. The result is theater: weeks of polish on an artifact that answers only the easiest question, then a painful meeting where reality files its objection.
Agents change the economics that made the facade rational. When an AI agent writes real interface code on a canvas, the working slice costs about what the mockup used to. You describe the flow, the agent builds it, and the thing on your screen accepts input, holds state, and breaks in honest ways. Testing it teaches you something true. On an AI prototyping canvas, the distinction between "the prototype" and "the start of the product" mostly dissolves; what survives testing simply keeps evolving.
Where to start
If your team is arguing about scope, settle the vocabulary first with prototype vs MVP. If you are choosing how real to make the next artifact, interactive prototypes walks the ladder rung by rung. And when you are ready to work at the new speed, rapid prototyping covers the loop itself: question, build, test, revise, at conversational pace. Structure still comes first, so if you have not sketched the flow yet, begin one step upstream with wireframing.