Method
A planning session that defines test objectives, participant profile, tasks, success criteria, and logistics for a usability test wave.
Choose this if
This method works when designing practical tests before prototype rounds.
Pack = one session you can run now. Workspace = a saved thread for method choice, planning, and shareable outputs.
What Workspace helps you carry forward
Artifact preview
Usability test plan
Validate · Low
Decide fit before you spend session time.
Room fit check
Best when a prototype or concrete scenario already exists and the team needs one disciplined plan for what to test, with whom, and how success will be judged. This room has enough of the right conditions for the method to hold without extra ceremony.
Primary risk: Tasks are written to validate the team's idea rather than reveal real usability breakdowns.
The core facilitation flow, with enough structure to run the method confidently in the room.
Standard setup for Mixed in remote delivery.
Total planned time: 90 min
What happens
Define questions this test must answer.
Facilitator does
Write test objectives as learning questions, not as performance targets. Each objective should identify one specific assumption about usability or comprehension you'd change your design decisions based on. If you're not sure what you'd change if an objective were answered either way, it's not worth testing.
Participants do
Write each objective as a learning question you'd act on if it were answered either way. If you'd only change the design if the result were negative, it's a validation goal — reframe it as: "What would we learn if users struggled here?" Two well-defined learning questions are better than six vague ones.
Output / signal of success
Usability test plan
Watch for
Objectives are stated as proving the design works rather than as genuine learning questions.
Recovery tip
For each objective framed as proving a design works ("we want to confirm the new flow is intuitive"), reframe it as a learning question: "We need to understand where, if anywhere, the new flow creates confusion." Objectives framed as confirmation produce plans designed to succeed rather than plans designed to learn.
What happens
Create realistic task prompts and moderator guide.
Facilitator does
Write tasks as scenario prompts, not instructions — 'you've just received an invoice and need to check if it's been paid' rather than 'click on the Invoices tab.' Read each task aloud and mark any word that tells participants what to do rather than what to accomplish. Those words are leading hints and must be removed.
Participants do
Write each task as a scenario the participant can step into without needing to know the product. Read each prompt aloud and mark any word that names an interface element or tells participants where to go. Those words are hints — rewrite the prompt to describe what the user is trying to accomplish, not how to accomplish it.
Output / signal of success
Moderator script
Watch for
Task prompts use interface labels that direct participants to the exact element being tested.
Recovery tip
For any task prompt that contains an interface label or feature name, rewrite it without the label. "Find the invoice that needs approval" not "click on the Approvals tab." The task prompt should describe the user's goal, not the interface element. If the prompt requires knowledge of the interface to be understood, it's leading the participant toward the answer.
What happens
Set observable indicators and severity thresholds.
Facilitator does
For each task, define observable success criteria — what the participant does or says that tells you the task works. Write at least one partial-success and one failure condition per task. Criteria that depend on self-report ('they felt confident') are weaker than behavioral criteria ('they completed without returning to the start screen').
Participants do
Write at least one failure condition per task, not just success. "The participant completes the task in under 2 minutes without assistance" is a success criterion. "The participant asks for help, gives up, or completes the task through a path that would fail in a live environment" is a failure condition. Both are needed to evaluate the task.
Output / signal of success
Every task has a written success criterion (observable), at least one failure condition (observable), and a severity note — what it means for the design if this failure occurs. The criteria don't depend on asking the participant how they felt.
Watch for
Success is defined as task completion only, ignoring comprehension errors that would cause real-world failure.
Recovery tip
For any success criterion that requires asking participants about their internal state ("they felt confident"), replace it with an observable behavior: "they didn't return to the start screen," "they didn't consult help documentation," "they didn't ask the moderator for guidance."
What happens
Finalize participants, schedule, and synthesis plan.
Facilitator does
Confirm participant count, session length, recording and consent approach, and who will facilitate versus observe. Check prototype fidelity against the task scope — if a task navigates to a section the prototype doesn't include, either cut the task or extend the prototype. A logistics gap discovered during testing destroys the session.
Participants do
Check whether the prototype covers every task in the test script — navigate through it now, as a participant would. If any task leads to a screen that isn't built or connected, either extend the prototype or remove the task before sessions begin.
Output / signal of success
The session ends with named actions, owners, and a clear next checkpoint.
Watch for
Prototype fidelity is not checked against the task scope before sessions begin.
Recovery tip
If the logistics plan assumes participant availability or prototype readiness without checking, run a prototype walk-through against each task right now. A logistics gap discovered mid-session is unfixable — the same gap caught here takes five minutes to address.
Prepare the room, the evidence, and the working surface so the session can stay focused on synthesis.
A prototype, mockup, or scenario description with enough fidelity to support the planned tasks. The test plan is only as useful as the prototype is complete. If the prototype has significant coverage gaps, either extend it or narrow the task scope to match what the prototype actually covers.
Prototype or concept
Optional
Test objective list
Optional
Observation note sheet
Optional
Operational context note
Optional
Bring examples, pain points, or service evidence the room can point to quickly.
Remote facilitation choreography
Required
Pre-plan handoffs, breakout usage, and how people rejoin the main board.
Task script template
Required
Shared digital board with timer and voting
Required
Keep instructions and voting visible at all times.
Usability test plan
Keep the output usable, then use the recovery guidance when the room starts drifting.
What this does not produce
A usability test plan produces a testing protocol — not findings. The test needs to be run with actual participants before any insight is available. Teams that review the plan in the workshop and treat the task design discussions as findings ("we all agreed step 3 is confusing") mistake the planning session for the research.
Failure mode
Why it happens
Teams invest in a prototype and want the test to validate that investment. Objectives get framed as "proving the design is intuitive" or "confirming users understand the flow" — which produces a test designed to produce passing results rather than genuine insight. Moderators unconsciously guide participants toward success, and failure signals are downplayed.
Recover now
If this happens, rewrite each objective in the form "we need to understand where or whether..." This frame explicitly allows for failure and produces a plan that treats negative results as findings rather than as problems to explain away.
Prevent next time
Next time, before objectives are written, state the framing rule out loud: "A usability test is designed to find problems, not to confirm the design is good. An objective that can only produce a positive result is not a learning objective."
Failure mode
Why it happens
Task writers have deep familiarity with the interface and unconsciously include the labels they use internally. "Navigate to the billing settings" tells a participant exactly where to go — it tests whether they can follow instructions, not whether the information architecture is learnable. The test produces passing results for a task that would confuse real users who don't know the terminology.
Recover now
If this happens, read each task prompt aloud and circle any word that appears as a label in the interface. Remove every circled word and replace with the user's goal. "Navigate to the billing settings" becomes "Find where to update your payment method." The instruction describes the goal; the participant must find the path.
Prevent next time
Next time, after the first task draft is complete, run the label-removal check as a dedicated 10-minute editing pass.
Failure mode
Why it happens
Prototypes are often built to demonstrate a specific feature or flow, not to support all possible paths through a task. When a participant takes an unexpected route, they hit a dead end — a blank screen, a placeholder, or a broken link. The test result reflects the prototype's limitations rather than the user's behavior, and the insights are contaminated.
Recover now
If this happens, before the first session, walk through each task in the prototype following the most likely paths and 2–3 alternative paths. Mark any dead ends. Either extend the prototype to cover those paths or remove the task from the plan.
Prevent next time
Next time, in the logistics step, add a "prototype coverage check" as a required item — a walkthrough of every task in the prototype with a different participant playing the user.
Change the shape of the session only after the fit and runbook are clear.
Standard variant for Mixed in remote delivery. Waypoint is adapting timing, facilitation emphasis, prep, and recovery guidance here, but the room still needs final tailoring to the exact stakes and participants.
Use this after you have checked the fit and know you want to carry the method forward.
The pack is the fastest way to run this now. Use the links below when you need prep, sharing, or a saved reference point.
Guides
The secondary fit is narrower but real. The book strongly backs quick, low-overhead validation planning as a way to get evidence into the work before internal opinion hardens into direction.
Open this when you want stronger rationale before choosing the method or taking it into the workspace.
A planner-led brief on how one practitioner can use lightweight evidence, shared principles, portable artifacts, and steady coalition-building to improve decisions before a mature discovery function exists.
Sources and references used in this method page.
Nielsen Norman Group usability test fundamentals.
Reviewed 2026-02-27 by Discovery Waypoint Editorial Team