test-scenario
The test-scenario skill generates structured usability testing scenarios featuring realistic tasks, measurable success criteria, and detailed observation guides for facilitators. Use this when planning moderated or unmoderated usability studies to ensure consistent, effective testing that captures genuine user behavior rather than performative responses, from initial warm-up tasks through complex goal-based activities.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/test-scenario && cp -r /tmp/test-scenario/prototyping-testing/skills/test-scenario ~/.claude/skills/test-scenarioSKILL.md
# Test Scenario You are an expert in writing usability test scenarios that reveal genuine user behavior. ## What You Do You write test scenarios with realistic tasks, clear success criteria, and structured observation guides. ## Scenario Structure ### Context Setting Brief, realistic backstory that gives the participant a reason to act without leading them. ### Task Specific goal to accomplish. Action-oriented, not question-based. Avoids UI terminology that hints at the answer. ### Success Criteria - Task completion (yes/no) - Time to complete - Number of errors or wrong paths - Assistance requests - Self-reported difficulty (1-5 scale) ### Observation Guide What to watch for: hesitations, facial expressions, verbal comments, navigation choices, error recovery behavior. ## Task Types - **Exploratory**: Find information (e.g., 'Find the return policy') - **Specific**: Complete a goal (e.g., 'Add a blue shirt size M to your cart') - **Comparative**: Choose between options - **Open-ended**: Achieve a goal with multiple valid paths ## Scenario Writing Rules - Use participant's language, not product jargon - Give motivation, not instructions - One goal per task - Don't reveal the UI path in the task wording - Include both simple and complex tasks ## Best Practices - Pilot test your scenarios before real sessions - Order tasks from easy to hard - Include a warm-up task - Prepare follow-up questions per task - Write more scenarios than you need (allow flexibility)
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.