Prototyping for small teams

There is no clever trick in this one, just a handful of decisions worth making deliberately. Most advice about prototyping assumes a team that does not exist at your size. Here is the version that does not.

Design decisions are the ones clients feel most confident arguing about, which makes it worth separating taste from evidence early. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to keep

A clickable prototype surfaces confusion no static mockup will. The teams that handle this well are rarely the ones with the biggest budgets. It rarely shows up as a line item, which is exactly why it slips.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. This is the sort of thing that compounds, quietly, in both directions.

The practical version

Test with five people and you will find most of the problems. This is the sort of thing that compounds, quietly, in both directions. If it only works because one person remembers to do something, it does not work yet.

The short version

Consistency is the quiet half of design work: it rarely gets complimented, and its absence is noticed immediately. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.