AI Product Design

Error States for Model Failures

AI systems fail in unique ways — hallucinations, rate limits, incomplete outputs, toxic responses. This guide covers how to design error states that maintain trust and provide a path forward.

#error states#model failure#hallucination#rate limit#ai errors#fallback#trust

What is it?

AI model failures are categorically different from traditional software errors. Where traditional errors are binary (worked/didn't work), AI failures include: confident but incorrect outputs (hallucinations), incomplete generations, toxic or harmful outputs, out-of-distribution inputs, rate limit errors, and context window overflows. Each requires a distinct error design strategy.

Why it matters

A single poorly-handled AI error can destroy user trust in the entire system, even if the model is highly accurate on average. Research shows that users apply disproportionate weight to negative experiences with AI — one dramatic failure outweighs many successes. Error states for AI must simultaneously communicate the failure, protect the user from incorrect information, and give them a clear path forward.

Best Practices

  • Categorize your expected failure modes before designing error states. Hallucinations, rate limits, content policy refusals, and context errors each need different UI responses.
  • For hallucinations (confidently wrong outputs): the output should be presented with editability and a feedback mechanism. Users must be able to flag wrong information.
  • For refusals (content policy blocks): explain why the request was declined and offer alternatives. Avoid vague "I can't do that" without guidance.
  • For rate limit errors: communicate clearly how long the wait is and offer queueing or notifications when capacity is available.
  • For incomplete outputs (context overflow, timeout): show what was generated, indicate it is incomplete, and offer a path to complete it.
  • Never silently substitute a fallback output without telling the user the original request failed.
  • Preserve user input on failure. If an AI generation fails, the user's prompt must not be lost.
  • Offer a non-AI fallback path for critical functions. If the model is unavailable, users should not be completely blocked.

Common Mistakes

  • Generic error messages: "Something went wrong" — tells the user nothing actionable.
  • Silently filtering or truncating AI outputs without informing the user.
  • Rate limit errors with no indication of wait time or retry path.
  • Content policy refusals that are opaque — "Unable to process this request" with no guidance.
  • Presenting partial outputs as complete outputs.
  • No feedback mechanism for users to flag wrong AI outputs.
  • Auto-retrying failed requests without user awareness — leads to multiple charges, confusing results, or submission duplicates.

Checklist

Research & Theory

Negativity Bias in Human-AI Trust (Dietvorst et al., 2015)

Users who observe an AI system making a mistake are significantly less likely to use it again — even when the AI outperforms human alternatives overall. This is "algorithm aversion."

Why it's relevant

A single visible AI failure disproportionately damages trust. Design failure states that normalize and contextualize errors rather than hiding them.

Microsoft's HAX Guideline 8: Support efficient invocation

Make it easy for the user to dismiss, ignore, or correct AI output and continue their work.

Why it's relevant

Error recovery for AI should be low-friction. The user should not be punished — stuck or blocked — because of a model failure.

Real-World Examples

ChatGPT

Network error states preserve the conversation context. "Regenerate response" option for unsatisfactory outputs. Content policy refusals explain the policy category. Thumbs-down feedback on every response.

Claude (Anthropic)

Refusals are contextualized: "I'm not able to help with X because Y. I can help with Z instead." Maintains a helpful tone even in failure states.

GitHub Copilot

When suggestion generation fails or times out, falls back to standard code completion rather than blocking the user. Errors are silent but recoverable — the developer's workflow continues uninterrupted.