Definition
A prototype is an approximation of a design made in order to learn something. What it approximates depends on the question. A prototype testing whether people understand a flow can be paper, clicked through by a facilitator. One testing whether an animation feels responsive must be built in code with real timing. One testing whether a recommendation is useful may need real data behind a crude interface. The defining characteristic is selectivity: a prototype is complete in the dimension being tested and openly unfinished everywhere else. Deciding which dimension matters — flow, content, timing, data, hardware — is the main skill.
Why It Exists
Prototypes exist because some questions cannot be answered by discussion or by looking at a static design. Whether a sequence is confusing, whether a gesture is discoverable, whether a delay is tolerable, whether a form can be completed with a real document in hand — these are properties of use, not of appearance, and they only appear when someone tries. They also exist as a commitment device in reverse: they let a team find out that an idea is wrong while abandoning it still costs days rather than quarters. In engineering and industrial design this logic is old; software adopted it as products became too complex to reason about in advance.
Examples
- →A paper prototype where a facilitator swaps sheets as the participant taps, used to test a form's sequence.
- →A clickable flow linking static screens, testing whether people can complete a task without guidance.
- →A coded prototype with real latency, testing whether a search feels fast enough to keep typing in.
- →A Wizard of Oz study where a human performs the work the system will eventually automate, to test whether the output is wanted.
History
Prototyping is inherited from engineering, architecture and industrial design, where models, mockups and test rigs long preceded manufacture. In software, the shift came with interactive tools: HyperCard in the late 1980s let non-programmers assemble clickable interfaces, and paper prototyping became a documented usability method through the 1990s, described in practitioner texts including Carolyn Snyder's Paper Prototyping. IDEO and similar consultancies popularized rapid, rough prototyping as a design attitude — build to think rather than to demonstrate. Agile software practice then absorbed the underlying idea, making working increments a means of learning rather than only of delivery.
In Modern Design
Prototyping tools now produce artifacts close enough to real software that stakeholders mistake them for finished products, which creates two problems: expectations about timelines, and feedback about polish rather than function. Designers manage this by stating what the prototype does and does not represent before any demonstration. At the same time, the gap between prototype and production has narrowed from the other direction, as design systems and code generation make it feasible to prototype with real components and, increasingly, real data. Prototyping now also covers behavior that is hard to fake — machine learning output, latency, notifications over time — where a convincing test requires the real mechanism.
Real-World Example
A team designing an AI-assisted triage tool for support agents faced a question a static design could not settle: would agents trust a suggested response enough to use it, and what would they do when it was wrong? They ran a Wizard of Oz study, where a colleague in another room wrote the suggestions the agents saw within a few seconds. The interface was crude. The finding was decisive: agents accepted good suggestions readily but, when a suggestion was subtly wrong, often sent it anyway because editing felt like rejecting the system. That result reshaped the design toward requiring an explicit edit step, and no amount of flow diagramming would have produced it.
Key Principles
- →Write the question first; the question determines the medium and the fidelity.
- →Be complete in the dimension under test and visibly rough everywhere else.
- →The cheapest prototype that can answer the question is the right one.
- →State the prototype's limits before demonstrating it, or you will collect the wrong feedback.
- →Some properties — timing, data quality, error behavior — cannot be faked and must be built.
- →Prototypes are for learning; keeping one because it took effort is how a test becomes a commitment.
Why it matters
Prototyping is the practical mechanism by which design becomes empirical rather than persuasive. Without it, the best argument wins; with it, observed behavior wins, and the person who was wrong finds out cheaply. It also changes the emotional economics of a project, because it is far easier to abandon an idea you spent two days on than one you spent two months defending. As products increasingly involve probabilistic behavior, live data and complex timing, the ability to construct a truthful partial version becomes more valuable, not less: these are precisely the systems whose behavior nobody, including their builders, can reliably predict from a specification.
Then vs Now
Then
Teams tested sequences with paper and clickable stacks, and the difference between a prototype and real software was obvious to everyone in the room.
Now
Prototypes can use real components, real data and real latency, so their limits must be stated explicitly and the risk of mistaking them for products is constant.
Try it yourself
Take a design idea you hold confidently and write the single riskiest assumption behind it as a testable question. Then build the cheapest possible thing that could answer it, giving yourself two hours maximum. If the question is about sequence, use paper. If it is about wording, put the text alone in front of people. If it is about whether the output is useful, fake the system with yourself behind a screen. Run it with three people, note what they did rather than what they said, and write down whether your assumption survived. Be specific about what you now know that you did not.