How many users for usability testing: the 5-user rule is an average, not a floor

How many users for usability testing is nearly always answered with five, and the reason given - five users find 85% of the problems - is a curve's output, not a measurement of anything. When a researcher drew real five-person samples from a 60-person study, coverage ran from 99% of the known problems down to 55%. The useful question is which decision your test has to support.

Where the 85% figure for five users comes from

It comes from a model. Jakob Nielsen's March 18, 2000 article predicts problems found as N(1-(1-L)^n), "where N is the total number of usability problems in the design and L is the proportion of usability problems discovered while testing a single user". Nielsen puts the typical value of L at 31%. Feed L=31% and n=5 into that expression and it returns about 84%, which is where the familiar 85% lives. Your product never entered the arithmetic.

The article's actual recommendation is the part that gets dropped. Nielsen did not advise running one five-person study and shipping; he advised splitting the budget - "Spend this budget on 3 studies with 5 users each!" - and redesigning between them. In that argument five is a per-round batch size inside a loop, and the 85% is the first lap. Quoting the 85% while skipping the loop inverts the point.

Two assumptions hold the curve up. Every problem must be equally likely to surface, and every user must be an independent draw with the same 31% discovery rate. Neither is true of a particular product with a particular task set, which is why the empirical check matters more than the formula.

How many users for usability testing holds up when you sample real people

Laura Faulkner ran the check. In Beyond the five-user assumption, published in Behavior Research Methods, Instruments, & Computers in 2003, she tested a software application with 60 users, then drew random samples of five or more from that pool to see what a single small test would have caught. Some five-person sets found 99% of the usability problems the full group found. Others found 55%. With 10 users, the lowest share any sample revealed rose to 80%; with 20 users, to 95%.

Read the ceiling carefully. Those percentages are shares of the problems the 60-person study itself surfaced, not of every problem in the software, and they describe one application and one task set. What the numbers do settle is the spread: five users is a point drawn from a wide distribution, and you never learn which end of it you drew. In our view that is the single most useful fact about sample size, and it is the one the rule of thumb hides.

Why the spread is that wide is worth a sentence, because it tells you when to worry. A test's coverage depends on how the problems are distributed: a design whose faults are mostly blocking, obvious and hit everyone will look fine with five people, while one whose faults depend on a user's data, role or path will not. You usually know which kind you have before you recruit. Complex flows, permissions, imported data and anything with an admin view are the cases where the floor, not the average, is the number to plan against.

The percentage has a denominator that moves

"Share of problems found" assumes everyone agrees what the problems were. They do not. Jeff Sauro's review of 33 studies for MeasuringU, published March 28, 2018, reports that the "median any-2 agreement across these 33 studies is 27%", "ranging from a low of 4% to a high of 75%" - that is, pick two evaluators who watched the same sessions and they typically share about a quarter of their problem lists.

So a coverage percentage is relative to whoever wrote the list. Two consequences are worth acting on. Have a second person watch or code the sessions, because a solo analyst's list is demonstrably partial. And write the raw observations down before anyone argues about severity, so the two lists can be compared instead of merged by the loudest voice.

Choose the number from the decision, not from the rule

Iterating on a design: five per round, and more than one round

If the point is to find problems and fix them, Nielsen's original structure is in our view still the cheapest option here: small batch, fix, repeat. Three rounds of five uses the same fifteen participants as one large round, and tests three designs instead of one. If five is genuinely all you can recruit in total, spend them one at a time rather than in a block: run one session, fix the thing that stopped them, and let the next participant test the fix. You lose comparability across sessions, which is a real cost if you wanted to count anything, and you gain five consecutive designs instead of one verdict. Skip this if you cannot actually change the design between rounds - then you are documenting, not iterating, and documenting is a measurement job with different sample sizes.

Several distinct user groups: three or four each

Nielsen's 2012 summary, How Many Test Users in a Usability Study?, is explicit that the five applies per behaviorally distinct group, and that because groups overlap you can usually drop to three or four per group. His own example is a financial site with novice, intermediate and experienced investors: three of each, nine users in total. A B2B tool with an admin, an end user and a buyer is the same shape - budget for nine, not five.

Hunting a problem only some users hit: do the arithmetic first

The formula that produced 85% is also the fastest way to see when five is hopeless. A problem that 31% of users trip over has a 1-(1-0.31)^5 chance of appearing in a five-person test, which is about 84%. Run the same arithmetic for a problem only 10% of users hit and five users give you 41%, ten users 65%, and twenty users 88%. That is arithmetic from Nielsen's own expression, not new evidence - but it shows which number to raise when the bug you are chasing is a corner case rather than a wall.

Measuring anything: twenty is the floor, and the margin is still wide

Numbers - task success rates, time on task, a System Usability Scale score - need a different sample size than problem finding. In Quantitative Studies: How Many Users to Test?, published June 25, 2006, Nielsen recommends testing with 20 users and is blunt about what that delivers: at a 90% confidence interval, "the margin of error is +/- 19% for testing 19 users". Ten users gives roughly plus or minus 27%. Getting to plus or minus 10% takes about 76 users, which he judges a poor use of most budgets. If someone is going to quote your number in a planning meeting, quote the interval with it.

The 2012 article sets two more method-specific floors worth knowing: at least 15 participants per user group for card sorting, and 39 for stable eyetracking heatmaps. A five-person sample is a usability-test convention, not a research-wide one.

What each sample size costs in tools and recruiting

Sample size is a budget line, and the plan limits in UX research tools are drawn around roughly these numbers. Useberry, listed in our UX & Research category, caps its free plan at "10 responses / month" with one project, and its Growth plan at €83 per month billed yearly for "300 responses / month" plus five interviews a month, according to its pricing page as of October 23, 2026. A single five-user unmoderated round fits the free tier; a 20-user quantitative study every month does not.

Recruiting is the other half. Prolific charges a participant reward you set plus a platform fee that its pricing page describes as "usually 42.8% for corporate customers" and "a discounted 33.3% for academic or non-profit customers", with a floor of "the minimum pay allowed is £6.00 / $8.00 per hour" and a recommendation to pay at least £9.00 / $12.00 per hour, checked on October 23, 2026. Multiply that out for a 15-minute study at the recommended rate and 20 participants cost about $60 in rewards and roughly $86 all-in at the corporate fee - our arithmetic from their published figures, not a quote from them.

Two practical notes on the spend. Moderated sessions cost your time rather than response credits, so the cheap way to reach ten users is often two five-person rounds a week apart. And prices and plan limits on both pages change; re-read them before you build a budget on this paragraph. Upfynd lists 142 products in UX & Research and 374 in design tools as of October 2026, so there is no shortage of alternatives if a plan limit lands in the wrong place for your sample size.

What we would do, and what we would stop saying

In our view the defensible default is five participants per round for three rounds when you are fixing a design, twenty or more when a number will leave the room, and three to four per group whenever the audience splits into groups that behave differently. We would also have two people write up every session set, given how little independent evaluators agree.

The sentence we would retire is "we tested with five users and found 85% of the problems". Faulkner's data makes that a claim about an average you cannot verify for your own test, and the evaluator-effect numbers make the denominator soft. "We ran five sessions, fixed what we saw, and ran five more" is smaller, true, and harder to argue with. We applied the same habit to another number the craft repeats without checking it in our piece on vertical video safe zones.

Before you pick a number for your next study, write down the sentence you want to be able to say when it ends. If that sentence contains a percentage or an average, you are measuring and need twenty-plus. If it names a problem you are going to fix next week, five is enough - this week.