Prototyping, explained without the jargon

It comes up on almost every project, usually later than it should. Here is prototyping without the vocabulary that usually surrounds it.

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. If two people in the business would answer this differently, that gap is the actual problem.

The short version

A clickable prototype surfaces confusion no static mockup will. The cost of getting this wrong is rarely visible on the day it happens. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. This is the sort of thing that compounds, quietly, in both directions.

Prototypes are for learning, not for reuse as production code. Getting it slightly wrong is survivable. Ignoring it entirely is not. Check it against what you would want a competitor's site to get wrong.

Where to go from here

Test with five people and you will find most of the problems. The cost of getting this wrong is rarely visible on the day it happens. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

The measurable part of design is whether people can find what they came for and act on it without hesitating. Three things worth confirming about prototyping before you move on:

• Someone can say what the current setup is without going to look
• Prototypes are for learning, not for reuse as production code — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.