/design-debate

name: design-debate
description: Use when a design direction is uncertain, when the team could go multiple ways, or when the user wants to see competing approaches argued before committing — orchestrates structured debate between agents who advocate for different directions

Design Debate

Good design decisions come from tension, not consensus. When agents converge too quickly, they optimise for agreement instead of the best answer. This skill creates productive conflict — agents argue for competing directions with real trade-offs, and the user decides.

When to Use

• When the design-strategist identifies multiple viable directions
• When the design-lead proposes a visual direction and alternatives exist
• When the user says "I'm not sure which way to go" or "what are my options?"
• When the design-critic recommends "rethink" — a debate can surface the better path
• When a decision has significant downstream consequences (navigation pattern, layout model, interaction paradigm)
• When the user explicitly asks for a debate: "debate this", "argue both sides", "what are the trade-offs?"

Do Not Use When

• The decision is trivial (icon choice, exact padding value)
• Accessibility requirements dictate the answer — there is nothing to debate
• The user has already made up their mind — respect their direction
• The brief clearly specifies the approach — follow it

Process

Step 1: Frame the Question

Define the design question precisely. A debate without a clear question produces noise.

Format:

DESIGN QUESTION: [Specific, answerable question]
CONTEXT: [Brief context from design-state.md]
CONSTRAINTS: [Non-negotiable requirements from brief, accessibility, taste profile]
STAKES: [Why this decision matters — what it affects downstream]

**Example:**

DESIGN QUESTION: Should the onboarding flow use a multi-step wizard or a single scrollable page?
CONTEXT: App for first-time pet owners, ages 25-45. Primary persona has mild anxiety about "doing it right."
CONSTRAINTS: Must be completable in under 3 minutes. Must work on mobile. Must not require account creation upfront.
STAKES: Sets the interaction pattern for all future multi-step flows in the app.

Step 2: Assign Advocates

Select 2-3 agents to argue for different directions. Each agent argues FOR their assigned position — they are advocates, not neutral analysts.

| Role | What They Argue | |------|----------------| | **Advocate A** | The case for Direction A — strengths, evidence, personas it serves best | | **Advocate B** | The case for Direction B — strengths, evidence, personas it serves best | | **Advocate C** (optional) | A third direction, a hybrid, or a "neither — here's why" position |

Assign agents based on their expertise:

| Agent | Best suited to advocate for | |-------|---------------------------| | **design-strategist** | UX patterns, information architecture, user flow approaches | | **design-lead** | Visual directions, layout models, component architecture | | **content-writer** | Content strategy approaches, tone directions, naming conventions | | **motion-designer** | Interaction paradigms, feedback models, transition approaches | | **accessibility-reviewer** | The most inclusive option, cognitive load implications | | **design-scout** | Evidence-backed positions from competitive research |

Step 3: Run the Debate

Each advocate delivers their argument in this format:

## [Agent Name] argues for: [Direction]

### The Case
[2-3 paragraphs making the strongest possible argument for this direction.
Be specific — reference the brief, personas, principles, and evidence.]

### Who This Serves Best
[Which personas benefit most and why]

### Who This Serves Least
[Which personas might struggle and why — be honest]

### Trade-Offs
[What you give up by choosing this direction]

### Evidence
[Research, patterns, competitive examples, or design principles that support this]

Rules for advocates: 1. **Argue to win** — make the strongest case you can. Do not hedge 2. **Be honest about weaknesses** — a strong argument acknowledges its trade-offs 3. **Reference the brief** — ground arguments in the project's actual goals 4. **Reference personas** — every argument must address who it helps and who it doesn't 5. **No straw men** — do not weaken the opposing position to make yours look better

Step 4: Cross-Examination

After all advocates present, each gets one round of rebuttal:

### [Agent Name] responds to [Other Agent]:
[1-2 paragraphs directly addressing the strongest point of the opposing argument.
Concede what is true. Challenge what is weak.]

This prevents echo-chamber advocacy — each agent must engage with the other side's best arguments.

Step 5: Accessibility Check

Before presenting to the user, the **accessibility-reviewer** evaluates all proposed directions:

## Accessibility Assessment

| Direction | Accessibility Impact | Concern Level |
|-----------|---------------------|---------------|
| Direction A | [Assessment] | Low / Medium / High |
| Direction B | [Assessment] | Low / Medium / High |

[If any direction creates accessibility barriers, flag it clearly.
This is not an argument for a direction — it is a constraint check.]

If a direction has High accessibility concern, it should be flagged prominently in the presentation to the user. The user can still choose it, but they should know the cost.

Step 6: Present to User

Show the debate to the user in a structured format:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  DESIGN DEBATE
  Question: [The design question]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  DIRECTION A: [Name]
  Argued by: [agent]
  [2-3 sentence summary of the case]
  Best for: [personas]
  Trade-off: [key trade-off]

  DIRECTION B: [Name]
  Argued by: [agent]
  [2-3 sentence summary of the case]
  Best for: [personas]
  Trade-off: [key trade-off]

  [DIRECTION C if applicable]

  ACCESS