How to get prototyping right
The advice here is unglamorous, which is probably why it gets skipped. The short answer to prototyping is that it is mostly a sequence of small decisions, not one big one.
Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. If it only works because one person remembers to do something, it does not work yet.
What it costs to ignore
A clickable prototype surfaces confusion no static mockup will. None of that requires a large budget, only a decision and someone to own it. It is the sort of thing that looks like polish right up until it costs you an enquiry.
The steps
- Establish what you have today before changing anything
- Prototypes are for learning, not for reuse as production code
- Test with five people and you will find most of the problems
- Write down the decision so the next person does not re-litigate it
Test with five people and you will find most of the problems. There is a version of this that is over-engineered, and it is worth avoiding. Assume whoever inherits this will have half your context and none of your patience.
A reasonable first step
In practice
Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. Three things worth confirming about prototyping before you move on:
- Someone can say what the current setup is without going to look
- A clickable prototype surfaces confusion no static mockup will — and you know whether that is true here
- There is a way to tell whether the last change to this helped
The point is not perfection, it is knowing which of these you have consciously chosen to skip.