---
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:
  1. What you chose
  2. What you didn't choose (and why)
  3. What principle guided the decision
  4. 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)