People visit a website to complete a goal. They may need to find information, compare an offer, submit a form, or complete a transaction. A clear website design can support that goal, but visual polish does not prove that the task works for the intended user.
Usability testing gives a team evidence about where people succeed, hesitate, make errors, need assistance, or stop. It can reveal problems in a wireframe, prototype, live site, or product flow before the team spends more effort on the wrong change.
This article explains what usability means, how usability testing differs from related research, how to choose a method, and how to run a study that produces an actionable decision.
- Effectiveness: whether the person reaches the correct outcome, including critical errors.
- Efficiency: effort, unnecessary steps, and time, interpreted in the session context.
- Understanding: whether the person knows what happened and what to do next.
- Experience: reported difficulty, confidence, and concerns after attempting the task.
What is usability?
Usability describes how effectively, efficiently, and satisfactorily a particular user can achieve a particular goal in a particular context. The context matters. A task that works in a quiet office may fail on a phone, under time pressure, or with assistive technology.
What is website usability testing?
Usability testing is a research method in which participants attempt realistic tasks with a website, prototype, or product while a researcher observes. The team records behaviour and task outcomes, then asks focused follow-up questions when needed.
The test is not a survey about whether people like an idea. It is not a focus-group discussion. A post-task interview can add context, but reported preference should not replace observed task performance.
How does website usability testing work?
Start with a decision and a user group. Recruit participants who match the role, experience, behaviour, device, and context that matter to the decision. Give each participant the same realistic task and neutral instructions. Observe the path without teaching the interface.
Record completion, errors, assistance, hesitation, and other measures that match the research question. Time can be useful when efficiency matters, but it can also change behaviour and should be collected consistently. After the task, ask what the participant expected and what made the task easier or harder.
Why is usability testing important?
Usability testing brings user behaviour into design decisions. It can show whether a software workflow supports its intended goal, which parts of a page cause confusion, and whether a proposed change removes a meaningful obstacle.
The result is evidence with limits. A test can reveal a problem and help explain it. It does not automatically show how common the problem is for the entire user base or prove that a design change will improve a business metric. Match the claim to the participants, tasks, measures, and study design.
Types of usability testing
The labels below describe the purpose of a study. Teams may use different names, so state the purpose, participants, tasks, and measures in the plan.
1) Exploratory or formative testing
Use exploratory testing when the team is still learning about a workflow, concept, or early design. Give participants realistic scenarios and observe what they expect, where the concept breaks down, and which questions need more research. The output is a set of design directions and open questions.
2) Assessment or evaluative testing
Use assessment testing to evaluate whether an existing interface or prototype supports defined tasks. Record completion, errors, assistance, and the reasons for failure. A study can be qualitative, quantitative, or mixed; the method must support the claim the team wants to make.
3) Validation testing
Use validation testing after a change when the team needs to check it against predefined success criteria. Compare the result with the same task and measurement plan used before the change. If the team reports a rate or a difference between variants, define the sample, observation window, and analysis before collecting the data.
4) Comparative testing
Use comparative testing when two concepts, flows, or interface variants need to be examined. Keep the task, context, instructions, and participant criteria comparable. Decide in advance whether the outcome is task completion, error rate, time, preference, comprehension, or another measure. A result can support a decision between the tested options; it does not establish a universal winner.
Related: What is user interface design?
Methods of usability testing
Choose the method that fits the research question, participant context, risk, and available evidence. No method is automatically more accurate or more economical.
1. Moderated and unmoderated
In a moderated session, a researcher introduces the task, observes the participant, and asks planned follow-up questions. This allows the team to clarify what happened and explore an unexpected issue, but the moderator can also influence the session.
In an unmoderated session, participants complete the task without a live moderator. This can support a broader set of contexts, but the team has less ability to probe confusion or distinguish a product problem from a participant or device problem. Use clear instructions, access controls, and a support route for technical failure.
2. In-person and remote
Remote testing can make it easier to include people in their normal environment and on their own device. It can also make it harder to observe the physical setting, manage technical problems, or protect confidential information outside the test platform.
In-person testing can reveal details of the environment, device, and physical workflow. It requires a suitable location and may change how naturally a participant behaves. Neither approach is inherently more accurate. Choose based on the task, environment, device, accessibility needs, privacy risk, and type of evidence required.
3. Group discussions are a separate method
A focus group is a discussion about experiences, language, expectations, or reactions to a concept. It can help the team explore opinions and identify topics for individual research. It should not be presented as a usability test because discussion does not show whether a person can complete a task. If a team needs both types of evidence, run a task-based test and a group discussion as separate activities.
Related: What is the difference between software and a program?
A website usability testing plan
A usable plan connects the research question to a task, participant criteria, evidence, and a decision. It also protects participants from unnecessary collection of personal or confidential information.
1. Select the product or flow
Choose the page, workflow, prototype, or task that matters to the decision. State what the team wants to learn and what will change if the result supports or rejects the current design.
2. Define participants and sample rationale
Recruit people who match the relevant role, experience, behaviour, device, and context. Screen for those criteria instead of relying on broad demographics alone. If user groups have different goals or risks, represent them separately in the plan.
Use a small, relevant set for formative learning and iterate in rounds. Use a preplanned, suitable sample when the goal is to estimate a rate or compare variants. The sample should support the claim; a convenience group should not be presented as the whole user base.
3. Write realistic tasks and success criteria
Describe a goal without naming the button or path the participant should use. Define completion, critical errors, assistance rules, and any conditions that end the task.
Illustrative task script:
- Scenario: “You have joined a new workspace and need a colleague to review the project.”
- Task: “Invite the colleague and confirm what access they will receive.”
- Moderator instruction: Read the scenario once. Do not point to controls or explain labels while the participant works.
- Success criteria: The participant finds the relevant area, sends the invitation with the intended access, and can explain what will happen next.
- Record: Completion, errors, assistance, expectations, and time only if efficiency is part of the decision.
This is a test-script example, not an observed case or Hapy result.
4. Create a consistent guide
Use the same introduction, task wording, follow-up prompts, and stopping rules for each participant. Pilot the guide to find ambiguous instructions. Keep follow-up questions neutral and ask them after the task when they could influence behaviour.
5. Assign roles and prepare the environment
Name the moderator, note-taker, decision owner, and person responsible for the prototype or site. Test the device, browser, access permissions, recording controls, and fallback plan before the session. If the product is live, use test accounts and safe data.
6. Obtain consent and handle recordings safely
Explain the purpose, activities, recording, data collected, intended use, access, retention, and withdrawal process. Obtain the consent required for the context. Never ask a participant to enter a real password, payment detail, private customer record, health detail, or other secret.
Mask or redact sensitive fields. Restrict access to the research team, keep only the data needed, and follow the agreed deletion plan. Do not publish a participant’s screen, voice, face, or words without separate permission. If a remote environment cannot be controlled, use a safer test account or a non-recorded method.
7. Run the sessions
Stay neutral and let participants work through confusion. Do not rescue them unless the task or prototype is broken. Note the exact point of difficulty, what the participant tried, what assistance was given, and what they expected. Ask post-task questions about the reason for the path, not only whether the participant liked it.
8. Compare results with the success criteria
Review task outcomes, errors, assistance, time where relevant, and reported expectations. Separate a product defect, a task or moderator problem, and a participant issue. Compare user groups only when the task and measurement are equivalent.
9. Report findings with severity and confidence
For each finding, record the affected task and users, evidence, severity, confidence, owner, and recommended action. Do not turn a small qualitative study into a percentage for all users. If a quantitative result is needed, report the sample, observation window, measure, and limits.
Illustrative finding-to-action format:
- Observation: A participant looks for the invitation control under “Account” and does not find it under “Manage seats.”
- Severity: High for the tested task because the participant cannot complete an important workflow without help.
- Confidence: Moderate until the same pattern is checked with other participants and other evidence.
- Action: Test a “Team” label, place “Invite member” in that area, and re-run the task with the defined administrator group.
This example shows a reporting format. It is not an observed study.
10. Decide and re-test
Assign an owner and decision date to each important finding. Fix the issue, change the prototype, update the requirement, or record why the team will not act. Re-test the changed path with the same success criteria. Then connect the result to analytics, support evidence, or a later product decision when appropriate.
What to do after website usability testing
Review the evidence with the people who own the product, content, design, engineering, and business decisions. Separate findings that block a task from findings that reduce clarity or satisfaction. Agree on an owner, action, and follow-up measure. Keep unresolved issues visible instead of treating the report as the end of the work.
Re-test the changed path with the same task and success criteria. Use analytics, support evidence, accessibility review, or a later study when they answer a different part of the decision. A change that looks better in a session still needs the right product or business measure when the team is making a broader claim.
Separate observation from interpretation. “Participant P3 returned to the pricing page four times” is an observation. “The pricing is confusing” is an interpretation to investigate. Link each proposed fix to the evidence and user consequence.
How is usability testing different from user testing?
“User testing” is a broad phrase for research with current or potential users. Usability testing is a specific method within that broad category: people attempt tasks so the team can observe ease, errors, and outcomes.
Other user research methods may explore whether a problem exists, how people describe it, or whether a concept is relevant. Use those methods when the decision needs that evidence. Do not use an interview or discussion as a substitute for observing task performance.
Final words
Website usability testing helps a team see where a real user can or cannot complete an important task. The value comes from a clear question, suitable participants, neutral tasks, consistent observation, protected data, and an action that is checked after the change.
If your site or product needs a structured usability review, review Hapy’s engagements against the tasks and evidence you need.
Further questions
How much does website usability testing cost?
There is no single price for a usability test. Cost depends on the research question, participant criteria, recruitment, incentives, moderation, prototype or site preparation, recording, analysis, and reporting. Ask for a scope that names these inputs rather than relying on a generic benchmark.
What are the four principles of usability testing?
Useful principles include screening for relevant behaviours and context, giving realistic tasks, observing what people do as well as what they say, keeping moderation consistent, protecting participant data, and testing the important user journeys.
