Getting started with prototyping
We end up explaining this on discovery calls often enough that it deserved writing down. A short on-ramp to prototyping for teams who have not touched it before.
Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Why it matters
A clickable prototype surfaces confusion no static mockup will. This is the sort of thing that compounds, quietly, in both directions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
Your first week
- Find out what is already in place
- Prototypes are for learning, not for reuse as production code
- Change one thing and measure it
Test with five people and you will find most of the problems. Small and consistent beats large and occasional here. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The short version
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
Worth checking on your own setup before it becomes someone else's problem to fix.