Prototyping

Prototyping

Prototypes are simplified and incomplete models of a design used to explore ideas, validate assumptions, refine specifications, and test functionality before committing to full implementation. The discipline is matching prototype fidelity to the question being asked — paper sketches answer structural questions cheaply; coded prototypes answer performance questions but cost more. Picking the right fidelity for each question lets teams iterate fast where it matters most.

Definition (in our own words)

A prototype is a deliberately incomplete version of a design built to answer a specific question that wasn't answerable from specifications alone. Prototypes range from paper sketches (minutes to make, structural questions only) to working code (days or weeks, real-world behavior questions). They are throwaway by intent — the team learns what they need to learn and moves on. The book identifies three kinds — concept, throwaway, and evolutionary — each suited to different questions.

Origins and research lineage

• Engineering practice — prototypes have been used since the industrial revolution. Wright brothers built and tested over 200 wing prototypes before the Flyer.
• Software engineering — Frederick Brooks' The Mythical Man-Month (1975, 1995) and Barry Boehm's spiral model (1986) both emphasized prototyping as risk reduction.
• Lidwell, Holden & Butler (2003) compactly distinguish three prototype kinds: concept (exploratory), throwaway (specific question), evolutionary (incremental refinement toward the final).
• Tom Kelley & David Kelley at IDEO, The Art of Innovation (2001) and Creative Confidence (2013). Codified prototyping as core to design thinking; "fail fast" via cheap prototypes.
• Michael Schrage, Serious Play: How the World's Best Companies Simulate to Innovate (Harvard Business School Press, 1999). Argued that prototyping cultures outperform specification cultures.
• Modern continuous-delivery practice — every staging deployment is, in a sense, a prototype of production behavior; canary releases prototype at increasing scale.

Why prototyping matters

Specifications and discussions can hide assumptions that only become visible when something concrete exists. A team can argue for weeks about whether a flow makes sense; ten minutes with a paper prototype usually resolves it. Engineering can spend weeks building something that turns out to be wrong; a clickable Figma in advance would have caught the issue.

The economics: prototyping costs scale roughly logarithmically with fidelity (sketch ~ 1x cost, wireframe ~ 5x, mockup ~ 20x, code ~ 100x), but error-discovery cost scales roughly logarithmically with the phase the error is found in (requirements ~ 1x, design ~ 5x, code ~ 50x, production ~ 500x+). Catching errors at the prototype phase is dramatically cheaper than catching them in production.

The three kinds (from the book)

Concept prototyping

For exploring preliminary ideas. Quick, cheap, often disposable.

Examples:

• Concept sketches.
• Storyboards.
• Mood boards.
• Wireframes.
• Cardboard mockups for industrial design.
• Foam props.

The book's caution — the artificial reality problem: a skilled artist or modeler can make any design look like it will work in a concept prototype. Don't conflate "looks plausible" with "will work in production."

When to use: very early, when the question is "is this concept worth exploring further?" or "do stakeholders agree on direction?".

Throwaway prototyping

For testing specific aspects of a design. Built to answer a question, then discarded.

Examples:

• Wind-tunnel models of automobile aerodynamics.
• Performance benchmarks of a specific algorithm.
• A/B test variants.
• Standalone interactive demos.

The book's caution — the scaling-and-integration problem: a feature that works in a throwaway prototype may not scale or integrate properly when built into the production system.

When to use: when one specific aspect needs verification (performance, usability of one flow, market reaction).

Evolutionary prototyping

For incrementally building toward the final design. The prototype itself evolves into (or becomes) the production system.

Examples:

• Software MVPs that grow into the product.
• Architectural mockups that inform the final building.
• Iterative product development with continuous user feedback.

The book's caution — the tunnel vision problem: evolutionary prototypers often get fixated on tuning existing specifications rather than exploring alternatives. Each iteration improves the current direction but may miss a better direction entirely.

When to use: when design specifications are uncertain or changing, and the team can sustainably iterate.

When to apply

• Whenever there's significant uncertainty about a design choice.
• Before major implementation investments — a few hours of prototyping can save weeks of building the wrong thing.
• When stakeholders disagree — concrete prototypes resolve disputes that abstract discussions can't.
• For user testing — most useful research uses prototypes as the subject.
• For technical risk reduction — performance, integration, and scale risks become visible in prototypes earlier than in production.

When NOT to over-apply

• For trivial, well-understood decisions. Prototyping the placement of a Save button on a CRUD form wastes effort.
• In safety-critical final stages. Prototypes are by definition incomplete; once a design is destined for safety-critical deployment, formal verification beats further prototyping.
• As a substitute for shipping. Endless prototyping without commitment is procrastination disguised as research.

The fidelity ladder

Different fidelities answer different questions; pick the cheapest fidelity that answers your question.

(See iteration-prototype-fidelity in this plugin for deeper detail on fidelity choices.)

Worked examples

Example 1: paper prototype to resolve a debate

Designers and engineers disagree on a flow. Engineering says it's complicated; design says users will figure it out.

A 30-minute paper prototype: sketch the flow on index cards, walk a colleague through it.

Outcome: in 30 minutes, both sides see what works and what doesn't. The debate resolves with concrete evidence rather than opinion.

Example 2: clickable prototype for user research

A new feature. Before building, the team makes a clickable Figma prototype. They test with 5 users.

Outcome: 3 of 5 users misunderstand the same step. The team revises the flow before any code is written. The build, when it happens, reflects the revisions.

If the team had skipped the prototype, the misunderstanding would have surfaced after weeks of engineering work.

Example 3: technical spike (throwaway prototype)

A team wants to add real-time collaboration. They suspect their current architecture might not handle the latency. They spend a week building a throwaway prototype with WebSockets, just to measure latency under load.

Outcome: latency is acceptable; the throwaway prototype is discarded; the team proceeds to design the production version informed by what they learned.

If they had skipped the prototype and built the production version directly, they'd have been months in before discovering the latency problem.