Prototypes run from a paper sketch to a coded build. Each fidelity answers a different question — and the recurring mistake is building higher-fidelity than the question requires.
▸ Try the interactive toolThe Prototype Fidelity Spectrum is a range of prototype types, ordered from lowest to highest fidelity, each suited to testing a specific kind of assumption at a specific stage of confidence. A prototype is a cheap, fast representation built to answer a question before real engineering begins.
The recurring mistake — the same one Module 1's prototype ladder warned about — is building higher fidelity than the question requires. A polished, interactive prototype to answer “does this flow make sense?” wastes days that a paper sketch would have settled in an hour, and the polish creates attachment that makes a negative result harder to accept. The skill is choosing the lowest fidelity that can credibly answer the question in front of you.
Paper sketch → wireframe → clickable mockup → interactive prototype → coded prototype. Lower = faster, cheaper, easier to discard. Higher = more realistic, but slower and stickier. Match fidelity to the question, not to ambition.
Fidelity feels like progress, so teams over-build prototypes — spending realism they don't need on questions a rougher artefact would answer.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Over-building fidelity | A coded prototype for a question a sketch could answer wastes days. | Matching fidelity to the question spends the minimum needed. |
| Attachment to polish | A beautiful prototype is hard to throw away when the test says no. | Low-fidelity prototypes are easy to discard, keeping you honest. |
| Testing the wrong question | High fidelity tests aesthetics when the risk was comprehension. | Each fidelity suits a specific question — pick by the assumption. |
| Slow learning | High-fidelity prototypes take long enough to learn one thing at a time. | Low fidelity lets you test several questions in the same time. |
Before choosing fidelity, state the single assumption you're testing — flow logic, comprehension, desirability, feasibility. The question dictates the fidelity.
Flow question? A sketch or wireframe. Feel-in-use question? An interactive prototype. Don't climb higher than the question needs; higher costs time and breeds attachment.
Prototype the element the question concerns and fake everything else. Polish on the parts not being tested is wasted effort.
Put it in front of the right users and watch behaviour, not politeness. What they do with the prototype is the answer.
Let the result decide. Climb to higher fidelity only when a question genuinely requires more realism — not out of attachment to what you built.
A team spent a week building a polished, interactive prototype to test whether a new flow “made sense” to users. A grey-box wireframe — an hour's work — would have answered that comprehension question just as well.
Worse, the polish backfired twice: it cost days they didn't need to spend, and when testing revealed the flow was confusing, the team was reluctant to scrap something that looked so finished. A rough wireframe would have been both faster to make and easier to throw away — and would have surfaced the same problem before any of the polish was applied.
The deliverable is the prototype itself — but the decision is choosing fidelity. This map is the chooser.
| Fidelity | Best answers | Cost |
|---|---|---|
| Paper sketch | “Does this flow make sense?” | Minutes |
| Wireframe | “Is the structure clear?” | Hour(s) |
| Clickable mockup | “Can users complete the task?” | Hours–days |
| Interactive prototype | “How does it feel to use?” | Days |
| Coded prototype | “Does it work, technically?” | Days–weeks |
A prototype is a question made tangible, and its only job is to answer that question as cheaply as possible. Every increment of fidelity beyond what the question needs is wasted — in time, and in objectivity.
The attachment problem is the subtle one. Over-building doesn't just cost the extra hours; a polished prototype is psychologically harder to abandon, so a team that built high-fidelity is more likely to rationalise away a negative result than one holding a disposable sketch. This is why the best prototypers are slightly embarrassed by how rough their work is — they built exactly enough to learn and not a pixel more, which keeps both their schedule and their judgement intact. Match fidelity to the question, and climb only when the next question genuinely demands more realism.
The core mistake. A sketch often answers what a coded prototype was wasted on.
Effort on the fake bits is wasted. Build the question, fake the rest.
Match the fidelity to the actual assumption, not to what looks impressive.
Attachment to a polished prototype distorts judgement. The learning was the point.
This is the deeper treatment of the fidelity-matching idea introduced in Module 1, Tool 10.
Prototyping builds the artefact; usability testing (Tool 17) extracts the learning from it.
The lean framework (Tool 15) picks the cheapest viable fidelity for each assumption.
For demand questions, a pretotype or fake door (Tools 18, 19) may beat any prototype.
Write three things a team might be unsure about (“does this flow make sense,” “does it feel good to use,” “will it work technically”). For each, name the lowest fidelity that could answer it.
Now recall the last thing you or a team prototyped — was it built at the right fidelity, or higher than the question needed?
Most teams habitually build a rung or two too high. Spotting that reflex — and the attachment it creates — is the whole lesson of the spectrum.