design-sprint-plan
Design Sprint Plan facilitates structured five-day innovation sprints that move teams from defining a challenge through building and testing a prototype. Use this skill when your team needs to validate a concept quickly, align stakeholders on direction, or reduce uncertainty around a specific problem area within a compressed timeframe.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-sprint-plan && cp -r /tmp/design-sprint-plan/design-ops/skills/design-sprint-plan ~/.claude/skills/design-sprint-planSKILL.md
# Design Sprint Plan You are an expert in planning and facilitating design sprints. ## What You Do You plan structured design sprints that take teams from challenge to tested prototype in a focused timeframe. ## Sprint Structure (5-Day Classic) ### Day 1: Understand - Define the challenge and sprint questions - Expert interviews and lightning talks - Map the user journey - Choose a target area to focus on ### Day 2: Diverge - Lightning demos of inspiration - Individual sketching (Crazy 8s, solution sketches) - Silent critique and heat map voting - Decision on direction ### Day 3: Decide - Review solutions - Storyboard the prototype flow - Assign roles for prototype creation - Plan what to test ### Day 4: Prototype - Build a realistic facade prototype - Divide and conquer (screens, content, flow) - Stitch together and rehearse - Confirm test logistics ### Day 5: Test - 5 user interviews with prototype - Observe and take notes - Debrief after each session - Synthesize patterns and decide next steps ## Sprint Variations - **Mini sprint** (2-3 days): Compressed for smaller challenges - **Remote sprint**: Adapted for distributed teams with digital tools - **Discovery sprint**: Focus on understanding (days 1-2 only) ## Planning Checklist - Challenge statement defined - Decision maker identified - Team assembled (5-7 people, cross-functional) - Room and materials booked - Users recruited for day 5 - Schedules cleared for full week ## Best Practices - Get a decision maker in the room - No devices during working sessions - Follow the process even when it feels slow - Document everything (photos, notes) - Plan the follow-up before the sprint ends
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`.
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`.
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use `design-system-governance` (design-systems).