Five mistakes teams make with prototyping
It comes up on almost every project, usually later than it should. These are the ones we run into repeatedly when we audit prototyping.
The measurable part of design is whether people can find what they came for and act on it without hesitating. Budget a little time for it every quarter and it never becomes a project of its own.
Where it usually goes wrong
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- A clickable prototype surfaces confusion no static mockup will
- Prototypes are for learning, not for reuse as production code
- Never checking whether the fix actually worked
Test with five people and you will find most of the problems. 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.
A reasonable first step
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 want a second opinion on how yours is set up, ask.