Build the cheapest thing that can answer your riskiest question. Six rungs of fidelity — the skill is matching the rung to the assumption, not always climbing higher.
▸ Try the interactive toolPrototyping is building the cheapest possible representation of an idea that can answer a specific question — before real engineering begins. The Prototype Fidelity Ladder organises prototype types from lowest to highest fidelity, each suited to a different kind of assumption at a different stage of confidence.
The most common prototyping mistake is over-building: jumping to a polished, coded prototype to answer a question a paper sketch could have settled in an afternoon. The right rung is the lowest one that can credibly answer the question you actually have. Fidelity costs time and creates attachment — the more you build, the harder it is to throw away when the test says no.
Sketch / paper · Wireframe · Clickable mockup · Interactive prototype · Fake door / concierge · Coded MVP — each answers a different question at a different cost
Fidelity is a cost, not a virtue. The ladder exists so you spend the minimum needed to de-risk the specific assumption in front of you.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Over-building the prototype | Coding a polished prototype to test a question a sketch could answer. | Match the rung to the question — climb only as high as the assumption requires. |
| Testing the wrong thing | A beautiful prototype that validates aesthetics when the real risk was demand. | Name the riskiest assumption first, then pick the rung that tests it. |
| Attachment to sunk work | The more you build, the harder it is to kill. | Low-fidelity prototypes are easy to discard — which keeps you honest. |
| Slow learning | High-fidelity prototypes take long enough that you learn one thing per month. | Low rungs let you test several assumptions in the time one coded prototype takes. |
Before choosing a fidelity, write down the single question that, if answered no, kills the idea. Everything follows from this.
Demand question? A fake door beats a coded build. Comprehension question? A wireframe beats a polished mockup. Don't climb higher than the question requires.
Prototype the part under test, fake everything else. A prototype is a question, not a product — polish elsewhere is wasted.
Put it in front of people who match the target, and watch behaviour, not politeness. What they do with the prototype is the answer.
Let the result move the idea up, sideways, or into the bin. The prototype's value was the learning — don't keep building it out of attachment.
A team spent three weeks coding a working prototype of a new feature to “test if users want it.” Users found it usable — but barely anyone tried it. The real risk was demand, and a one-day fake-door test would have revealed the lack of interest before the three weeks.
They'd climbed to the top of the ladder to answer a question the bottom rung was built for. Worse, the polished build made it emotionally harder to accept the result.
The artifact is the prototype — but the decision is choosing the rung. This map is the chooser.
| Rung | Best answers | Cost |
|---|---|---|
| Sketch / paper | “Does this flow make sense?” | Minutes |
| Wireframe | “Is the structure clear?” | Hours |
| Clickable mockup | “Can users complete the task?” | Hours–days |
| Interactive prototype | “How does it feel in use?” | Days |
| Fake door / concierge | “Do users actually want it?” | Hours–days |
| Coded MVP | “Does it work at small scale, for real?” | Weeks |
A prototype is a question, not a product. Its only job is to answer the riskiest assumption as cheaply as possible — and then to be thrown away.
The discipline runs against instinct: building feels like progress, and a polished prototype feels more “real” than a sketch. But fidelity buys you nothing if the sketch would have answered the question, and it costs you both time and the objectivity to accept a no. The best prototypers are slightly embarrassed by how rough their prototypes are — because they built exactly enough to learn, and not one pixel more.
Coding what a sketch could answer. Pick the lowest rung that credibly tests the assumption.
A gorgeous prototype that validates looks when the risk was demand. Name the real risk first.
Effort spent making the fake bits pretty is wasted. Prototype the question, fake the rest.
Sunk-cost attachment to a prototype that tested no. The learning was the point; let the artifact go.
Prototypes are how the Discovery track answers “is this the right solution?” before delivery commits.
A prototype checks whether a proposed solution actually closes the gap the problem statement named.
Interviews surface the riskiest assumption; the prototype is built to test it.
Fake-door testing, pretotyping, and the full fidelity spectrum get dedicated treatment in the discovery module.
Write down three things your team is unsure about (e.g. “will users want X,” “is this flow clear,” “does this feel good to use”). For each, name the lowest ladder rung that could answer it.
Now ask: for the last thing your team prototyped, did you build at the right rung — or higher than the question needed?
Most teams habitually build one or two rungs too high. Spotting that habit saves weeks per quarter.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.