Write a usability test plan
Writes a usability test plan with scenario tasks, success metrics, participant criteria, a screener and a moderator script, tied to the research questions. Use before running a usability study.
Usability studies usually fail in the plan, not the sessions. Tasks reuse the interface's own labels and so give away the answer ("Click Workspaces and add a member"), tasks are not traceable to any research question, nobody defines what counts as success before the sessions, and the participants are whoever was easy to recruit. A good plan lets the team watch the right people attempt realistic goals and leaves no debate afterwards about what was measured.
Write a usability test plan.
- Rewrite each research question so it is answerable by watching behaviour. Flag questions a usability test cannot answer (willingness to pay, future intent, market size) and name the better method for each.
- Write 4 to 7 tasks, ordered as a user would naturally meet them. Each task:
- is a realistic scenario with a goal and a reason ("You just hired Ana and want her to see the Q3 board"), never a list of UI steps;
- avoids the exact words on the interface's buttons and menus;
- maps to at least one research question, and every question maps to at least one task;
- has a defined end state, a success rule (success / partial / fail, with what counts as partial) and a time limit after which the moderator moves on.
- Choose metrics: task success, time on task, errors or wrong paths, the Single Ease Question (1 to 7) after each task, and SUS or UMUX-Lite at the end. Say which metrics are meaningful at the planned sample size and which are only indicative.
- Define participants: behaviour-based inclusion criteria (what they do, not job titles alone), exclusions (employees, UX or market-research professionals, anyone who took a study in the last 6 months), and segments. Recommend 5 to 8 per segment for moderated qualitative testing, or 15 to 20 per segment for unmoderated studies that report metrics, and explain the trade-off. Write a short screener with disqualifying answers marked.
- Write the script for the method:
- moderated: welcome and consent to record, "we are testing the product, not you", think-aloud explanation with a practice task, 2 to 3 warm-up questions, the tasks, neutral probes ("What are you looking for?", "What did you expect to happen?"), and a debrief;
- unmoderated: self-contained written instructions, a think-aloud reminder, each task with its follow-up question, one attention check, and closing questions. Every task must be unambiguous without a moderator.
- Add an analysis plan (how notes will be captured, how severity will be rated), logistics (duration, tools, incentive, observers), and risks, including a pilot session before the real ones.
- If the product or the questions are too vague to write real tasks (no flows named, no idea what decision the study informs), ask up to three questions and stop.
- Do not invent product features, data or numbers. Where a task needs realistic content (an account, a record), say what test data must exist.
- Moderator prompts must be neutral: no leading questions and no confirming whether the participant is right.
- Keep the session length realistic: 45 to 60 minutes moderated, 15 to 25 minutes unmoderated.
- Include consent and data handling: what is recorded, who sees it, and how long it is kept.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Goals
Background in 2 to 3 sentences, then the research questions as rewritten, and any question routed to another method.
Method and logistics
Method, platform, session length, location or tool, observers, incentive.
Participants
Segments and counts, inclusion and exclusion criteria, then the screener as a numbered list with disqualifying answers marked.
Tasks
| # | Scenario (as read to the participant) | Research question | Success rule | Time limit |
Metrics
What is measured, how, and how it will be reported.
Script
The full moderator script, or the participant instructions for unmoderated.
Analysis plan
Risks and pilot
Weak task: "Go to Settings > Team and invite a new member." Strong task: "A new colleague, Ana, starts on Monday. Make sure she can see and edit the Q3 planning board before then." Success: Ana is invited with edit rights to that board. Partial: invited to the workspace but without board access. Limit: 4 minutes.
2 required values still a placeholder; the assistant will ask for them.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Design
- category
- UX research
- level
- Intermediate
- made for
- UX researcher, Product / UX / UI designer, Product manager
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install write-usability-test-plan --target claude-codenpx skills add hermes-hq/hodios-dist --skill write-usability-test-plan -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-design@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of UX researchSynthesize usability test findings
Turns raw usability session notes into evidence-backed issues rated by severity and frequency, with task results and recommendations. Use after a round of usability sessions.
synthesize-usability-findingsRun a heuristic evaluation
Evaluates a flow step by step against Nielsen's ten usability heuristics and returns located issues with severity ratings and concrete fixes. Use for a fast expert review before or between user tests.
run-heuristic-evaluationUX researcher
UX researcher who matches the method to the question, separates what people did from what it means, and protects participants. Use as a partner for planning, running and synthesising research.
ux-researcherAnalyse session recordings and heatmaps
Synthesises notes from session recordings and heatmaps into usability issues with frequency, severity and evidence, keeping observation apart from interpretation, and plans follow-ups.
analyze-session-recordingsBuild a user journey map from research
Builds an evidence-based journey map with stages, actions, thoughts, emotions, pain points and opportunities, marking every assumption. Use after interviews or studies about one segment.
build-user-journey-mapBuild evidence-based user personas
Builds UX personas from research notes, grouping participants by behaviour, with goals, pain points and scenarios traced to evidence and assumptions marked. Use after interviews or field research.
build-user-personas