The Prototype Fidelity Ladder
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 toolThe framework
Prototyping 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
Try it yourself
What it prevents
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. |
Step by step
Name the riskiest assumption
Before choosing a fidelity, write down the single question that, if answered no, kills the idea. Everything follows from this.
Pick the lowest rung that can answer it
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.
Build only what the test needs
Prototype the part under test, fake everything else. A prototype is a question, not a product — polish elsewhere is wasted.
Test with real users from the segment
Put it in front of people who match the target, and watch behaviour, not politeness. What they do with the prototype is the answer.
Decide and discard
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 short illustration
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 rung-to-question map
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 |
Why it matters
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.
Common mistakes
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.
When not to use it
- The assumption is already validated. If you know users want it and it's feasible, prototyping to re-confirm is procrastination — build it.
- The risk is purely technical and large. Some feasibility questions need a real engineering spike, not a UX prototype.
- You can't recruit real users. A prototype tested only on the team validates the team's taste, not the market's need.
Where this sits in the toolkit
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.
Pick the rung for three real questions
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.