Usability Testing

Usability Testing

Usability testing means watching real people try to complete real tasks with your product, to find out where it confuses them. It's a UX research method, and the point is to observe what they do rather than ask what they think.

Go back to Glossary

What is usability testing?

Usability testing is a UX research method in which representative users try to complete realistic tasks with a product or prototype while someone observes, to find where the design confuses or blocks them.

The critical word is watching. People are unreliable narrators of their own behaviour. Someone who struggled for four minutes will often say the flow was fine, because they got there in the end and don't want to seem slow.

The ISO 9241-11 standard defines usability as the extent to which specified users can achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. A usability test checks all three on a real design with real people.

What are the 5 components of usability testing?

The five components of usability testing are a clear goal, representative participants, realistic tasks, a facilitator, and a way to observe and record what happens.

  1. Goal. The question the test has to answer, for example "can a new admin invite their team without help?" Keep it to one flow per test so the results stay readable.
  2. Participants. People who match the real users of that flow. Colleagues know the product too well to count.
  3. Tasks. Realistic things to get done, written as goals with no hint of which buttons to press.
  4. Facilitator. The person who runs the session, hands over the tasks and then stays quiet. In unmoderated tests, written instructions and the testing tool take over this role.
  5. Observation and data. Notes, screen recordings and simple measures like task success, time on task and errors, so findings can be counted and compared across sessions.

Nielsen Norman Group names three of these as the core of every usability study: the facilitator, the tasks and the participant. The goal and the data are what turn a handful of sessions into a decision.

Some answers to this question list Jakob Nielsen's five quality components of usability instead: learnability, efficiency, memorability, errors and satisfaction. Those describe what a test measures. They also make good categories for sorting the problems you find.

What are the types of usability testing?

The five common types of usability testing are moderated, unmoderated, remote or in-person, comparative and think-aloud. Most real tests combine two or three of them.

  • Moderated. A facilitator is present and can ask why. Richer, slower, and vulnerable to the facilitator leading the participant.
  • Unmoderated. The participant works alone while their screen is recorded. Faster and cheaper, and you can't ask follow-up questions.
  • Remote or in person. Remote is now the default and loses body language.
  • Comparative. Two designs, same task, measuring which performs better.
  • Think-aloud. Participants say what they're thinking as they work. It's a protocol you add on top of the other types, and it explains the reasoning behind a wrong click.

What is an example of usability testing?

A simple example is six account admins each trying the same task on a redesigned billing page while a researcher watches and records where they hesitate.

The task reads: "Switch your plan to annual billing and download last month's invoice." Four of the six finish without help. Two look for the invoice under Profile before finding it under Billing, and one gives up on that part. Asked afterwards, both describe the page as "pretty clear." The recordings show the real finding, and the fix is a download link in the place people looked first.

How do you run a usability test?

You run a usability test in five steps: set one goal, recruit the right participants, write tasks, run the sessions without helping, and sort what you saw by how many people it stopped.

  1. Set one goal. Pick the flow and the decision the test should inform.
  2. Recruit about five people per user group. Jakob Nielsen's widely quoted estimate is that five participants find about 85% of the usability problems in a design for one type of user. Five admins and five end users is not the same as ten people, because they hit different problems.
  3. Write tasks as goals. "Find out how much your team would pay per month" is a task. "Click pricing, then select the team plan" is a script that tests nothing.
  4. Say nothing while they work. The silence is uncomfortable and it is where the findings are. A pause before clicking counts as a usability problem even when the click is right. Keep questions for the end, since asking mid-task changes the behaviour you're measuring.
  5. Sort the findings. Group problems by task, count how many participants hit each one, and fix whatever blocked the most people first.

What can't usability testing tell you?

Usability testing can't tell you whether people want the thing you're testing, only whether they can use it. A flawlessly usable feature nobody needs still fails, and usability testing will report it as a success.

That question belongs to product discovery and broader product research. Teams that run usability tests in place of discovery can spend a whole quarter polishing a feature nobody asked for.

Usability testing for enterprise product teams

At enterprise scale, usability testing runs across many teams in parallel, and findings need to outlive the session that produced them. Ten squads might each test their own flow in the same quarter, with different user roles, different recruiting rules and notes kept in ten different places.

Test each role on its own. An admin, an approver and an occasional end user will hit different problems on the same screen. Then keep every finding attached to the recording and the participant group it came from, so that when someone asks six months later why a design changed, the answer is a set of sessions anyone can reopen.

How Usersnap supports usability testing

Usersnap lets test participants report a problem from inside the product at the moment they hit it. That matters most in unmoderated sessions, where no facilitator is around to reconstruct what happened.

  • Visual reports: annotated screenshots and screen recordings of up to three minutes, with browser, operating system and screen size attached to every item.
  • Post-task questions: in-app surveys with conditional logic, so a participant who rates a task as hard gets a follow-up asking why.
  • Grouping: Sentiment Sensor tags each report with a topic and sentiment as it arrives, and test findings sit next to acceptance testing reports and general feedback.
  • Asking your AI assistant: the MCP connector lets ChatGPT, Claude or Cursor query your live workspace with your own permissions, for example "summarise what testers reported about the onboarding flow."

Sentiment Sensor is included on Professional plans and above, and available as an add-on on Starter and Growth.

Usability testing FAQ

How many people do you need for usability testing?

Around five per distinct user group and per flow. Five surfaces most problems in one design for one audience, and separate groups need their own five.

What is the difference between usability testing and user acceptance testing?

Usability testing asks whether people can use it, usually on a design before release. User acceptance testing comes just before go-live and checks that the product does the job the business needs.

What metrics are used in usability testing?

The common ones are task success rate, time on task and error rate, plus a satisfaction rating at the end. The System Usability Scale (SUS), a 10-question survey published by John Brooke in 1986, is a long-standing standard for that rating.

Is usability testing qualitative or quantitative?

It can be either. A five-person moderated test is qualitative and good at finding problems. Run a larger unmoderated test that measures success rates and timings, and you get numbers on how big each problem is.

Related terms

See how test participants show you a problem with a screen recording, at the moment it happens.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.