Usability Testing on a Budget
Most designers who never test say the same thing: "We don't have the budget." What they usually mean is "We don't have a lab, a recruitment agency and a six-week timeline." None of those are required. Usability testing at its core is astonishingly cheap: five people, one script, a quiet hour, and the discipline to keep your mouth shut while someone struggles with your design. This guide is a fully practical process you can run this week for almost nothing.
Why five users is genuinely enough
The classic research finding is that a small number of participants surfaces the large majority of serious usability problems, and that diminishing returns kick in fast. After roughly five users on a given task set, you keep seeing the same handful of issues rather than new categories of them. The practical implication is not "test once with five and never again" — it is "run several small tests at different stages" rather than one enormous expensive study at the end.
Five users per round, three rounds across a project, beats one round of fifteen. You iterate between rounds, so each round tests a different design rather than the same broken one fifteen times.
Test early with a rough prototype and you will find problems while they are still cheap — a moved element, a renamed button. Test the finished, polished build and the same problems cost you a redevelopment cycle. The value of testing falls the later you do it.
Recruiting without an agency
You do not need perfect participants. You need people who resemble your users closely enough to hit the same walls. Cheap recruitment options, roughly in order of ease:
- Existing customers or users. Ask them directly; they already care and often enjoy being consulted.
- Your own network — friends, colleagues in adjacent teams, family — as long as they are not the design team.
- A community group, meetup or forum relevant to the product's domain.
- A short screening form of five questions to filter out people who are too close to the project or the wrong audience.
Offer a modest incentive — a gift card in the range of 25–75 in your local currency is standard for an hour of someone's time. Even this is optional when you are testing with colleagues, but paying strangers fairly is both ethical and improves turn-up rates. Over-recruit by one or two people; in my experience roughly one in five no-shows.
Write a five-task script
The script is where amateur tests go wrong. Do not write tasks that describe your interface. Write tasks that describe a goal, and let the participant figure out the path. This is the single most important rule in usability testing.
| Avoid (leading) | Use instead (goal-based) |
|---|---|
| Click the blue "Export" button | Save this report so you can share it with a colleague |
| Use the search bar to find a laptop | You want to buy a laptop — find one you would consider |
| Fill in the sign-up form | Create an account so you can place an order |
Five tasks is the right number for a one-hour session once you allow for setup, thinking time and a short debrief. Order them easiest-to-hardest so the participant builds confidence, and always start with a warm-up that is not being scored — "Tell me what you make of this page" — to settle nerves.
Moderating: shut up and watch
Moderating is mostly a discipline of restraint. The temptation to rescue someone who is stuck is overwhelming, and it destroys your data. Every time you hint, the next participant's difficulty becomes invisible. Your job is to observe, not to teach.
A moderation rhythm that works:
- Read the task. Then stop talking.
- Stay quiet for 10–15 seconds when they hesitate. People often talk themselves out of a stumble.
- Probe after, not during. When they finish, ask "What were you thinking there?" rather than interrupting mid-flow.
- Ask open questions. "Tell me what you expected to happen" beats "Did you find that confusing?" — which invites a yes or a polite no.
- Never explain the design. If they misunderstand it, that is the finding.
Metrics worth recording
With small samples, do not pretend to have statistically rigorous numbers. Record observations that a small set can genuinely support: task success, task failure, hesitation, and — most valuable of all — the exact words and moments where confusion happened. A single clear quote ("I didn't know if this had saved") is worth more to a stakeholder than a percentage.
Lightweight things to capture per task: succeeded / struggled / failed, the time it roughly took, and one sentence of what went wrong. A table of five participants across five tasks gives you twenty-five quick signals you can cluster into themes.
Tools that cost little or nothing
You do not need a purpose-built testing platform. A video call with screen sharing and a simple screen-recording tool captures everything you need. Keep a spreadsheet open for notes in a second column. If a session must be remote, that is fine — moderated remote testing is standard practice and often finds problems in-person sessions miss, because people are naturally at ease in their own space.
For note-taking, use the classic two-column layout: on the left, what the participant did and said (observation); on the right, what you think it means (interpretation). Keeping them separate stops you from dressing up your own opinions as findings.
From findings to fixes
Raw observations are not a report. Cluster the notes from all participants into themes, then rank each theme by two axes: how often it appeared, and how badly it blocked the goal. A problem that three of five people hit and that stopped the task is top priority. A cosmetic wobble that one person mentioned in passing can wait.
Then resist the urge to fix everything at once. Pick the two or three highest-impact themes, redesign them, and test again. Feeding findings back into the next iteration is what turns testing from a box-tick into a habit that steadily improves the product.
Key takeaways
- Five users per round is enough to surface most serious problems; run several small rounds instead of one big study.
- Recruit through customers and your network with a short screening form and a modest incentive.
- Write goal-based tasks, never instructions that name your UI elements.
- Moderate by staying quiet for 10–15 seconds and probing afterwards with open questions.
- Separate observation from interpretation in your notes, and keep verbatim quotes.
- Prioritise findings by frequency and severity, fix the top few, then test again.