Prototype

Origin & evolution

Prototyping moved from engineering practice into design method through IDEO, where rapid, scrappy modelling became the visible signature of the work. Tom Kelley's *The Art of Innovation* (2001) framed the prototype as a thinking tool: the act of building forces the questions and choices that talking around a problem lets you dodge. The slogan that followed, build to think, captured the inversion. You prototype to learn what you do not yet know, then design.

The cost of being wrong fell sharply over two decades. Paper prototyping, popularised by Carolyn Snyder's *Paper Prototyping* (2003), proved that hand-drawn screens shoved across a desk could expose real usability failures for almost nothing. As tools improved, the spectrum widened from low-fidelity sketches through clickable flows to high-fidelity interactive mockups indistinguishable from shipped software, each tier suited to a different question.

The settled doctrine is fidelity discipline. Match the prototype's realism to the question and no further. A low-fidelity wireframe▭WireframeExperience DesignA low-fidelity structural layoutView reference → answers "is this the right structure?" A high-fidelity prototype answers "does this interaction feel right?" Over-polishing a prototype wastes effort and, worse, makes testers reluctant to criticise something that looks finished.

How it works in practice

A team is unsure whether a new canvas should snap nodes to a grid or let them float freely. Building either in production code would cost a sprint. Instead they make two medium-fidelity clickable prototypes in a design tool, one snapping and one floating, and run them past eight users with a single task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →: arrange six items the way you would want them. The prototypes carry a test_status of testing. Six of eight users fight the grid and prefer floating, but three ask for an optional align command. The snapping prototype is marked failed, the floating one passed, and the team ships free placement with an align action, a design it would not have reached by arguing. The expensive build starts only after the cheap test resolves the question.

Prototype vs. its neighbours

• Wireframe: a wireframe is a static layout of structure and hierarchy; a prototype adds interaction and can be operated. A wireframe shows where things go; a prototype lets a user try to do something. The graph treats the wireframe as an earlier step in the same design sequence.
• Minimum viable product: an MVP is a real, shippable product released to a market to learn; a prototype is a throwaway model tested with a few users. The MVP transacts with reality; the prototype rehearses against it. Confusing the two leads teams to ship rehearsals.
• Mockup: a mockup is a high-fidelity visual of how a screen looks; a prototype is concerned with how it behaves. A mockup can be the surface a prototype animates, but a static mockup answers no interaction question on its own.

In the graph

In the Unified Product Graph, prototype📱PrototypeExperience DesignAn interactive mockup for testing lives in the Experience, Design & Brand region, near the end of the design creation sequence after journeys, screens, flows, and wireframes. Its fidelity and test_status properties encode the two facts that matter most: how realistic it is and whether anyone has actually tested it. The connecting edge that gives a prototype its purpose is prototype_tests_hypothesisPrototypetestsHypothesiscross-domain, which reaches across into the Discovery, Research & Validation region, closing the loop between making and learning🧠LearningValidationAn insight gained from an experimentView reference →. prototype_validates_featurePrototypevalidatesFeaturecross-domain and prototype_simulates_screenPrototypesimulatesScreensemantic tie it to what it stands in for, and solution_materialises_as_prototypeSolutionmaterialises asPrototypehierarchy records where it came from. A prototype stuck at untested with no hypothesis🧪HypothesisValidationA testable belief about a solutionView reference → edge is the graph's version of the anti-pattern the field already named: a prototype nobody tests is just art.