When we suggest usability testing before a big feature ships, the most common pushback isn't “we don't have budget” — it's “five people isn't a real sample size.” It's a fair instinct, but it misunderstands what usability testing is actually measuring. We're not trying to prove a statistical claim about your entire user base. We're trying to find where people get stuck, and that shows up fast.
Why the number five isn't arbitrary
The pattern we see over and over: the first user hits a confusing step and struggles with it. The second user hits the exact same step. By the third or fourth, we're not learning much new — we're watching the same friction point repeat. Research on this goes back decades at this point, and our own sessions consistently confirm it: most usability problems are found by the first handful of testers, and each additional participant after that finds diminishing new issues relative to the added time and cost.
That doesn't mean five is right for every situation. If you're testing a feature meant for several genuinely distinct user groups — say, both first-time buyers and repeat business customers with different goals — you want five from each group, not five total. The number scales with how many meaningfully different audiences you're serving, not with how confident you want to feel about the results.
How we actually run these sessions
We keep it simple: a clickable prototype, a short list of realistic tasks (“find and book a consultation,” not “click the blue button”), and a facilitator who says as little as possible. The instinct to jump in and explain is the biggest risk to a good session — if a tester is confused, that confusion is the finding, not something to smooth over in the moment.
We record the sessions and watch for hesitation as much as outright failure. A user who eventually completes a task but pauses for ten seconds staring at a button has just told you something real about your interface, even though technically they “succeeded.” Those near-misses are often more useful than the outright failures, because they're the ones a client's internal team would never catch just by using the product themselves — everyone on the inside already knows where to click.
For a client on a tight budget, five short sessions run in an afternoon consistently catch the issues that would otherwise surface as support tickets and drop-off in analytics months after launch, at a fraction of the cost of fixing it live. It's one of the highest-value, lowest-cost steps in the process, and it's the one that gets skipped most often when a deadline is tight.
Testing early, not just before launch
The other habit we push clients toward is testing a rough prototype, not a polished one. A clickable wireframe with placeholder text and no visual design is enough to run a real session, and it's far cheaper to change at that stage than after visual design and development are already invested. Waiting for a “finished-looking” prototype before testing tends to mean testing too late to change anything meaningful without pushback about wasted work.
We also try to test with people who actually resemble the target user, not just whoever's easiest to grab — a coworker who already understands the product's internal logic isn't a stand-in for a first-time visitor. It doesn't need to be a formal recruiting process; even five people found through a client's existing customer list or a quick social post asking for volunteers is usually enough to get a genuinely useful read.
What we do with the findings afterward
A session is only as useful as what happens after it. We write up findings the same day, while the specific moment of hesitation or confusion is still fresh, rather than batching notes from five sessions into a single summary a week later where the details blur together. Each finding gets tied to the specific task and the specific point in the flow where it happened, not a vague “users found the checkout confusing” — vague findings are the ones that get argued away in a design review instead of acted on.
We also triage findings by severity before presenting them, separating “this blocked someone from completing the task” from “this caused a brief pause but they recovered.” Not every finding needs an immediate fix, and presenting a flat list of ten issues with no prioritization tends to overwhelm a client team into inaction. Two or three high-severity fixes, clearly tied to a specific moment in a specific recorded session, get acted on. Ten undifferentiated notes usually don't.
When five isn't the right number after all
We've also learned to recognize the specific situations where the five-user guidance doesn't hold. Testing a completely novel interaction pattern — something users have no existing mental model for — tends to produce more scattered, individual reactions than testing a familiar pattern like a checkout flow, and scattered reactions take a larger sample to find real patterns in. Similarly, if the first five sessions produce wildly inconsistent results with no overlap in where people struggled, that's a signal to run five more rather than conclude the research early — it usually means the task itself was ambiguous, or the recruited testers weren't representative of the real audience.
The discipline that matters more than the exact number is watching for when you've stopped learning anything new, and being honest with yourself about whether that's because the interface is solid or because the testing method itself has a blind spot. Five is a reliable starting point, not a rule to follow mechanically regardless of what the sessions are actually showing you.
