Prototyping

Concept of the skill

Prototyping is the practice of building an artifact whose only purpose is to answer a specific, written-down question — and building it at the lowest fidelity that can credibly produce that answer. A prototype is not an early draft of the product; it is an instrument. The work begins with a learning goal contract: one or two questions the prototype exists to answer, plus a definition of what evidence would count as an answer in either direction. From there the central judgment is fidelity matching — choosing a rung on the ladder (paper sketch → wireframe → clickable mockup → wizard-of-oz → role-play/bodystorming → service prototype → code spike) that can answer the question without paying for fidelity the question doesn't require. Paper can answer "is this flow understandable?" but not "is this typography readable?"; a clickable can answer "do users find the primary action?" but not "does this feel fast under load?"; only a code spike can answer a true scaling question. The artifact is disposable by design: its value is the learning, not the thing, and a prototype that produces a clear "this concept doesn't work" has succeeded — that finding came at the price of a prototype rather than a launched feature. The discipline rejects polishing before showing, because polish signals finality, makes stakeholders evaluate fit-and-finish instead of concept, and makes users reluctant to criticize.

Coverage

Prototyping covers the practice of constructing artifacts whose primary purpose is to answer a question the team has written down. The fidelity ladder runs from paper sketches (fastest, cheapest, best for early flow and concept testing) through wireframes, clickable prototypes (Figma, Framer, similar), wizard-of-oz prototypes (a human secretly performs the function the system will eventually automate — Kelley 1984), role-play / bodystorming (the team physically acts out a service interaction), service prototypes (props and staged environments for service-design questions), and up to code spikes (throwaway working code that answers a feasibility question).

The central skill is fidelity matching: choosing the lowest fidelity that can credibly answer the learning question. Paper prototypes can answer "is this flow understandable?" but not "is the typography readable?"; a clickable prototype can answer "do users find the primary action?" but not "does this feel fast under load?"; only a code spike can answer "will this API rate-limit us at scale?". Building higher fidelity than the question requires wastes time and prematurely anchors stakeholders on visual decisions.

A complementary skill is the learning goal contract: every prototype begins with one or two written questions it is built to answer, and a definition of what evidence would count as an answer in either direction. Without this, prototypes drift into "let's just make it look nice" and the testing session that follows produces ambiguous results because nobody agreed in advance what they were looking for.

The practice also covers sacrificial concepts — deliberately rough or extreme prototypes whose purpose is to provoke a reaction, not to be defended. IDEO and the Stanford d.school both teach using disposable artifacts to draw out user preferences that would not surface in abstract conversation.

Philosophy of the skill

Prototyping rejects the instinct to polish before showing. Polish signals finality; polish makes stakeholders evaluate fit-and-finish instead of concept; polish makes users reluctant to criticize. A rougher prototype invites honest reaction. The famous IDEO maxim "if a picture is worth a thousand words, a prototype is worth a thousand meetings" captures the substitution effect — but only if the prototype is cheap enough that a team can build three and throw two away.

The discipline insists prototypes are means, not ends. A successful prototype is one that produced a clear answer, even if the answer is "this concept doesn't work" — perhaps especially then, because that finding came at the price of a prototype rather than a launched feature. Teams that judge prototypes by their visual quality have inverted the value system; teams that judge them by what was learned have it right.