Pretend you are the design lead so soft UX claims and missing usability evidence fail before the next ship date turns them into support load.
Optimistic product packs optimize for the flow they wish users had. The design-lead seat does the opposite. It asks which step has no owner, which claim lacks a study or support ticket, which accessibility gap is deferred without a date, and which "simple" path fails for a careful first-time user. A polished mock is not evidence that the experience survives real use.
This is one of the core moves in a product or launch war game: after you describe the UI change, seat a careful design-lead perspective and make it try to stall. The output you want is not taste theater. It is a short list of material gaps, the exhibits each needs, and the edits that would survive a real release week.
How to cast the seat
Name a real mandate: ship a defined flow without raising support volume, protect accessibility commitments, or underwrite a conversion claim with evidence. Give constraints: the audience, the evidence standard for "ready," and the residual risk you will not invent away. Without constraints the seat becomes cartoonish. With constraints it produces questions you might actually hear in critique.
Write the seat into the prompt as a named role with a mandate. Example: "Design lead: list the top reasons this flow would confuse a careful first-time user, the claim with the weakest evidence, the accessibility or empty-state gap that worries you most, and the ten diligence questions you would send product after review. Stay inside a realistic mandate and avoid illegal tactics."
What to demand from the pass
- Top reasons the flow would confuse or delay a careful user.
- The claim that looks strongest and is least evidenced in the pack.
- The accessibility, empty-state, or edge-case gap that would worry you most.
- What would make you trust the ship plan enough to sign without quiet redesign later.
- The ten hardest questions you would send in writing after critique.
Run that brief in Pingpong against the real specs, research notes, and support themes. Follow with a home-team response pass so you leave with edits and named owners, not only fear. When the change sits near billing or account deletion, run this seat after legal and support attacks so it can use earlier objections as ammunition.
When the plan leans on a single prototype, a single happy path, or a single designer, force the seat to price concentration risk in writing. Ask what happens if that person is out, if research is stale, or if mobile paths were never tested. Concentration that only appears in an appendix still counts.
Pair with pretend you are the CPO, war-game a product launch, stress-test an accessibility commitment, war-game a feature request triage, and the war-game decisions hub. See how to run a Pingpong.