Test
Watch what happens. Let evidence guide the next move.
Testing is where the team learns early, while change is still easy. The prototype is a hypothesis. The test is what puts it in contact with reality. The questions are practical: who struggles with this, what surprises us, what changes the direction.
The hardest discipline is to believe the data when it disagrees with the story the team has already told itself. Most “the user just did not understand” findings are the team protecting its plan from contact with reality.
What you do
Recruit users who match the brief, not the calendar
"Who is available next week" is a sample of convenience. It gives you a partial signal. Find the right people, even if it takes longer.
Set up to observe, not to demo
The test is not a demo. Hand the user the prototype, ask them to do a thing, and give them room to think aloud.
Write down what surprised you
Surprises are the highest-signal data. A user who used a feature unexpectedly is teaching you about the model in their head.
Decide what to keep, change, or set aside
Each test should end with a written disposition for each prototype: keep, change, or set aside.
What you produce
Findings notes
Behaviors, surprises, severity-tagged issues. Quotes and clips where you have them.
Updated assumptions
Which of the bets from Define survived contact, which did not. Write both down.
A clear next direction
Either the prototype is good enough to take forward, or it is not, and you know exactly why.
AI sharpens analysis. Humans still hold judgment.
Use AI to cluster findings across sessions, surface patterns you might have missed, draft severity tags. It is excellent at the analytical labor that used to take a week.
Be skeptical of synthetic-user testing for anything that depends on emotional response. Models will give you plausible-sounding feedback, but plausibility is exactly the failure mode you should be testing against. Synthetic feedback can help structure a real test; it cannot replace one.
Watch for
Patterns that can make the work look farther along than it is.
Confirmation testing
Designing the protocol so users have to succeed. A test that cannot fail is not a test.
Leading the witness
"Don’t you find this easy?" is not a question. Phrase neutrally; let silence do the work.
Counting clicks, ignoring confusion
Quantitative passes that mask qualitative pain. Watch what users actually do, not just what they tap.
Ending without a decision
A test that produces "interesting findings" but no go/no-go forces the next stage to do the work twice.
A direction validated by evidence, or a clear reason to loop back to ideation. Either result is a win. The failure mode is shipping without knowing which one you have.