What a prototype actually is
A prototype is a simple model or representation of a final design. The definition is intentionally broad. Sketches count as prototypes. Equations count as prototypes. Computer renderings, wind tunnel models, small physical mockups, simulations - all of these are prototypes. A physical 3D model is just one narrow type.
This matters because teams often wait too long to "start prototyping" when they have actually been doing it all along - or could have been. Recognising that a sketch is a prototype changes how quickly you start testing ideas.
The Dorado case study
To understand how prototypes progress in a real project, consider the Dorado - a robotic submarine developed in Canada by International Submarine Engineering. The engineers needed to design the movable control surfaces (called "planes") that keep the submarine near the water surface.
Their prototype sequence, in order from cheapest to most expensive:
Each step bought confidence to invest in the next one. Sea trials would have been reckless without the wind tunnel, water tank, and simulation work that preceded them.
How to classify a prototype
Any prototype can be placed on two dimensions:
- Completeness: from focused (captures only one or two aspects of the design) to comprehensive (a near-complete representation)
- Tangibility: from fully virtual (equations, simulations, renderings) to fully physical (scale models, the real device)
Most engineering projects use prototypes across all four quadrants of this grid. The progression generally moves from focused-and-cheap at the start toward comprehensive-and-expensive at the end.
Why prototypes progress over time
Early in a project, many ideas are still in play and the cost of changing direction is low. Use cheap, fast, low-fidelity prototypes. They explore, suggest, question, and provoke. They help you learn quickly.
Late in a project, most decisions have been made and the cost of changing direction is high. Use more comprehensive prototypes. They refine, describe, answer, and resolve. They confirm what earlier work suggested.
The cost-versus-time curve makes this concrete: early prototyping is cheap. Discovering the same problem in Stage 4 - after committing resources to a solution - is not. Every prototype is a question you're trying to answer cheaply before the answer becomes expensive.