User Testing With Five People and No Lab
By CodexierPublished 6 min read
Most usability problems on a website or app are visible to anyone who watches a real person try to use it. The trouble is that nobody does. This guide is the minimum viable version of user research: five remote sessions, run by you, in one week, producing a prioritised list of fixes. It is what we do in the first days of every UX audit, and there is no reason you cannot do it yourself.
Why five users find most problems
The mechanism is simple. Serious usability problems are not rare events; they hit almost everyone who meets them. So the first user finds many, the second finds most of the same ones plus a few new, and by the fifth the new findings have dried up. Testing more people in the same round mostly confirms what you already know. The better use of the budget is to fix the problems and test again with five new people. Two rounds of five tell you far more than one round of ten.
Recruiting the right people
The value of a test depends entirely on who sits in it. A colleague who knows the product will glide past problems a customer would hit. A relative who never buys what you sell will struggle with things that do not matter. Write down two or three characteristics of your real customer, such as "books a service online at least twice a year" and "has never used our site", and recruit only people who match.
| Source | How | Cost and notes |
|---|---|---|
| Recent customers | Email asking for thirty minutes in exchange for a gift card | Cheapest and most realistic; pick people who bought once, not fans |
| Newsletter or social followers | Short screener form with the two or three criteria | Good reach; screen out anyone who knows the team |
| Your shop, clinic or office | Ask people at the counter | Free; works for local service businesses |
| Recruiting panels | Paid platforms that find participants by profile | Fast; costs per participant, and quality varies |
| Partner businesses | A neighbour company's customers who match your profile | Useful when your own customer list is small |
Offer a modest thank-you. A gift card is fine. Paying too much attracts professional testers; paying nothing makes people cancel.
Writing tasks, not questions
Opinions are cheap and mostly wrong; behaviour is what you are buying. So the session consists of tasks, phrased as a realistic situation with a goal, and no hints about where to click. Five to seven tasks fit in thirty minutes. Start with an easy one to settle nerves, put the most important flow in the middle, and end with one that tests something you suspect is broken.
- Bad: "Is the navigation clear?" Good: "You need a quote for painting a three-room flat. Find out what it would cost and how to get one."
- Bad: "Try the checkout." Good: "Buy the blue version in size medium and have it delivered to a parcel locker near you."
- Include one task the site cannot do, to see what people try when there is no path.
- Write the success condition for each task before the session so you know when to move on.
Running remote sessions
A video call with screen sharing is all the lab you need. Ask the participant to share their screen, open the site on the device they normally use, and think aloud as they go. Record with explicit permission and say what the recording is for and when it will be deleted; a test session is personal data too. Then the hard part: stay quiet. Every time you help, you erase a finding.
Before
Send the link and a one-line explanation the day before. Test your own screen share. Have the task list and a notes template open.
During
Read each task aloud, then wait. If they get stuck, ask "what would you do now?" not "have you tried the menu?". Note where they hesitated and what they said.
After
Ask two questions: what was the hardest part, and what did you expect to happen that did not. Thank them, send the gift card the same day.
Have a second person take notes if you can. The moderator cannot both keep the session moving and write down what happened at the second the participant clicked the wrong button. Recordings help, but nobody rewatches five hours of video; the notes are what you will use.
Turning notes into fixes
The day after the last session, put every observation on a list: one line, one participant, one moment. Then group them by the page or step where they happened. Problems that hit three or more of five people and stopped them from completing a task go to the top. Problems that slowed people down come next. Comments about colours and preferences go last, or nowhere. For each top problem, write the smallest change that would remove it, and estimate the effort. That list is your backlog for the month, and it is more reliable than any expert opinion, including ours.
When you do not need this: if the site has almost no traffic yet, testing will find real problems, but the bigger question is whether anyone wants the product; spend the week on customer interviews instead. And if you already have analytics showing exactly where people drop, start by fixing that step before testing. Where a full UX audit adds value is in combining these sessions with a heuristic review and the analytics data, and in the accessibility check we cover in designing for WCAG 2.2. Whether you need that or just this recipe is a 15-minute conversation.
- UX audit and conversion improvementFive user sessions, a heuristic review and a prioritised fix list, delivered in a published window.
- Designing for WCAG 2.2The accessibility criteria that user tests often surface without naming them.
- Book a free 15-minute callTell us what you want to test; we help you write the tasks or run the sessions for you.
Frequently asked questions
How long does a user test session take?
Thirty to forty-five minutes is enough for five to seven tasks and two closing questions. Longer sessions tire participants and the findings get thinner. Schedule sessions with a gap between them so you can tidy your notes.
Can I test a prototype instead of a live site?
Yes, and it is often the best time to test, because fixes cost nothing before code exists. A clickable Figma prototype works for most flows. Tell participants it is a prototype and that some parts will not respond, then run the same tasks.
Do I need to record the sessions?
It helps for checking details and for showing colleagues a clip of a real person getting stuck, which persuades faster than any report. Record only with clear consent, explain how long you keep it, and delete on schedule.
What if the five participants disagree?
They will, on preferences. Ignore preferences and look at behaviour: where did people stop, backtrack or fail. Behaviour clusters; opinions scatter. If a real problem appears for only one participant, note it and watch for it in the next round.
Want the sessions run for you, with a fix list at the end?
Fifteen minutes with an engineer: describe the flow you are worried about and we tell you whether five sessions will answer it, and whether you should run them yourself or hand them to us.
Book a free 15-minute call