Panic Design Field Guide

Panic design means designing for the moment when everything goes wrong: urgency, failure, degraded context, and consequence are treated as first-class test inputs.

Artifact workbench Paste, upload, or drag profile, report, card, and bundle JSON Seeded artifact Open the Checkout Timeout Panic Card

Urgency

Time pressure changes how people scan, decide, and recover. The interface must reveal the next safe action fast.

Failure

Failure copy, recovery actions, and preserved state need to sit together so users do not hunt under stress.

Degraded context

Distraction, interruption, weak connectivity, and assistive technology can all reduce the context a user has available.

Consequence

The design should make the cost of failure clear and reduce avoidable loss before the user reaches the worst moment.

Urgency example Replay the reservation timer pressure moment

See how a visible countdown changes the checkout recovery path.

Failure example Inspect the payment authorization failure

Follow the worst moment from evidence to consequence and fix.

Recovery example Open the retry-path Panic Card

Keep user state, failure, recovery test, and fix in one review artifact.

Protocol example Validate imported artifact JSON

Confirm a profile, report, card, or bundle can render without private app state.

How to use it in review

Start with a Panic Profile that names the user state, trigger, pressure, and consequence.
Run or replay the flow until the worst moment is visible as evidence, not opinion.
Create a Panic Card from a finding so the recovery test and recommended fix stay attached.
Use the artifact workbench to validate profile, report, card, or bundle JSON before replay.
Keep public artifacts seeded and explicit; private evidence stays local unless a sharing manifest includes it.