Prototyping
Make your assumptions tangible so they can be tested and killed cheaply. A prototype is the cheapest version of a thing that can answer a specific question — build only what you need to learn what you need to know.
01 — TL;DR
Two sentences.
Prototyping is the practice of building a lightweight, testable representation of a design — ranging from paper sketches to clickable Figma flows to coded front-end shells — specifically to answer a defined question about whether the design will work before full engineering cost is committed. The prototype is not a preview of the final product; it is a scientific instrument for testing a specific assumption, and its fidelity should be calibrated to the question being asked.
What makes prototyping valuable is the asymmetry of costs: a prototype that takes a day to build and reveals a fundamental problem saves weeks of rework, and a prototype that confirms the design is correct gives the team confidence to proceed. Either outcome has positive expected value — the only bad outcome is the absence of a prototype, which means shipping assumptions as facts.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when the question is technical feasibility (use a spike), when the flow is an established pattern with strong prior validation, when time pressure means the prototype cannot be tested before the build decision, or when the decision hinges on live product metrics (use A/B testing).
03 — How It Works
The mechanism
Prototyping works by making assumptions concrete enough to fail. An assumption about navigation lives safely in a design file until a real user interacts with a prototype. At that point, the assumption either holds or does not — and the cost of discovering it does not hold is the cost of the prototype, not the engineering build.
A prototype is not a commitment
Teams hesitate to prototype because they worry a well-executed one will be taken as a final design. This is a communication problem. Establishing shared vocabulary — "this is for testing, not building" — and using lo-fi signals (placeholder content, greyscale, rough interactions) prevents this misread. If the prototype looks too finished to be questioned, it is too finished to be a prototype.
04 — Real Example
Dropbox's explainer video before a line of code was written
Before building Dropbox, Drew Houston created a three-minute screencast demonstrating what the product would do — showing a simulated sync experience that did not yet exist. The video was posted to Hacker News in 2007. Overnight, beta waitlist signups went from 5,000 to 75,000.
The core assumption was not "can we build this" but "do people want this enough to sign up before it exists?" A video answered that question for a few hours of effort. An engineering prototype would have answered it for six months. The correct fidelity for the question was video, not code — and recognising that distinction is what made the validation one of the most efficient in software history.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a product that clearly tested their flow before shipping — or one where a fundamental problem suggests it was never prototyped? Submit what you observed.
Seen Prototyping skipped in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
Prototyping sits within a family of validation methods varying in fidelity, cost, and the type of assumption they can test.
The most important pairing is Prototyping with Lean UX. Lean UX prevents the most common failure — building without a defined question — by requiring a hypothesis before any build. The prototype is the vehicle for testing the hypothesis; Lean UX ensures it tests the right thing at the right fidelity.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
1. Pick one feature in design or recently shipped. Write down the single most important behavioural assumption the design depends on — the one thing that, if false, means the design needs to be reconsidered.
2. Has this assumption been tested with a real user interacting with a prototype, or only discussed internally? If only discussed, write "untested assumption."
3. Write the minimum prototype needed to test it — not the full flow, just the specific moment. Paper takes 15 minutes. Figma click-through takes 2 hours. Coded interaction takes a day.
4. Identify one person you could put this prototype in front of this week. Five minutes of watching someone interact while thinking aloud is enough to start validating or invalidating the assumption.