name: design-rationale
description: Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied. Use when making significant UX decisions, aligning with stakeholders on design direction, or preserving design context for future reference.
license: Apache-2.0
metadata:
category: specification
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
version: "1.0.0"
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
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.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: design-rationale3description: <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->4---5
6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7---
8name: design-rationale
9description: Documents the reasoning behind design decisions including alternatives considered, trade-offs evaluated, and principles applied. Use when making significant UX decisions, aligning with stakeholders on design direction, or preserving design context for future reference.
10license: Apache-2.0
11metadata:
12 category: specification
13 frameworks: [triple-diamond, lean-startup, design-thinking]
14 author: product-on-purpose
15 version: "1.0.0"
16---
17
18# Design Rationale
19
20A 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.
21
22## When to Use
23
24- When making significant UX decisions that affect user experience
25- Before design reviews to prepare stakeholder discussions
26- When multiple valid approaches exist and the choice needs justification
27- To onboard new team members to existing design decisions
28- When revisiting past decisions to understand original reasoning
29- During design system evolution to document pattern choices
30
31## Instructions
32
33When asked to document design rationale, follow these steps:
34
351. **State the Decision**
36 Begin with a clear, one-sentence summary of what design decision was made. This becomes the title and reference point for the document.
37
382. **Describe the Context**
39 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.
40
413. **List Options Considered**
42 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.
43
444. **Define Evaluation Criteria**
45 Specify how options were assessed: usability heuristics, technical feasibility, brand alignment, user research findings, business requirements, or design principles.
46
475. **Explain the Reasoning**
48 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.
49
506. **Document Trade-offs Accepted**
51 Every design decision involves trade-offs. Name what you gave up and why it was acceptable. This honesty helps future teams understand constraints.
52
537. **Note Follow-up Considerations**
54 Capture anything that needs attention later: metrics to watch, conditions that might warrant revisiting the decision, or related decisions to make.
55
56## Output Format
57
58Use the template in `references/TEMPLATE.md` to structure the output.
59
60## Quality Checklist
61
62Before finalizing, verify:
63
64- [ ] Decision is clearly stated in one sentence
65- [ ] Context explains the "why now" and constraints
66- [ ] Multiple alternatives are documented fairly
67- [ ] Evaluation criteria are explicit
68- [ ] Reasoning addresses why chosen option beats alternatives
69- [ ] Trade-offs are honestly acknowledged
70- [ ] Document is useful to someone inheriting this design
71
72## Examples
73
74See `references/EXAMPLE.md` for a completed example.