Sweep Every Screen for Missing States

Workflow area: Figma AI & Prototyping · Tier: Foundation · Hands-on time: ~25 minutes per flow

Missing states are the highest-volume design defect in shipped products, and they're missing for a boring reason: enumeration is tedious and happens under deadline. This is the exact shape of task AI is best at — exhaustive, mechanical, checklist-like — and the exact shape designers skip. The judgment stays with you: which enumerated states are real for this product, and what each one should actually do. The model brings the completeness; you bring the truth.

When to use — and when not to

• Use it before every handoffthe state sweep is the cheapest moment to catch a missing error state; the most expensive is a production incident ticket.
• Use it when estimatinga feature is its state matrix, not its happy path; sweeping early stops the "oh, plus error handling" schedule surprise.
• Use it on inherited or legacy flowsa sweep of an old flow produces the defect backlog nobody had time to write.
• Skip the full matrix for throwaway explorationspb-04 concept fodder doesn't need an offline state; sweep only what's heading toward engineering.
• Skip states your platform genuinely can't hitbut write down why they can't, because "can't happen" is the most-falsified phrase in software.

The recipe

1. 1.

   Describe the flow to the model, screen by screen. Screenshots plus text beat text alone. In Claude or ChatGPT, attach screens and run:

   Copy

   You are doing a state-completeness sweep on a product flow.
   
   Flow: [e.g. "expense submission: form → receipt upload → review →
   confirmation"]
   Platform: [web/iOS/Android] · Data source: [e.g. "REST API, can be
   slow or down"] · Users: [e.g. "includes RTL locales, offline field
   staff"]
   Screens attached: [ATTACH SCREENSHOTS OR PASTE DESCRIPTIONS]
   
   For EACH screen, enumerate the state matrix:
   empty / loading / partial-load / error (each distinct error cause) /
   offline / permission-denied / long-content & overflow / zero-results
   / first-use / RTL / slow-connection / stale-data.
   For each cell: LIKELY (real for this product), EDGE (possible,
   decide), or N/A (impossible here — say why).
   Then list states MY HAPPY-PATH SCREENS ALREADY HANDLE so I can see
   the true gap. Do not invent screens I didn't provide.
   

2. 2.

   Curate the matrix — this is the design judgment step. Walk every LIKELY and EDGE cell and mark it: design it, defer it (ticketed), or kill it (with the reason recorded). Good curation output looks like:

   Copy

   Upload screen · error: file-too-large   → DESIGN (support data:
   top-3 ticket driver)
   Upload screen · offline                 → DESIGN (field staff,
   §research Q2)
   Review screen · RTL                     → DEFER (no RTL locale
   until FY26 — ticket DS-412)
   Form · stale-data                       → KILL (form is
   client-side only; no server state to go stale)
   

3. 3.

   Draft the DESIGN states with AI assistance, decide the content yourself. For each state you're designing, the layout is usually mechanical (your empty-state pattern exists) but the content is judgment. Draft copy in the model — cause, consequence, next action per pb-28's rubric — then build the states in Figma from your design-system patterns, as component variants where your system supports them, not as detached one-off frames.

4. 4.

   Attach the matrix to the file. Paste the curated matrix (including KILL reasons) on a page beside the flow. This is half of pb-12's spec pack already written — and the KILL reasons are what save the next designer from re-litigating them.

5. 5.

   Re-sweep when the flow changes. A new data source, a new permission, a new platform target each add a matrix column. Sweeps age like personas do; the trigger is any change to what the screen depends on.

Make it yours

• Claude Project with your standing context: store platform, locales, API behavior and your design-system's existing state patterns in Project instructions — every sweep then starts pre-contextualized, and the model stops proposing states your system already solves globally.
• ChatGPT with your PM's edge-case folklore: feed it the support team's top-20 ticket categories alongside the screens; state sweeps grounded in real ticket data produce LIKELY ratings you can defend in prioritization.
• Gemini for Android-specific matrices: its Android platform knowledge is strong on process-death, back-stack and permission-flow states that generic sweeps under-enumerate.

Quality check

• Every screen got the full matrixa sweep that skipped the "simple" confirmation screen missed the screen most likely to be missing states.
• Every cell has a decisionLIKELY cells without design/defer/kill marks are the gap surviving in disguise.
• KILL reasons are written down"can't happen" claims are recorded so reality can falsify them politely later.
• Drafted states use system componentsa state sweep that spawns twelve detached snowflake frames trades one defect class for another; check token and component provenance.
• Error states name real causes"Something went wrong" copied twelve times means the content judgment step was skipped; each distinct cause earns distinct copy.
• The matrix lives with the filea sweep in a chat transcript is a sweep that didn't happen by next sprint.