AI Failure State Designer

An AI feature is judged by how it fails, because it will fail more often and more strangely than deterministic software.

What this skill is

A workflow that inventories the ways an AI feature can fail, separates failures the system can detect from those only the user can catch, and assigns each one a UI pattern, a recovery path, and microcopy. It replaces the generic "Something went wrong" with failure states that preserve work, explain what happened in plain terms, and give the user a next best action.

What it solves

• Every AI failure collapsing into one generic error message
• Hallucinations presented with the same confidence and styling as correct answers
• Refusals that lecture the user or give no alternative path
• Long waits with a spinner and no sense of progress or option to stop
• Partial results discarded entirely when one step or tool call fails
• Answers based on outdated information with no date context

When to invoke

• Designing a new chatbot, copilot, search assistant, or agent
• Support tickets describe dead ends, lost work, or "it just stopped"
• Writing or reviewing refusal and fallback copy
• Adding tool use or retrieval, which introduces new failure surfaces
• Launch readiness review requires a failure-handling spec

Phase 1: Inventory failure modes

Start from this taxonomy and add product-specific modes:

Phase 2: Rate frequency and impact

For each mode, estimate from evaluation data or logs:

Failure priority = Frequency (1-5) x Impact (1-5) x Detection difficulty (1-3)
Detection difficulty: 1 = system detects, 2 = user can easily notice, 3 = user unlikely to notice

Undetectable, high-impact failures (typically hallucination and outdated knowledge) rank highest because the interface is the only defense.

Phase 3: Assign UI patterns

Latency thresholds to design for:

Phase 4: Define recovery actions

Every failure state needs at least one forward action. Rank options by user effort:

1. Automatic recovery - silent retry or fallback model, only if the result is equivalent
2. One-click recovery - retry, try a narrower request, use a different source
3. Guided recovery - suggested rephrasing, clarifying question, or form fallback
4. Manual path - link to the non-AI way to do the job
5. Human path - handoff to support with context preserved

Rules: never discard user input; never retry silently more than twice; never auto-retry an action with side effects.

Phase 5: Write the microcopy

Microcopy formula:

[What happened, plainly] + [What it means for the user] + [What they can do next]

Voice rules: first person for the assistant is acceptable, but no apologies longer than three words, no blaming the user, no anthropomorphic feelings ("I'm so sorry, I feel terrible"), and no technical codes in the primary message.

Output

• Failure mode inventory with detectability and priority scores
• Pattern assignment table per failure mode
• Latency treatment spec with time thresholds
• Recovery action ladder per failure mode
• Microcopy library (primary message, secondary detail, action labels)
• Instrumentation list to measure each failure's frequency in production

Operating rules

Always

• Design for undetectable failures, not just the ones the system can catch
• Preserve user input and completed work through every failure
• Pair every refusal with an alternative path
• Show progress stages and a stop control for long waits
• Date-stamp time-sensitive answers

Never

• Use a single generic error for all AI failures
• Style unverified claims identically to cited ones in high-stakes contexts
• Auto-retry actions that have side effects
• Blame the user's prompt in error copy
• Hide a partial failure inside a success message