Prototype

A prototype is a version of a design you can click through. The pages are not real and nothing behind them works, but the buttons go somewhere, so a person can be handed it and asked to complete a task. That is the whole purpose: it tests behaviour, which pictures cannot, before anybody has written the code that would make behaviour expensive to change.

In short

• Clickable, so it tests the journey rather than the appearance.
• Nothing in it works. No data, no payments, no real search.
• Its value is watching somebody use it, not showing it off.
• Built to be thrown away once the question is answered.

What it answers that the earlier stages cannot

Design arrives in a rough order, and each stage answers a different kind of question.

A wireframe answers what goes on the page and in what order of importance. A mockup answers what it looks like once the colours, type and photographs are applied. Both are static, and both are perfectly capable of hiding a fault.

The faults they hide are the ones that only exist between pages. How many steps the checkout actually takes when a customer wants to change the delivery address, and whether those extra steps are where baskets get abandoned. Whether somebody who mistyped their mobile number can work out what to do about it. Whether the path from a product to a completed order ever loops back on itself. None of that is visible in a picture of a page, because none of it happens on a page. It happens in the movement between them.

That is the gap a prototype exists to close, and it is why the question it answers is a verb, not a noun.

Watching, not asking

A prototype that only gets presented has been half wasted, and this is the most common way the work fails to pay for itself.

The temptation is to demonstrate it. Somebody walks a client through the screens, narrating what happens, and everyone agrees it looks good. Nothing has been learned, because the person who built it was driving.

The version that pays is a task. Hand the link to somebody who resembles a customer, give them something to accomplish, and then say very little. Where they pause, what they click that was never meant to be clicked, and the moment they ask what to do next are the findings. All of them are cheap to fix in a prototype and considerably less cheap once the site is built, which is the entire economic argument for the stage existing.

Five or so people will surface most of what is badly wrong. Beyond that the same problems repeat, and the sensible move is to fix them and test again rather than to keep recruiting.

The hazard of looking finished

A good prototype creates a problem the earlier stages never do, and it is worth naming before it happens.

It looks like a website. It opens in a browser, it responds to clicks, and to anybody who has not been part of the process it appears to be very nearly done. The reasonable question that follows is why launch is still weeks away, and the answer, that none of it is connected to anything, is difficult to believe while looking at something that plainly works.

Two habits keep this from becoming a disagreement. Say what the prototype does not do before showing it, specifically that there is no real data, no stock, no payments and no live search. And match the fidelity to the question. A rough prototype invites comment on the flow, which is what you wanted. A polished one invites comment on the shade of a button, which the mockup stage already settled, and it signals that decisions are further along than they are.

Words you will hear

• Fidelity. How closely it resembles the finished thing. Low fidelity invites bigger comments, high fidelity invites smaller ones.
• Hotspot. A clickable region drawn over a static screen.
• Flow. The sequence of screens for one task, such as booking or checking out.
• Happy path. The route taken when nothing goes wrong, and the only route most prototypes cover.
• Edge case. Everything else, which is where journeys usually break.
• Usability test. A person given a task while somebody watches. The activity a prototype exists to support.
• Coded prototype. A rough working version built in real code, used when the question is technical rather than about user experience.

When to skip it

Not every project needs one, and pretending otherwise adds a stage that produces a file nobody opens.

Skip it when the site is a handful of pages with no multi-step task in it. The navigation is the journey, and the wireframes have already shown it. Skip it when the flow is one you have built before and nobody is arguing about it.

Insist on it when money changes hands, when a form has more than one screen, when two people in the room disagree about the order of steps, or when the site is replacing something that customers already complain about. In that last case the prototype has a job before it has an audience, which is to prove that the new route is genuinely shorter than the old one rather than differently shaped.