design-rationale

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)