A practical checklist for prototyping
Every audit we run turns up some version of this. Run through this the next time prototyping comes up.
Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The checklist
- A clickable prototype surfaces confusion no static mockup will
- Prototypes are for learning, not for reuse as production code
- Test with five people and you will find most of the problems
- Someone is named as the owner
- There is a date to review it again
Why it matters
A clickable prototype surfaces confusion no static mockup will. There is a version of this that is over-engineered, and it is worth avoiding. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
How to tell if yours is fine
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
- 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
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.