Prototype

A prototype is the first artifact in a design process that can be handed over rather than presented. Somebody else holds it, taps something, and finds out where that lands. That is a different kind of evidence from an opinion about a picture: it produces the sentence “I thought this button would take me to my orders”, which no review of a still image ever produces, because a still image never took anybody anywhere.

What makes it affordable is how little of it is real. A screen is linked to another screen, so pressing a region swaps one for the other, and that swap is the entire mechanism. Nothing is stored, nothing is fetched, nothing is validated. The tells are always the same and they are worth recognizing on sight: the results list is the same row three times, the greeting has one hardcoded name in it, the search field accepts typing and returns identical results whatever you type, and one control on each screen goes somewhere while every other control is painted on. Fidelity is a separate axis from this and gets confused with it constantly. A prototype can be paper cut with scissors or a pixel-exact build, and either can be wired; what makes it a prototype is that a tap resolves, not how finished it looks.

Two prototypes usually get called the same word while doing opposite jobs. One exists to be tested, so it covers a single path in enough detail that a stranger can walk it unaided, and everything off that path is deliberately dead. The other exists to be approved, so it covers every screen shallowly and is walked by the person who built it, who knows which taps work. Handing the second kind to a usability participant is the common failure: they wander off the wired path within seconds, nothing responds, and the session becomes a study of the artifact rather than of the design.

Against its two siblings the line is clean. A wireframe and a mockup are both still pictures and differ from each other only by how much has been decided; a prototype is the one that answers input, which is a difference in kind rather than in finish. The cost of that difference is what teams underestimate: a wired flow needs states a picture never had to have, so the pressure is always to wire the happy path and let the empty, error and loading cases stay unbuilt, which is exactly where a real reader ends up. It is also the one of the three that is hardest to hand off, because the wiring lives in the prototyping tool and none of it survives into code.