Test

Designs used to be reviewed inside the team and handed to engineering. Everyone in the room nods, and it passes.

The trouble is that everyone in that room already knows the product. Knowing which button does what and what screen comes next makes any flow feel smooth. Put the same screens in front of five people seeing them for the first time and four of them stop on the second screen. The team looked at a layout; the user met an unfamiliar procedure, so the same picture produces two different experiences. Another review meeting does not close that gap, because the people in it cannot unknow the product.

Building stops here and only checking happens. The prototype made in the previous stage, over half a day or two days, is the material.

1. Meet about five people and give them tasks. The method is a usability test: don't ask what they think, watch them try. Asked for opinions, people produce plausible answers; asked to do something, they produce the place where they stall.
2. Split the facilitator from the note-taker. Alone, you lose the moment you just saw while thinking up the next question, and the moment is the finding.
3. The output isn't a verdict on the design but a list of stalling points, with numbers: how many of the five stopped where.
4. Going back a stage is normal. If only the screen is wrong, back to prototyping; if the direction of the solution is wrong, back to ideation; if it was never the right problem, back to define.

The defining trait is that one pass doesn't finish it. When three people stall in the same place, the next step is fixing it and meeting five more. Five people surface most of the serious problems, so teams add rounds rather than participants, and each round is cheaper than the one before.

"Four of five stopped on the second screen in testing."

Reporting the stalling point with a number attached, which is what makes it hard to argue with.

"Don't ask for opinions. Just give them the task."

What people are asked to do, rather than asked about, is the condition this method runs on.

"This isn't a screen problem. I think the problem statement is wrong."

We need to go back two stages rather than adjust a layout again.

Rebuilding the Pagedeck sharing flow, Noa met five people with eight paper screens. Four stalled at the permissions step, and all four stalled for the same reason: they expected different wording than "view only" and "can edit," closer to what their own company says. Mia took that result and revised the problem statement once.