Run a Four-Lens Red-Team Critique Panel

Workflow area: Ideation & Critique · Tier: Core · Hands-on time: ~35 minutes

Human critique is precious and scarce: you get thirty minutes a week of colleagues' attention, and half of it goes to explaining context. An adversarial AI panel is the opposite — unlimited, context-loaded, and completely tireless — which makes it perfect for the brutal first pass that leaves human critique free for judgment calls. The trap is treating the panel's output as a to-do list. Red-team findings are attacks, and some attacks deserve to lose. The decision log — accept, reject, and why — is what turns an AI pile-on into design reasoning you can defend in any review.

When to use — and when not to

• Use it when a concept is formed but not committedafter the direction exists, before high-fidelity investment; attacks are cheapest to absorb here.
• Use it before every stakeholder reviewwalking in with "here are the four strongest objections and our answers" converts skeptics faster than any polished mock.
• Use it on your favorite idea especiallythe concept you are in love with is the one whose flaws you have stopped seeing.
• Skip it during early divergenceattacking half-formed sparks kills the fragile ones; red-team after ideas have bones (pb-04 and pb-05 come first).
• Skip it as a consensus machineif you accept every finding, you did not run a critique, you outsourced your judgment; the panel proposes, you decide.

The recipe

1. 1.

   Package the concept for attack. One paragraph of intent (who it serves, what job, what success looks like), plus screenshots or the flow description. The panel can only attack what you show it — thin context produces generic attacks.

2. 2.

   Convene the four lenses in one structured prompt. Run in Claude or ChatGPT with images attached where you have them:

   Copy

   You are a red-team critique panel reviewing a design concept.
   Concept: [PASTE INTENT PARAGRAPH + ATTACH SCREENS / FLOW]
   
   Attack it from four separate lenses. For each lens produce the 3
   strongest findings — concrete, specific to THIS concept, no generic
   design advice.
   
   LENS 1 — SKEPTICAL USER: you are a busy, distrustful target user.
   Where do you bail? What feels like vendor benefit dressed as user
   benefit? What would you do instead of using this?
   
   LENS 2 — ACCESSIBILITY: attack for exclusion — vision, motor,
   cognitive, situational. Name the WCAG criterion or user group per
   finding.
   
   LENS 3 — WHY WILL THIS FAIL: you are the post-mortem author two
   years from now. What killed it? Adoption? A wrong assumption?
   An edge case at scale? Misaligned incentives?
   
   LENS 4 — FEASIBILITY: you are the tech lead. What is 10x more
   expensive than the design assumes? What data does it require that
   we do not have? What degrades at 100x load or 1% of users?
   
   Format each finding: LENS / claim (one sentence) / evidence or
   reasoning (two sentences) / severity guess 1-3.
   Do not soften. Do not balance criticism with praise.
   

3. 3.

   Push each lens one level deeper. First-pass findings skim. Follow up per lens: "Finding S2 — make it concrete: script the exact moment the skeptical user bails, with what they see on screen and think." Attacks that survive concretization are the real ones; attacks that dissolve into vagueness were noise.

4. 4.

   Adjudicate every finding into the decision log. This is the artifact. For each finding, record accept / reject / investigate, plus rationale:

   Copy

   #   LENS   FINDING                      DECISION     RATIONALE
   S1  Skept  Value prop reads as          ACCEPT       Rewrite hero copy;
              time-tracking surveillance                test framing in pb-02
                                                        study
   A2  A11y   Drag-to-prioritize has no    ACCEPT       Add up/down buttons;
              keyboard path (WCAG 2.1.1)                non-negotiable
   F1  Fail   "Teams will maintain tags"   INVESTIGATE  Check tag decay in
              assumption is historically                analytics before
              false here                                betting the IA on it
   E3  Feas   Real-time sync cost          REJECT       Phase 1 is single-
                                                        player; sync is v2
                                                        scope, not this bet
   

5. 5.

   Fold accepted findings back and re-run once. Revise the concept, then run the panel again on the revision. Findings that reappear despite your fix are telling you the fix was cosmetic. One re-run is discipline; endless re-runs are procrastination with extra steps.

Make it yours

• Split the panel across two models: run skeptical-user and why-will-this-fail in Claude, accessibility and feasibility in ChatGPT — different models attack differently, and duplicate findings across models are your highest-confidence signals.
• Add a fifth domain lens: compliance for fintech, clinical safety for health, trust-and-safety for social — one lens slot rotates by product domain.
• Pre-mortem workshop mode: run lens 3 live in a team session — the AI drafts ten failure narratives, the team votes on the three most plausible, and those become the risks the design must answer this sprint.

Quality check

• Findings are concept-specifican attack that would apply to any product ("users may find it confusing") is filler; demand the on-screen moment.
• Every finding got a logged decisionan unadjudicated finding is a loose end that will resurface as someone else's gotcha.
• You rejected somethinga log with zero rejections means the panel is steering, not sparring.
• Rejections carry reasons, not reflexes"out of phase-1 scope" is a rationale; "disagree" is a mood.
• Accessibility accepts turned into requirementsan accepted WCAG finding that never reaches the spec was accepted only emotionally.