Product prototyping: how to answer a real question in days

Every useful prototype exists to settle a specific disagreement. Write the question down first, in one sentence, with the answer you would act on.

Will people understand what this does within five seconds. Can someone complete setup without help. Does this feel fast enough to use daily. Is this technically possible at all. Those are four different questions and they want four different artifacts. Teams that skip this step build a thorough prototype of everything and learn nothing in particular.

Only the third and fourth need code. The mistake most often made by capable builders is jumping to a coded prototype for a comprehension question, which costs a week and answers something nobody asked.

Fidelity is not quality. It is a choice about what you are willing to fake. Get it wrong in either direction and the feedback becomes unreliable.

• Too low and people critique the sketchiness instead of the idea. Grey boxes invite comments about grey boxes.
• Too high and people stop questioning the direction, because it looks decided. Polish suppresses dissent.
• Real copy always. Placeholder text hides the single most common reason products confuse people.
• Real data shapes always. Names are longer than you drew, prices have edge cases, lists are empty on day one.
• Fake everything else with enthusiasm: no auth, no persistence, one hard-coded account, no error handling.

The fastest prototypes are honest about being hollow. Trouble starts when a prototype quietly becomes the foundation because it looked finished.

The cost of a working, clickable, coded prototype has collapsed. Something that used to be a week of front-end work is now an afternoon, which changes the economics: it is often cheaper to build the real interaction than to fake it in a design tool.

• Generate the scaffolding, then hand-work the two or three moments that decide the feel. That is where judgment still pays.
• Because output is fast, produce two or three genuinely different directions instead of refining the first one.
• Watch for the sameness. Generated interfaces converge on a house style; the differentiation has to be deliberately added.
• Speed makes it tempting to skip the question. It is still the only step that matters.

1. 01

   Five people, not fifty

   Five of the right people surface nearly every serious problem. Recruiting fifty is a research project, and it delays the decision by weeks.

2. 02

   Give a task, not a tour

   Say what they are trying to accomplish and stop talking. The instinct to explain the interface destroys the only data you came for.

3. 03

   Watch the hesitations

   Note every pause, backtrack and reread. Where someone hesitates is a design problem, whatever they say about it afterwards.

4. 04

   Separate what they did from what they said

   Behaviour is evidence. Opinions about future behaviour are conversation. Write them in different columns.

5. 05

   Decide the same day

   Fix the top three problems immediately and rerun. A prototype loop measured in days beats a research report measured in weeks.

Some prototype code is worth keeping. Most is not, and the decision should be made deliberately rather than by drift.

One practical middle path: keep the prototype as the specification. Screens, copy, states and timing carry straight into the build, while the throwaway plumbing gets rewritten properly.