Plan a usability test by naming the decision it must inform, recruiting people who match the relevant users, and asking them to attempt realistic tasks. Decide what observers will record, how consent and data will be handled, and how findings will be analyzed before sessions begin. A test diagnoses interaction problems; it does not estimate market demand.
Who this is for: Product designers and researchers preparing a moderated or unmoderated test of a digital workflow before a design decision.
- Tie the study to one product decision and define what evidence could change that decision.
- Recruit participants by relevant behavior, role, access need, and context rather than convenience alone.
- Pilot the tasks, technology, note-taking scheme, and consent flow before collecting study evidence.
Frame the decision
Start with the choice the team faces, such as whether people can complete account recovery without support. List the uncertain interaction steps and the consequences of failure. A broad goal to test the redesign gives observers no common standard and encourages every comment to become a finding.
Choose usability testing only when observing attempts can answer the question. Interviews may better explain an existing practice, analytics may locate a funnel break, and accessibility evaluation requires additional methods and expertise. State what this study can and cannot establish so stakeholders do not treat a small test as a prevalence estimate.
Recruit relevant participants
Write screening criteria from the workflow: role, recent experience, device, domain knowledge, language, and assistive technology where relevant. Include meaningful variation without claiming the participants statistically represent every customer. Exclude conflicts that could distort behavior, and explain compensation, recording, privacy, and withdrawal clearly.
Select session count from the study purpose, user variation, iteration plan, and available evidence rather than a universal magic number. A narrow formative round and a comparative benchmark have different needs. Document who was recruited, who was missed, and which claims the resulting sample can responsibly support.
Design tasks and measures
Build tasks around realistic goals, starting conditions, and information participants would actually possess. Avoid interface words that reveal the control to use. Define completion, critical error, assistance, abandonment, and notable behavior before the study, while leaving room to capture unexpected strategies and comments.
Use measures that fit the decision. Task completion and error paths can show whether the workflow works; time may matter when speed is part of the user goal; confidence comments can reveal uncertainty but do not replace behavior. Plan follow-up questions that ask what participants expected and noticed without teaching the answer.
Prepare operations and analysis
Create a session script covering introduction, consent, think-aloud guidance if used, tasks, neutral prompts, closing, and data handling. Assign facilitator and note-taker roles. Test links, accounts, prototypes, recording, accessibility, and backup arrangements with a pilot participant who resembles the target profile.
Prepare an observation sheet linked to each research question. After sessions, separate observed events from interpretations, group evidence, inspect contradictions, and rank issues by customer consequence and confidence. Preserve source links and report limitations. Design recommendations should explain the evidence and tradeoff, not merely restate participant preferences.
Plan a hypothetical invoice test
Hypothetical scenario: a billing team is deciding whether a revised invoice-correction flow is ready for development.
- Define the decision as whether first-time billing coordinators can identify and repair a rejected line without losing accepted work.
- Recruit hypothetical participants with recent invoice-correction responsibility and include relevant keyboard users in the plan.
- Write tasks from a rejection notice, define completion and critical data-loss errors, then pilot the session and accounts.
- Synthesize observed breakdowns, contradictory strategies, and study limits before recommending design changes.
Usability test plan
Use these fields to make the study reviewable before recruitment starts.
- Decision, research questions, current evidence, assumptions, and claims excluded from the study.
- Participant behaviors, roles, access needs, variation, screening, compensation, consent, and sample limits.
- Tasks, starting states, completion definitions, critical errors, prompts, measures, and follow-up questions.
- Session roles, technology, accounts, privacy, recording, pilot, backup, schedule, and evidence storage.
- Analysis method, severity criteria, contradiction review, recommendation owner, and decision meeting.
Common mistakes
- Recruiting coworkers who know the interface and presenting their behavior as customer evidence.
- Writing tasks with button labels that tell participants how the workflow is supposed to work.
- Collecting reactions without defining the product decision, observation scheme, or analysis process.
Try one
A team wants to test whether customers need a new reporting feature by showing a polished prototype. Is usability testing the right first method?
A strong answer separates need from usability. The prototype can reveal whether people understand and operate the proposed interaction, but it cannot establish that the underlying reporting problem matters in real work. First investigate recent reporting behavior and evidence of the problem, then use a usability test for the riskiest interaction and state the sample limits.
Sources
- Nielsen Norman Group usability testing guideGuidance on planning sessions in which representative participants attempt realistic activities.
- Nielsen Norman Group test task guidanceGuidance on writing realistic task scenarios without revealing the intended action.