🔨 Rapid Prototyping

At IDEO, the design firm founded by David Kelley in 1991, there is a maxim that guides every project: "Never go to a meeting without a prototype." In “The Art of Innovation” (2001), Tom Kelley describes how a culture of rapid prototyping distinguishes teams that innovate from teams that only plan to innovate. The prototype isn’t the final solution—it’s a physical question you ask the real world.

Prototyping is think with your hands. When you take an idea out of your head and make it tangible—even if it is a paper card or a sequence of sticky notes—your brain, and other people's brains, start seeing problems no presentation would reveal. Harvard Business School estimates that teams that prototype early reduce the cost of correcting errors by up to 5x compared with fixing it in the final product. The logic is simple: making a mistake on paper costs nothing; making one in code costs a sprint; making one at launch costs a company.

Fidelity is the level of polish and realism in a prototype. There is no universally "best" fidelity — there is the right level of fidelity for the question you want to answer. IDEO uses the principle of building "rough, rapid, right": the prototype should be rough enough not to be mistaken for the final product, fast enough to avoid creating attachment, and right enough to test the central hypothesis.

There isn't just one type of prototype. The choice depends on what you want to learn: user behavior, technical feasibility, business model, or market demand. Each type of prototype addresses a different area of uncertainty. IDEO catalogs dozens of techniques; here are the five most commonly used in corporate innovation and startups.

The biggest source of waste in prototyping isn't building the wrong prototype — it's building the right prototype with the wrong level of fidelity. A team that uses an interactive Figma prototype to find out whether users want the product spent 3 days instead of 3 hours. A team that uses a paper card to test technical performance will never get the data it needs. Fidelity should be guided by hypothesis you are testing, not based on the team’s comfort level or the desire to impress stakeholders.

A rule of thumb from IDEO: build the prototype with the minimum fidelity that still produces the data you need to make the decision. If a sticky note answers the question, don't open Figma. If Figma answers it, don't write code. If the code answers it, don't launch. Every level of fidelity above what is necessary is an opportunity cost—time you could have used to test the next hypothesis.

Testing a prototype without knowing what you want to measure is like conducting research without a hypothesis: you collect data but don’t know what to do with it. IDEO trains its teams to define learning metrics before building—not vanity metrics. “How many people liked it?” is a vanity metric. “How many people completed the task without help?” is a learning metric.

Tom Kelley dedicates an entire chapter of “The Ten Faces of Innovation” (2005) to what he calls “the prototyping traps”: pitfalls that turn a powerful tool into a source of waste. The most common and most devastating is emotional attachment to the prototype — what IDEO calls "falling in love with the prototype". When the team spends days on a beautiful prototype, the brain stops treating it as a hypothesis and starts treating it as a product.

Module Key Concepts