Usability testing with five users and a small budget
You do not need a lab or a large panel to learn what is wrong with an interface. A lean testing method that fits into a normal sprint.
Usability testing has a reputation for being expensive and slow: recruiting agencies, lab rentals, weeks of analysis and a thick report nobody reads. That version exists, but it is not the one most teams need. For most product and website decisions, five participants, a clear set of tasks and a few days of work will reveal the majority of serious problems in an interface. We run lean tests like this on nearly every project, and they consistently change what we build.
Why five is usually enough
The reasoning is straightforward. Serious usability problems tend to affect a large share of users, so they show up early. By the third or fourth participant, you are mostly seeing the same issues again. Five participants per round, drawn from one user group, typically surface most of the problems that matter. The exception is when you have distinct user groups with different goals, such as buyers and sellers, or clinicians and patients. Then you need a small round for each.
The point is not statistical confidence. Qualitative testing finds problems; it does not measure how often they occur. If you need to know what percentage of users fail a task, you need a larger quantitative study. For deciding what to fix, five is plenty.
Write tasks, not questions
The most important preparation is writing realistic tasks. A task gives the participant a goal and lets them work out how to reach it, which reveals where the interface helps and where it gets in the way.
- Good: "You are looking for a waterproof jacket for hiking under 200 dollars. Find one you would consider buying."
- Weak: "Use the filters to find a jacket." This tells them which feature to use.
- Weak: "What do you think of the homepage?" This invites opinion rather than behavior.
Aim for four to six tasks that cover the most important journeys, ordered roughly as a real user would encounter them. Pilot the script with a colleague to check timing. Sessions should last 30 to 45 minutes; beyond that, participants tire and data quality drops.
Watch what people do, not what they say they would do. Behavior is the data; opinions are context.
Recruit and moderate
Recruiting
Participants should resemble real users in the ways that matter for the tasks: domain knowledge, frequency of use and device. For consumer products, remote testing platforms can supply participants within a day or two. For specialist or B2B products, the client's own customer list is usually the best source, with a modest incentive. Screen out people who work in design, marketing or tech, since they behave differently.
Moderating
Remote moderated sessions over video with screen sharing work well and remove travel costs. The moderator's job is to set participants at ease, explain that you are testing the interface rather than them, and then mostly stay quiet. Encourage thinking aloud, and when participants get stuck, ask what they expected to happen rather than helping. Resist the urge to explain the design. Every explanation you give is a problem you just hid from yourself.
Invite the product team to observe live. Nothing builds agreement on what needs fixing faster than watching a real customer struggle with something the team considered obvious.
Record every session, with consent, and keep the recordings organized by participant and task. Short clips of key moments are the most persuasive artifact you will produce. A thirty-second clip of a customer failing to find the pricing page settles debates that hours of meetings could not.
Synthesize quickly and specifically
Analysis should take days, not weeks. Immediately after each session, observers write down the problems they saw, one per note, with the task and a timestamp. After the last session, group the notes by issue and count how many participants experienced each one.
Rate each issue by severity:
- Critical: prevented task completion.
- Serious: caused significant delay, errors or frustration.
- Minor: noticeable friction that did not affect outcome.
The output should be a short, prioritized list, with a clip or quote for each major issue and a proposed fix. A two-page summary with video clips gets read and acted on. A forty-page report does not.
Test early and test again
You do not need a finished product to test. Clickable prototypes, even low-fidelity ones, reveal navigation, labeling and flow problems before any code is written, when fixes are cheapest. Our wireframing and prototyping work is built around this, with a round of testing before visual design begins.
The real value comes from iteration. Test, fix the top issues, then test again with five new participants. The second round confirms whether fixes worked and reveals problems that were hidden behind the first set. Three rounds of five participants almost always teach more than one round of fifteen.
Keep a running log of findings across rounds and projects. Patterns emerge over time, such as recurring confusion about a particular term or a navigation label that never works, and those patterns are valuable input for the next redesign or the design system.
A lean round, including recruiting, five sessions and a synthesis workshop, typically takes one to two weeks. We offer usability testing as a standalone service and as part of broader UX research programs, and we often train client teams to run their own rounds afterward so the habit continues without us.
Put your interface in front of real users
If a redesign or new feature is about to launch untested, a single round could save months of rework. Request a fixed-price testing proposal and receive it within 24 hours.
