design-rationale
owl-listener/designer-skills
Write design rationale that connects decisions to user needs, business goals, and principles.
What is design-rationale?
Design Rationale helps you articulate the reasoning behind design decisions in writing. Use it when you need to defend a choice in documentation or asynchronous communication; for live conversations, use design-negotiation instead.
- Structure rationale with decision, context, options, evidence, reasoning, trade-offs, and validation plan
- Connect design choices to user needs, business goals, and design principles
- Document alternatives considered and explain why they were rejected
- Identify and acknowledge trade-offs and compromises in each decision
- Create rationale that remains useful for future reference and handoff
How to install design-rationale
npx skills add https://github.com/owl-listener/designer-skills --skill design-rationaleHow to use design-rationale
- 1.Identify the design decision that needs rationale
- 2.Describe the context and problem that prompted the decision
- 3.List the alternative options you considered
- 4.Gather evidence: user research, data, best practices, usability testing results
- 5.Write the reasoning connecting the chosen option to user needs and business goals
- 6.Document known trade-offs and what was deprioritized
- 7.Define how you will validate whether the decision was correct
Use cases
- Documenting major design direction decisions for stakeholder review
- Explaining departures from established patterns or previous approaches
- Recording reasoning for controversial or debated design choices
- Creating handoff documentation that justifies decisions to future teams
- Building a design decision log that can be referenced months later
- Product designers and design leads
- UX/UI designers making significant direction changes
- Design systems maintainers documenting pattern decisions
- Product managers defending design choices to stakeholders
- Teams conducting design reviews and critiques
design-rationale FAQ
Write rationale for major design decisions, departures from established patterns, controversial choices, decisions that will be questioned later, and changes from previous approaches. Write it during the decision-making process, not after.
Keep it concise but complete—long enough to be useful months later and specific enough that someone unfamiliar with the project can understand the reasoning.
Store rationale alongside your design files and reference it in handoff documentation. This makes it discoverable when future team members need to understand why decisions were made.
Use design-rationale for written documentation of decisions that need defending asynchronously. Use design-negotiation for live conversations and real-time discussion of design choices.
Write for your audience, connect to evidence and principles, acknowledge alternatives and trade-offs, be specific enough to provide context, and store it where it will be found during future work on the same design.
Full instructions (SKILL.md)
Source of truth, from owl-listener/designer-skills.
name: design-rationale
description: Write rationale connecting decisions to user needs, business goals, and principles. Use when a decision needs defending in writing. For a live conversation, use design-negotiation.
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
Related skills
More from owl-listener/designer-skills and the wider catalog.
design-review-process
Establish design review gates, criteria, and approval workflows to ensure consistent quality.
design-sprint-plan
Plan and run a focused design sprint from challenge to tested prototype in 5 days.
design-system-adoption
Drive design system adoption with strategy, enablement materials, and team engagement tactics.
design-system-governance
Define contribution models, versioning, and change management for multi-team design systems.
design-token
Define and organize design tokens for color, spacing, type, and elevation with systematic naming rules.
design-token-audit
Audit design token adoption and identify hard-coded values, gaps, and drift across your product.