When prototyping is worth the effort
There is no clever trick in this one, just a handful of decisions worth making deliberately. Prototyping is not free, and pretending otherwise leads to bad decisions.
Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. It rarely shows up as a line item, which is exactly why it slips.
When it is worth it
A clickable prototype surfaces confusion no static mockup will. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
When it is not
If nothing downstream depends on it and nobody is complaining, it can wait. The teams that handle this well are rarely the ones with the biggest budgets.
How to decide
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. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
What this looks like day to day
The measurable part of design is whether people can find what they came for and act on it without hesitating. 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
Worth checking on your own setup before it becomes someone else's problem to fix.