Khushi Bhut
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.
