Design Debate

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