| name | design-rationale |
| description | Defend a design decision to skeptical stakeholders with structure and evidence. Use when presenting design work, writing design documentation, or pushing back on requests to change something. |
Design Rationale
Convince the room with structure, not feelings.
How to use
/design-rationale Apply rationale constraints to defend design decisions in this conversation.
Constraints
Rationale Structure
- MUST include all four elements in one paragraph:
- What you chose
- What you didn't choose (and why)
- What principle guided the decision
- What outcome you expect
- MUST connect to user behavior or business goals, not aesthetic preference
- NEVER defend a design decision with "it feels right" or "it looks better"
Anticipate Objections
- MUST address the most likely pushback before it's raised
- SHOULD acknowledge what's lost by this choice (the tradeoff)
- MUST have a fallback position if the primary argument doesn't land
Anti-Patterns
- Defending decisions by appealing to authority ("Apple does it this way")
- Using data as a shield without explaining the logic ("our A/B test showed...")
- Getting defensive when challenged instead of engaging with the objection
- Over-explaining simple decisions (not every choice needs a thesis)
