How to Run a Usability Test: A Practical Workflow

Usability testing observes people attempting realistic tasks with a product, prototype, website, or app. The purpose is to identify friction in finding, understanding, navigating, or completing something. For example, ask a participant to find and order catering for a team event, then observe where the journey becomes uncertain or breaks down.

A good test can show what happened and, with neutral follow-up questions, help explain why. It cannot by itself prove market demand, accessibility conformance, technical quality, or a future increase in conversion or revenue. This guide treats usability testing as an evidence workflow: frame a decision, choose an appropriate method, preserve task-level evidence, and route reviewed findings to a named owner.

Start with the unresolved uncertainty. Observe task behavior when you need to know whether people can complete a workflow. Use an experiment when you need to compare versions against a defined outcome. Use analytics, recordings, interviews, or other research when you need to understand an existing pattern or its underlying causes.

What a usability test can and cannot answer

A usability test is a structured observation of people attempting tasks with a product or design. It can reveal problems with findability, comprehension, navigation, content clarity, or task completion. A moderated session can add context because the facilitator can ask what the participant expected, noticed, or found confusing after the relevant behavior occurs.

User research is the broader practice of learning about people and their needs through methods such as interviews, surveys, and observation. A/B testing compares versions against a predefined outcome. It can show which version performed better for that outcome, but it does not explain user behavior by itself. The UserTesting glossary distinguishes moderated sessions, where a moderator directs tasks and asks follow-up questions, from unmoderated sessions, where participants complete the study independently.

Usability testing also does not replace accessibility audits, security testing, performance testing, production quality assurance, market-demand research, customer-support analysis, or legal review. A prototype can expose a confusing workflow while hiding a backend defect. A live-site metric can show where friction occurs without explaining its cause.

Keep measures distinct. A participant may complete a task while feeling uncertain, or fail because a prototype link is broken. Completion, time, errors, assistance, satisfaction, engagement, conversion, and revenue describe different units of analysis. Define the population, time period, and measurement grain before comparing them.

Choose a method that fits the uncertainty

Moderated testing is useful when the task, workflow, or user expectation is uncertain and follow-up questions may change the interpretation. Unmoderated testing is useful when the task is clear enough to complete independently and the team needs directional evidence across more participants or contexts. The labels describe how the session is conducted, not whether the result is automatically reliable.

Research question	Suitable evidence	Key tradeoff
Can people complete an unfamiliar workflow, and why do they struggle?	Moderated task observation with neutral follow-up	Rich context, but facilitation takes time and can influence behavior if the moderator coaches.
Can people complete a clear task independently?	Unmoderated task study with recordings or responses	Efficient directional evidence, but instructions must work without live clarification.
Where does friction occur in an existing experience?	Analytics or recordings followed by task-based observation	Production data can locate a pattern, but a metric or recording alone may not explain it.
Which version performs better on a defined outcome?	A/B test with a predefined metric and comparison plan	Compares outcomes, but does not replace research into why users behaved as they did.

This table is an editorial decision rule, not a vendor-prescribed framework. Use moderated sessions when instructions, expectations, or workflow logic are uncertain. Use unmoderated research when the task is sufficiently clear. For an existing site, use analytics to identify a question worth investigating, then select evidence that can answer that question.

Select the stimulus and define its evidence boundary

Choose the least expensive stimulus that can answer the question, without treating low cost as proof of quality. A wireframe can test early structure and findability. A clickable prototype can test navigation, comprehension, and perceived workflow logic. A staging or live product is more appropriate when implementation behavior matters.

UserTesting describes self-guided testing for websites, prototypes, and apps, including tasks and questions, but capability and availability can depend on the account plan. Its self-guided testing overview is a product description, not evidence that a particular study will be representative or valid.

For a live website, verify the selected configuration before recruiting. Maze documents that snippet-based website tests can provide expected paths and heatmaps, while snippet-less tests rely on recordings and do not provide those outputs. Maze also documents single-tab testing and warns that in-page interactions that do not change the URL may not appear as path steps. Its live-website testing guidance should be checked for current setup details.

Before launch, confirm whether the tracking script loads, whether URL changes represent the journey, whether ad blockers or privacy controls affect collection, and which source is authoritative for the study: recording, response, path, heatmap, or task result. Do not promise that every click or interaction will be captured.

Write tasks and success criteria before recruiting

Give participants a goal, not a sequence of interface instructions. A useful scenario might be: “You are arranging a team event. Find a catering option that fits the group and place the order.” Avoid naming the menu, filter, button, or expected answer unless the research question specifically concerns that control.

For each task, define the goal, starting state, completion condition, permitted assistance, and follow-up question. Use a status such as success, partial, failure, or abandoned. Where meaningful, record completion time, errors or backtracks, assistance given, and a brief confidence or satisfaction response. These measures should not be collapsed into one unexplained usability score.

Keep observed behavior separate from stated preference. Ask what the participant expected after the behavior occurs, rather than leading them toward a diagnosis. For example, “What were you looking for at that point?” is safer than “Was the filter hard to find?”

Pilot the task and stimulus before the main study. If wording is unclear or a prototype link is broken, fix the materials and repeat the pilot. Do not silently change instructions for only one participant, because that weakens comparison across sessions.

Run the study with consistent facilitation and records

Recruit against a stated participant profile and screen for experience relevant to the task. A convenient sample is not automatically representative. A small study can reveal actionable friction, but its participants and method determine what can reasonably be concluded.

Use the same core instructions across participants. In moderated sessions, invite think-aloud behavior where appropriate, observe without coaching, and ask neutral follow-ups after behavior occurs. In unmoderated sessions, pilot instructions carefully because there is no facilitator to resolve ambiguity. A note-taker should capture timestamps, task outcomes, observable behavior, and source references rather than only writing a general impression.

Before recording or sharing research material, address consent, access, retention, and masking. Record the stimulus version, device context, and relevant browser context so the team can distinguish a product issue from a test-environment issue. Recordings and transcripts may contain personal information, so limit access and retain only what the research needs.

Turn observations into findings a team can act on

Define the data grain before building metrics. A session record describes one participant’s complete session. A task-result record describes one participant attempting one task with one stimulus version. An observation record describes one behavioral observation or quotation. An aggregate record describes results grouped by a defined variant, segment, device, or period. These records should not be mixed.

The following is an illustrative task-result record, not a vendor-defined schema. It uses a pseudonymous participant key and includes an attempt number so repeated attempts remain distinct:

{
  "study_id": "study_checkout_01",
  "participant_id": "pseudonymous_key_07",
  "session_id": "session_07",
  "task_id": "task_checkout",
  "stimulus_version": "prototype_v3",
  "attempt_number": 1,
  "task_status": "partial",
  "completion_time_ms": null,
  "error_count": 2,
  "assistance_flag": false,
  "source_recording_id": "recording_reference"
}

Use an agreed unavailable value rather than inventing a completion time when the task was not completed. A proposed uniqueness key for this row grain is participant_id + session_id + task_id + stimulus_version + attempt_number. Enforce it with a database uniqueness constraint or transactional upsert when concurrent writes are possible. A lookup-then-create check alone can race and create duplicates.

Store several observations or citations in separate child records rather than overwriting the task result. Keep aggregate success rates separate from participant-level results, and keep research findings separate from CRM contact or deal events. A product backlog may contain an accepted finding and its owner, but that does not make it the raw evidence record.

Prioritize findings using task criticality, severity, observed frequency within the study, and confidence. A count in a small study describes the observed sessions; it is not automatically a population estimate. A useful finding states the problem plainly, links to task and session evidence, identifies confidence and a next step, and names an owner.

AI can help cluster consent-cleared comments or draft candidate themes when a researcher supplies the source material. It should not decide task success, infer clicks missing from a recording, claim statistical representativeness, classify a non-reproducible bug as confirmed, or deploy a design change. A researcher must check every proposed theme against the underlying observation.

Use deterministic validation for required fields, allowed task-status values, duplicate detection, stable identifiers, and access controls. Keep the research repository or agreed product backlog as the system of record. Do not assume a research platform automatically sends findings to a CRM or backlog. ClickUp consulting may be relevant when a team needs operational support for assigning and tracking accepted work, but ClickUp is not a research platform and no automatic integration is promised.

Learn from case studies without copying their outcomes

Customer stories can illustrate an evidence chain, but their reported business results are not universal expectations or proof that one research method caused the result. Read each example as a sequence: question, stimulus or behavioral evidence, observation, design response, and follow-up measure.

Case	Evidence and response	Reported result	Boundary
Panera	UserTesting describes clickable Figma prototypes and research evaluating Panera’s catering ordering experience. The reported findings influenced navigation, customization visibility, past-order access, and bundle presentation.	UserTesting reports a 1.2% initial conversion increase, followed by 9% year-over-year conversion growth and 18% year-over-year revenue-per-visit growth.	Vendor-published customer story. It does not provide the full experimental design, sample size, confidence interval, or independent audit needed to establish causality.
V1CE and Credo	Hotjar describes heatmaps and recordings used to identify interaction patterns and individual-session behavior, followed by site changes and A/B-testing activity.	Hotjar reports a 14.5% increase in page engagement and a 220% revenue increase.	The figures are vendor-reported. Heatmaps alone did not establish why users behaved as they did or cause the revenue result.

The practical lesson is not to copy the percentages. An observed navigation problem can produce a design hypothesis; a subsequent experiment can compare a defined outcome. Use UserTesting’s Panera customer story and Hotjar’s Credo case study as examples of reported evidence chains, not as guarantees.

From production evidence to an experiment

Heatmaps and recordings have different data grains. A heatmap aggregates clicks, scrolling, or movement across a selected population or page segment. A recording represents an individual session. Use a heatmap to locate an interaction pattern and a recording to inspect how one person navigated it. Neither method alone proves the cause.

A disciplined follow-up sequence is:

1. Identify a production pattern using analytics, a heatmap, or support evidence.
2. Form a task-specific usability question about the suspected friction.
3. Observe the task and document the behavior, context, and alternative explanations.
4. Propose a design change and define the outcome that would indicate improvement.
5. Run an appropriate experiment or measurement plan with a defined population, time period, unit of analysis, and stopping rule.

Do not substitute usability completion for conversion, or revenue for comprehension. The measures answer different questions.

Minimum readiness plan before launch

• Question: What decision will this study inform?
• Participant: Who has relevant experience, and how will you screen for it?
• Stimulus: Does the wireframe, prototype, staging site, or live product support every required action?
• Task: Is the scenario goal-based, with an observable completion rule?
• Session: Are the script, pilot, consent, recording plan, tracking setup, and device context ready?
• Analysis: Where will task-level evidence live, who will review it, and who will own accepted findings?

Do not launch until a second person can explain what counts as success, which evidence sources are available, how records will remain unique, and who will review and act on the findings. A small, well-scoped study can expose actionable friction, but the method and participants determine what you can responsibly conclude.