How to plan, run and act on a small usability test in about a week, without a lab, a research team or a large budget.
In short
Usability testing means watching real users try to complete real tasks with your product while they think aloud. A budget version needs five participants, three to five tasks, a short script, one moderator, one note-taker and a single afternoon of analysis. Repeat it after each larger change instead of running one big study.
Many product teams know they should test with users but postpone it because it sounds expensive and slow. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for product owners, designers and developers who want a method they can run themselves in a week. It explains what a test is, gives a seven-step method and shows how to turn what you see into backlog items.
What is usability testing?
Usability testing is a research method where representative users attempt specific tasks with a product while an observer watches where they succeed, hesitate and fail. It answers one practical question: can people use this to do what they came to do?
Usability (användbarhet in Swedish) is the extent to which specific users can reach specific goals effectively, efficiently and with satisfaction in a given context. A usability test measures that directly, by observing behaviour rather than asking for opinions.
It is easily confused with related methods. Each has a place in UX research, but they answer different questions:
Method
What it is
What it tells you
What it cannot tell you
Usability test
What it is
Users attempt tasks while you observe
What it tells you
Where and why people get stuck
What it cannot tell you
How many users are affected across the whole product
UX audit or UX review
What it is
An expert inspects the interface against principles and standards
What it tells you
Likely problems, quickly and without users
What it cannot tell you
Whether real users actually struggle
Analytics
What it is
Data on what users do at scale
What it tells you
Where drop-offs happen
What it cannot tell you
Why they happen
Survey
What it is
Users answer questions
What it tells you
Attitudes and self-reported needs
What it cannot tell you
What people actually do
Interview
What it is
Open conversation with users
What it tells you
Goals, context and motivations
What it cannot tell you
How well the interface works
A UX audit is a useful first pass. An expert review against the ten usability heuristics from Nielsen Norman Group, such as visibility of system status and error prevention, finds obvious issues cheaply. Testing then shows which of them really block users and reveals problems no expert predicted.
How do you run a lightweight usability test?
Run it as a short, fixed sequence: decide what you want to learn, write tasks, recruit five people, run moderated sessions, and analyse together on the same day. The GOV.UK Service Manual's guidance on moderated usability testing describes the same core approach: participants attempt tasks and think aloud while the team watches.
- Pick one question and one journey. For example: "Can a new customer order a replacement part without calling support?" A narrow focus keeps the test short and the results usable.
- Write three to five realistic tasks. Give each a goal and context, not instructions: "Your dishwasher pump has failed; find and order a replacement", not "Click Spare parts". Tasks must not hint at the answer.
- Recruit five participants who match your users. Existing customers, people from customer service lists or colleagues from another department who resemble the target group all work. Offer a small thank-you, such as a gift card.
- Prepare a one-page script. Include a short introduction that makes clear you are testing the product, not the person, the tasks in order, and two or three follow-up questions. Use the same script for everyone.
- Run 30 to 45 minute sessions. One person moderates and stays mostly quiet; another takes notes. Remote sessions over a video call with screen sharing work well and save travel. Ask for consent before recording and store recordings securely.
- Invite the team to watch. Developers and stakeholders who see a user struggle accept the finding far faster than those who read about it in a report.
- Analyse on the same day. Put each observation on a note, group similar ones, and rate each problem by how many participants hit it and how severe it was. Write a one-page summary with the top five issues and a screenshot or short clip for each.
The total effort for a small team is typically a day of preparation, a day of sessions and half a day of analysis. You need a working prototype or the live product, a video tool and a shared board, and nothing else.
How many users do you need for a usability test?
Five users per round is enough to find most of the usability problems in a focused test, provided you test again after fixing them. Jakob Nielsen's analysis of why you only need to test with five users, published in 2000, estimates that five participants uncover about 85 percent of the problems in a study, and that the sixth and later users mostly repeat what you have already seen.
Two caveats matter:
- Different user groups need their own participants. If your product serves two very different groups, such as customers and administrators, the same article suggests three to four users from each group.
- Several small rounds beat one large one. Nielsen recommends spreading the budget over iterations: test, fix, test again. Fixes can fail, and removing one problem often reveals the next.
The five-user rule is for qualitative testing, where the aim is to find problems. If you need statistics, such as a reliable task success rate to compare two designs, you need many more participants and a different method.
Include users with different abilities
A budget test is a good moment to include at least one participant who uses assistive technology, such as a screen reader or screen magnification. The GOV.UK guidance advises asking such participants to bring their own setup. It will not replace an accessibility audit, but it shows what barriers feel like in practice. Our explainer on WCAG 2.2 and how to test against it covers the formal side.
How do you turn findings into backlog work?
Turn each problem into a backlog item with evidence, severity and a proposed fix, and decide in the next refinement what to do about the top items. A finding that only lives in a slide deck rarely gets fixed.
For each issue, record:
- What happened, in one sentence, with the task and step where it occurred;
- How many participants hit it, for example "4 of 5";
- Severity, such as blocks the task, causes delay or minor irritation;
- Evidence, a quote, screenshot or short clip;
- A suggested change, as a starting point for the team, not a final design.
Then plan the next round. Once the top issues are fixed, run the same tasks with five new participants to check that the changes worked. Over time, a short test every few sprints becomes part of how the team builds, not a separate project.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
How much does a small usability test cost?
The main cost is time. A lightweight test with five participants usually takes one or two people about two and a half working days: preparation, sessions and analysis. Add small thank-you gifts for participants and a video-call tool you probably already have. That is far less than the cost of building and releasing a feature that users cannot complete.
What is the difference between a UX audit and usability testing?
A UX audit, sometimes called a UX review, is an expert inspection of an interface against established principles and standards, done without users. Usability testing observes real users as they try to complete tasks. An audit is faster and finds likely problems; a test shows which problems actually stop people and uncovers issues experts miss. Many teams run an audit first, then test the most important journeys.
Can we test with colleagues instead of customers?
You can, with care. Colleagues from other departments who do not know the product can reveal basic navigation and wording problems. They are a poor substitute for customers when the tasks depend on domain knowledge, real motivations or the customer's own data. Never test with people who built or sell the product, because they know too much to stumble where users do.
Should usability tests be moderated or unmoderated?
For a small team starting out, moderated tests are usually more useful. A moderator can ask why a participant hesitated and follow up on unexpected behaviour, which is where most insight comes from. Unmoderated tools, where participants record themselves, scale better and suit simple tasks, but you lose the follow-up questions and spend more time reviewing recordings.







