Usability testing when you have no research budget

Small studies find most problems

Testing with five to eight people per round surfaces the large majority of usability problems, and repeating in rounds finds more than one large study. The value comes from iterating, not from sample size.

This is a research result that consistently surprises teams who assume statistical significance is required. For finding problems, it is not; for measuring preferences, it is.

Ask people to do things

Do not ask whether the interface is clear — people are polite and are poor at predicting their own behaviour. Give them a realistic task and watch.

• Frame tasks as goals, not instructions: “find out when your order arrives”, not “click Orders”.
• Stay quiet. The silence is uncomfortable and it is where the findings are.
• When asked for help, respond with “what would you do if I were not here?”
• Note what they do, not only what they say.

Recruit people close enough

Perfect recruitment is expensive. People who resemble your users in relevant ways — domain familiarity, technical confidence — will find most interface problems.

Existing customers, people from another department, or a recruitment service for specialist audiences all work. Testing with your own team finds only the most obvious issues, because they know too much.

Turn findings into tickets

A research report nobody reads changes nothing. Write each finding as a specific problem with evidence and a suggested change, and put it in the backlog alongside other work.

Recording short clips of the moments where people struggled is the most persuasive artefact available. Watching a real person fail at a task ends debates that argument cannot.

Analysing what you saw

The value of a session is lost if findings are not captured while fresh. Debrief immediately after each participant and note the three most significant observations before moving on.

Group observations across participants rather than reporting person by person. A problem two of five people hit is a pattern; a problem one person hit may be a pattern or may not, and the next round will tell you.

Distinguish observations from interpretations. “Three participants scrolled past the button” is an observation; “the button is not prominent enough” is one possible explanation among several.