Prototyping: the questions we get asked most

Teams tend to reach for this after something has already gone wrong. The questions about prototyping that come up most often on our calls.

The measurable part of design is whether people can find what they came for and act on it without hesitating. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Do we need to care about this?

A clickable prototype surfaces confusion no static mockup will. The teams that handle this well are rarely the ones with the biggest budgets. The version that survives contact with a real deadline is the simple one.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Test with five people and you will find most of the problems. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

The short version

Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. 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

Most of the value here comes from doing the first two things, not all of them.