Prototype

A prototype is a working approximation of a product or feature, built to answer a question before the real thing is constructed. Prototypes range from paper sketches manipulated by hand, through clickable screens linked in a design tool, to functional code running against real data. What unites them is intent: a prototype exists to be evaluated and discarded or revised, not to be shipped.

The essential discipline is deciding what question the prototype must answer, because that determines the fidelity required. To learn whether people understand a navigation structure, a set of linked static screens is sufficient. To learn whether an interaction feels responsive enough, a coded prototype with real timing is necessary because no static artifact can convey it. To learn whether a complex data table is usable, realistic data volumes are essential, since a table that works with ten rows may be unusable with ten thousand. Building more fidelity than the question requires wastes time; building less produces answers that do not transfer.

Prototypes are most valuable for questions that cannot be settled by discussion. Teams can argue indefinitely about whether a flow is too long, whether a concept is comprehensible, or whether an interaction is discoverable, and no amount of debate resolves it because everyone is reasoning from their own mental model. Putting an approximation in front of five people who match the target audience typically settles the argument within a day, and frequently reveals that both positions were wrong for reasons nobody anticipated.

The main risk is that a prototype becomes the product. A convincing prototype attracts pressure to ship it, particularly under deadline, and code written to answer a question is rarely code written to be maintained: no error handling, no accessibility, no edge cases, no tests. Organizations that repeatedly promote prototypes to production accumulate technical debt in the least visible way possible. Treating prototype code as explicitly disposable, and saying so before building it, is the only reliable protection.

A second risk is over-investment. Prototypes that take weeks to build carry the same emotional weight as finished work, and teams become reluctant to abandon a direction they have spent significant effort representing. The value of prototyping comes from being able to discard cheaply, which means speed is a functional property rather than a convenience. If a prototype takes longer to build than the feature would, the question should have been answered another way.

There is also a useful distinction between prototypes built to explore and prototypes built to communicate. An exploratory prototype is rough, private to the team, and discarded once the question is answered. A communication prototype is built to demonstrate a proposed direction to stakeholders or to specify behavior for implementation, and it needs to be more complete and more polished because it will be interpreted literally. Confusing the two causes predictable problems: exploratory work shown to executives is read as a commitment, and communication prototypes built with exploratory looseness leave developers guessing about states and edge cases that were never considered. Deciding which kind is being built, and saying so when presenting it, prevents most of that confusion.

In practice, prototyping sits at the junction between design and delivery, and its output is a decision rather than an artifact. In a product design engagement, prototypes are used to validate concepts with real users before specification, while in product development they are also used to de-risk technical assumptions about feasibility, performance, and integration before committing to an architecture. Keeping those two purposes distinct matters, since a prototype that answers a usability question and a prototype that answers a technical one rarely need to be the same thing.