Product teams spend a remarkable amount of time discussing things nobody has tried. Should onboarding be three steps or five? Will users find the filter? Is the pricing page clear? Each opinion is reasonable, and none of them is evidence.
Match the fidelity to the question
A prototype is a question made tangible, and its fidelity should match the question. Whether people understand the structure of an app can be tested with grey boxes. Whether they trust a checkout needs something closer to finished, because trust depends on the details.
Building more fidelity than the question needs is a common way to waste a week. It also makes people reluctant to throw the work away when the test says they should.
Test with people outside the building
Everyone inside a company knows too much. They know what the product is for, what the icons mean and where things are supposed to be. The most useful testers are people who match the audience and have no idea what the team intended.
Five sessions are often enough to find the biggest problems. By the fourth or fifth person, the same stumbles repeat, and the team rarely needs a sixth to be convinced.
Give tasks, not tours
A test that walks someone through the screens teaches very little. Asking them to do something real, find a plan that fits a family of four, change a delivery address, cancel a subscription, and then watching quietly shows where the design fails.
The hardest part for the team is not helping. The pause while someone looks for a button is the most valuable data in the session.
Watch what people do, not what they say
People are polite about prototypes. They say a design is clear while taking a minute to find the main action. They say they would use a feature they never touched. Behaviour is the finding; opinions are context.
Prototype the hard parts too
It is tempting to prototype only the ideal journey. The decisions that cause problems later live elsewhere: what happens when there is no data yet, when a payment fails, when someone has two hundred items instead of three. Those states deserve a prototype before they deserve a debate.
Let the prototype change the plan
A test is only useful if it can change what gets built. The best time to prototype is before a roadmap is committed and before engineering estimates harden into promises. Changing a prototype takes an afternoon. Changing shipped software takes a quarter.
