Usability testing on a budget

Short version: usability testing doesn't need a lab or a budget line. Give five realistic people a realistic task, watch them try to do it, and stay quiet. You'll find most of your serious problems in an afternoon. The discipline isn't in the tooling — it's in giving tasks rather than asking opinions, resisting the urge to help, and actually fixing what you observe.

Teams postpone user testing because they picture something expensive: a facility, mirrored glass, a recruitment agency, a research specialist. That version exists, and it's excellent, and you don't need it to learn that nobody can find your pricing page. Most of the value comes from a laptop, a willing stranger and forty-five minutes.

Five people is enough

The single most freeing fact in this field: a small number of participants uncovers the large majority of usability problems. Serious flaws aren't subtle — if the checkout button looks like a label, roughly everyone will stumble on it. Beyond a handful of sessions you start hearing the same things again. So run five, fix what you found, and run five more on the improved version. Two small rounds teach you more than one big one, because learning is only useful if something changes between rounds.

Give tasks, not questions

This is where most sessions go wrong. "What do you think of this screen?" produces politeness. "You need a refund for the blue jacket you bought last week — go ahead" produces truth. Write three to five tasks that mirror why people actually open your product, phrase them in the user's language rather than your feature names, and hand them over one at a time.

Then the hard part: say nothing. When someone stalls, the instinct to point at the right button is almost physical. Resist it — that stall is the finding. If you must speak, ask "what are you trying to do right now?" or "what did you expect to happen?" Never ask "would you use this?", because everyone says yes to a person's face.

A workable format

Recruit realistically. Existing users, waiting-list signups, people in a relevant community, or customers of a shop that serves the same audience. Offer a small thank-you — a voucher is enough.
Test remotely. A screen-share call is fine and removes travel from both sides. Record it, with permission.
Bring an observer. One person facilitates, one takes notes. Anyone who hasn't watched a real user struggle should be the note-taker at least once.
Test what exists. Prototypes, sketches on paper, a half-built page — all work. Waiting for polish means testing after the expensive decisions are locked in.

If a user can't work out what to do, that's never their mistake. It's a design finding.

Turning notes into changes

After each session, write down the three moments where the participant hesitated, went the wrong way or said something surprising. After five sessions, look for repeats — anything that happened to three or more people is a genuine problem, not a quirk. Rank by how badly it blocks the user's goal, fix the top few, and test again. Findings that never turn into changes are an expensive way to feel diligent.

Key takeaways

Five participants per round finds most serious usability problems.
Give realistic tasks in the user's words; never ask for opinions.
Stay silent when they struggle — the struggle is the data.
Test early and rough; waiting for polish means learning too late.
Anything that trips up three or more people is real. Fix it, then retest.

Frequently asked questions

How many people do I need to test with?

Around five per round is the well-established sweet spot. A handful of participants surfaces the majority of serious usability problems, and additional people mostly repeat what you've already seen. Two rounds of five beats one round of ten, because you fix things in between.

Can I test with friends and colleagues?

Colleagues are a poor substitute — they know too much about the product and want you to succeed. Friends outside your industry are better than nothing for spotting confusing language. Real prospective users are best, and are usually easier to recruit than teams expect.

What should I actually ask participants to do?

Give them realistic tasks, not questions about opinions. "Buy a gift for a friend under £30" tells you far more than "do you like this page?" Then stay quiet and watch where they hesitate, backtrack or misread something.

ZIVARA designs and tests products with the people who'll use them. Let's talk. Related: UX mistakes that drive users away and onboarding flows that keep users.