Run usability testing that reveals where users get stuck

Effective usability testing observes people as they try to complete tasks with a product or prototype. It reveals where the interface, language, or workflow makes the task difficult. The goal is to understand behavior, rather than ask whether people like a design or can explain its features.

A user can describe a screen as attractive and still fail to submit a request. Watching that attempt gives a team evidence it cannot get from a general opinion survey.

This article explains how to plan a study, recruit suitable participants, and write realistic tasks. It also covers moderation, evidence, prioritization, and how to test a revised design.

What usability testing can and cannot tell you

A usability study can reveal confusion, errors, and workarounds in the tasks you examine. It can also show whether people understand labels and recognize the information they need.

However, a small qualitative study does not establish the percentage of all users who face a problem. It gives detailed evidence from the participants and conditions involved.

Likewise, testing a prototype can reveal design issues without proving production speed, reliability, or full accessibility. Keep the limits of the test visible.

The GOV.UK guide to moderated usability testing provides practical guidance on planning and running observed sessions. Use a method that fits your research question rather than treating every product question as a usability task.

Choose a question before a method

Start with a decision the team needs to make. For example, can a new customer find the correct service and submit the information needed for a quote?

That question gives the study a useful boundary. It identifies the journey, likely participants, and evidence the team needs.

Next, separate usability from other research needs. If you need to know which problem customers care about, interviews or field research may help before interface testing. If you need to compare measured conversion at scale, an experiment may answer a different question.

Use usability testing when observing task behavior will reduce uncertainty about the design. Avoid running sessions simply because the team wants approval for work it has already decided to ship.

Test at the right stage

Early sketches can help assess navigation and language. Interactive prototypes can support more complete journeys. A working product can reveal real inputs, errors, and operational constraints.

Choose the least expensive representation that can answer the question. A static image cannot test an upload workflow, while a production build may be unnecessary for comparing two navigation labels.

Also explain prototype limits to participants without teaching them the interface. They should know that some paths do not work, but the introduction should not reveal how to complete the task.

Oxen’s MVP development guide explains how early validation can focus effort on important assumptions. Usability sessions can provide one kind of evidence within that process.

Recruit people who reflect the task

Recruit based on relevant behavior and context, not only broad demographics. An employee who approves invoices has different knowledge from someone who submits an expense for the first time.

Identify the characteristics that affect the journey: experience, role, device, environment, language, and accessibility needs. Then choose participants who can represent the important variations.

For a specialist business system, avoid replacing actual users with convenient colleagues who know the product. Familiarity can hide problems that new or occasional users face.

Also avoid a blanket sample-size rule. The right plan depends on study goals, user diversity, task risk, and whether the team will run more rounds.

A small iterative study can reveal useful issues, but report its scope honestly. Do not turn observations from a few sessions into precise population claims.

Include people with different access needs

Users may navigate with a keyboard, use a screen reader, enlarge text, or rely on other adaptations. Include relevant access needs when they affect the product’s audience.

W3C’s web accessibility evaluation overview explains the role of different skills and user involvement. User sessions complement technical evaluation rather than replacing checks against accessibility requirements.

Plan the session environment so participants can use their normal tools where possible. Unfamiliar equipment can add difficulty unrelated to your design.

Oxen’s accessibility testing guide covers technical checks that should accompany research. A participant completing one task does not establish that every screen or interaction is accessible.

Write realistic tasks without giving directions

A good task gives the participant a goal and enough context to act. It should not name the exact button or menu you want them to discover.

For example, “You need a copy of last month’s invoice for your accounts team” leaves room to observe navigation. “Click Billing, then Download Invoice” teaches the solution and removes the question.

Use plausible data and consequences. A person booking a service needs enough information to choose an option. A task with unrealistic inputs may create confusion that does not reflect normal use.

Next, define success and important failure states for the research team. Participants do not need to see that checklist. It helps observers judge the result consistently.

Avoid packing too many unrelated goals into one task. If someone becomes stuck early, you may lose the chance to examine the later behavior.

Prepare the session and run a pilot

Create a short discussion guide with the introduction, tasks, follow-up questions, and closing. Keep it flexible enough to explore unexpected behavior without losing the study’s purpose.

Check the prototype, test accounts, devices, recording setup, and backup plan. A technical fault can consume the session or change how the participant approaches the task.

Use suitable test data and explain how recordings and notes will be handled. Obtain the relevant consent before recording. Keep private or sensitive information out of shared observation material.

Then run a pilot session. It can reveal unclear tasks, broken paths, or a schedule that leaves no time for follow-up questions.

Do not treat the pilot as proof that the design works. Its main purpose is to improve the research setup before the full round.

Moderate without rescuing too soon

Explain that the session examines the product, not the participant. People should feel comfortable showing confusion and making mistakes.

Ask them to describe what they are thinking when that helps the study. However, remember that thinking aloud can affect behavior and timing, so interpret time measurements accordingly.

When someone pauses, use neutral prompts such as “What are you looking for?” Avoid hints that point to the expected answer.

If the participant cannot progress, record the difficulty before helping. You can then move them forward to examine a later part of the journey, while clearly marking that assistance in the notes.

Also avoid defending the design. An explanation from the moderator may make the interface seem clear during the session without solving the user’s real problem.

Capture observations separately from interpretations

An observation describes what happened. An interpretation proposes why it happened. Keeping them separate makes findings easier to review.

For example, “The participant opened three menus before asking for help” is an observation. “The navigation label did not match their mental model” is an interpretation that needs supporting context.

Record task outcome, errors, help, and meaningful comments. If timing matters, define when measurement starts and stops, and note interruptions.

Do not treat every spoken preference as a design requirement. A requested feature may point to an underlying need that another solution can meet more simply.

Use recordings or timestamps to support important findings, subject to the study’s consent and data rules. Evidence helps the team discuss behavior without relying on memory.

Prioritize by consequence, frequency, and confidence

After the sessions, group related observations into problems. Then assess the impact on the task, how often you observed it, and how confidently the evidence supports your explanation.

A problem that blocks a critical action can deserve attention even if it appears once. A minor annoyance that appears often may still rank below it.

Include context. A first-time user and an experienced administrator may encounter different problems. Avoid averaging away those differences.

Next, propose changes as hypotheses. “Move the status beside the action so users can tell whether submission succeeded” is more testable than “make the page clearer.”

Assign an owner and a route into the product backlog. Research that ends in a presentation without follow-up work has not yet changed the experience.

A worked example: requesting a repair

Imagine a portal where customers submit repair requests. The study asks whether a new user can describe the issue, attach a photo, and understand what happens next.

During a session, a participant uploads the image but cannot tell whether it finished. They select the upload button again and later submit two copies.

The team records the behavior and checks whether the interface provides a clear progress and completion state. It does not assume that duplicate uploads come from careless use.

A revised design adds visible file status, a remove action, and a clear submission confirmation. The next round tests whether users now understand the state without moderator help.

This is an illustrative scenario, not a claimed client result. It shows how observation can lead to a specific change and a new test question.

Combine usability evidence with other checks

Usability sessions do not replace functional or acceptance testing. A workflow can be easy to understand while calculating the wrong total.

Oxen’s user acceptance testing guide explains how business reviewers confirm that delivered behavior meets agreed needs. Keep that evidence alongside usability findings.

Product analytics can show where behavior changes at scale, while sessions can reveal possible reasons. Support records can identify recurring confusion worth investigating.

Use the methods together without overstating causation. An observed problem can suggest a fix, but a later metric change may also reflect traffic mix or other product changes.

Report findings people can act on

A useful report states the research question, participants, tasks, setup, and limitations. Then it presents a small set of prioritized findings with evidence and proposed next steps.

Keep strong claims tied to what you observed. Say that participants in this study struggled with a task, rather than claiming every user will fail.

Also show what worked when it affects the design decision. A team needs to preserve successful behavior as well as fix problems.

Finally, plan a follow-up round for important changes. The goal is not to prove the first design right; it is to learn whether the revised experience helps users complete their work.

Keep stakeholder observation useful

Invite relevant stakeholders to observe user testing through an agreed setup. Give them a simple note format that separates what they saw from their proposed solution.

Ask observers to hold questions until the appropriate point rather than interrupt the task. Otherwise, several people can unintentionally guide the participant.

Afterward, compare notes before debating fixes. This helps the team agree on the evidence and notice where observers interpreted the same behavior differently. The result should be a shared understanding of the problem, not a vote on whose preferred design wins.

Observe the task, then test the improvement

Good usability testing connects a clear question with realistic behavior and actionable evidence. Recruit suitable participants, avoid leading tasks, and separate observations from assumptions. Then use another round to see whether the design change solves the problem.