Design Rationale
A design rationale document captures the "why" behind design decisions.the context, constraints, alternatives considered, and reasoning that led to a particular solution. While designs themselves show what was built, rationale documents preserve institutional knowledge about why it was built that way.
When to Use
- When making significant UX decisions that affect user experience
- Before design reviews to prepare stakeholder discussions
- When multiple valid approaches exist and the choice needs justification
- To onboard new team members to existing design decisions
- When revisiting past decisions to understand original reasoning
- During design system evolution to document pattern choices
When NOT to Use
- The decision is architectural or a technology selection -> use
develop-adr(Nygard format) - You need stakeholder alignment on the overall solution direction -> use
develop-solution-brief - You are documenting exploration findings rather than a decision -> use
develop-spike-summary - The decision is trivially reversible and low-stakes: a rationale document adds ceremony; record the reasoning in the PR or ticket instead
Instructions
When asked to document design rationale, follow these steps:
-
State the Decision Begin with a clear, one-sentence summary of what design decision was made. This becomes the title and reference point for the document.
-
Describe the Context Explain the situation that prompted this decision. What problem were you solving? What constraints existed? What user needs informed the direction? Include relevant research findings.
-
List Options Considered Document at least 2-3 alternatives that were evaluated. For each option, describe what it would look like and its key characteristics. Be fair to all options.avoid strawmen.
-
Define Evaluation Criteria Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles.
-
Explain the Reasoning Walk through why the chosen option best meets the criteria. Be explicit about trade-offs.what you gained and what you sacrificed. Acknowledge where the decision is reversible vs. irreversible.
-
Document Trade-offs Accepted Every design decision involves trade-offs. Name what you gave up and why it was acceptable. This honesty helps future teams understand constraints.
-
Note Follow-up Considerations Capture anything that needs attention later: metrics to watch, conditions that might warrant revisiting the decision, or related decisions to make.
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete rationale fills every template section: Decision Summary; Context; Options Considered; Evaluation; Decision Rationale; Trade-offs Accepted; Reversibility; Follow-up Considerations; Supporting Materials; and Decision History.
Quality Checklist
Before finalizing, verify:
- Decision is clearly stated in one sentence
- Context explains the "why now" and constraints
- Multiple alternatives are documented fairly
- Evaluation criteria are explicit
- Reasoning addresses why chosen option beats alternatives
- Trade-offs are honestly acknowledged
- A reader who inherits this design can reconstruct why the chosen option won without asking anyone
Examples
See references/EXAMPLE.md for a completed example.