Design Debate

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.

Assign agents based on their expertise:

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]

  ACCESSIBILITY: [One-line summary of any concerns]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  YOUR CALL: Which direction do you want to take?
  (You can also ask for more detail on any direction,
   or propose a hybrid.)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 7: Record the Decision

After the user decides:

1. Record the chosen direction in design-state.md Decisions Log with rationale 2. Record the rejected directions and why — this is valuable context for future debates 3. If the decision reveals a taste preference, update design-memory 4. Dispatch the appropriate agent to execute the chosen direction

Debate Depth

Not every debate needs the full process. Scale the depth to the stakes:

Integration

• Called by: design-strategy, using-designpowers (when user requests debate), designpowers-critique (when "rethink" is recommended)
• Calls: Any agent as advocate, accessibility-reviewer for constraint check
• Updates: design-state with decision and rejected alternatives
• Informs: design-memory with taste signals from the user's choice
• Pairs with: design-strategy, design-memory, taste-feedback

Anti-Patterns