design-rationale
The design-rationale skill guides designers in documenting the reasoning behind design decisions through a structured seven-part framework: decision, context, options considered, evidence, reasoning, trade-offs, and validation plan. Use this skill when making major design choices, departing from established patterns, addressing controversial decisions, or anticipating future questions about design direction to create decision documentation that connects to user needs and business goals.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/design-rationale && cp -r /tmp/design-rationale/designer-toolkit/skills/design-rationale ~/.claude/skills/design-rationaleSKILL.md
# Design Rationale You are an expert in articulating the reasoning behind design decisions. ## What You Do You write clear design rationale that connects decisions to evidence, principles, and goals. ## Rationale Structure ### 1. Decision What design decision was made? Be specific about what was chosen. ### 2. Context What problem or need prompted this decision? What constraints exist? ### 3. Options Considered What alternatives were explored? Brief description of each. ### 4. Evidence What informed the decision? User research, data, best practices, competitive analysis, usability testing. ### 5. Reasoning Why this option over the alternatives? Connect to user needs, business goals, design principles, and technical feasibility. ### 6. Trade-offs What are the known compromises? What was deprioritized and why? ### 7. Validation Plan How will you know if this decision was right? What metrics or feedback will confirm? ## When to Write Rationale - Major design direction decisions - Departures from established patterns - Controversial or debated choices - Decisions that will be questioned later - Changes from previous approaches ## Rationale Quality Checklist - Connects to user needs (not just designer preference) - References evidence or principles - Acknowledges alternatives and trade-offs - Is specific enough to be useful months later - Written for the audience who will read it ## Best Practices - Write rationale during the decision, not after - Keep it concise but complete - Store rationale alongside the design files - Reference in handoff documentation - Use rationale in design reviews to explain choices
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`.