AI Products Are Shipping Without Designed Error States. The Damage Is Accumulating.
The error message problem in AI products isn't a copywriting problem. It's a category error.
When a form submission fails, the error is binary. It worked or it didn't. The system knows which. The UI can say "payment failed — please try again" because the payment system has a definitive answer.
When an AI feature fails, you often don't know it failed. The model returns something. It's fluent. It's confident. It might be completely wrong, subtly wrong, outdated, or a hallucination that will look correct until someone tries to use the output in the world. The system doesn't have a definitive answer because the system doesn't know what "correct" is — that's the whole reason AI is involved in the first place.
This is the fundamental design challenge that AI products are mostly ignoring. Showing users what the AI is doing is one design problem. Showing users that the AI might be wrong — when the AI itself doesn't know — is a different and harder one.
The Problem Nobody's Designing For
Walk through the design documentation for most AI features: the happy path gets full treatment. The feature works, the output renders, the user is delighted. The error states get a paragraph at best — usually a generic "something went wrong, try again" pattern copied from non-AI product design.
This isn't negligence. It's category confusion. Product teams have well-established error patterns for deterministic systems: the system state is known, the error is discrete, the recovery path is clear. Apply those patterns to AI and you get an interface that lies by omission.
The lie is this: a visible error signal means the system knows something went wrong. Absence of an error signal means everything worked. In AI products, the second half of that is frequently false. A language model that returns a confidently-stated hallucination generates no error signal. The product tells the user things are fine. The user acts on bad information. Nobody knows until the consequence surfaces.
Why AI Errors Are Different From Regular Errors
Standard error taxonomy: the system tried to do something, it failed, there's a known failure reason.
AI error taxonomy is different at every level.
Type 1: Silent wrong answer. The model generates output that is factually incorrect but rendered normally. No error flag, no low-confidence signal, no distinction in the UI between this and a correct answer. This is the most dangerous failure mode and the most common.
Type 2: Misinterpretation. The model understood a different question than the user asked. The output is internally coherent but answers the wrong thing. The user doesn't know whether to trust it or re-prompt. The UI gives them no signal either way.
Type 3: Stale or out-of-scope data. The model answers from a training cutoff or from context it wasn't given. The output is confident, might have been correct at a different time or in a different context, and is now misleading. This is especially common in RAG products where the retrieval quality varies.
Type 4: Low-confidence-high-fluency. The model is uncertain but doesn't signal it because the system isn't exposing confidence scores. Fluency is not confidence — models produce grammatical, authoritative-sounding text at low internal confidence. The UI makes both look identical.
Type 5: Capability refusal. The model can't do what was asked (context limits, safety constraints, genuine capability gap) and the response is a version of "I can't help with that." The UX for this is usually an awkward, unexplained rejection that leaves users with no recovery path.
Each of these needs a different design response. A single "something went wrong" pattern handles exactly none of them.
The Confidence Signal Problem
The fundamental challenge is that AI error design requires surfacing uncertainty that most products don't expose.
Most LLM API responses include some form of confidence or probability signal — token probabilities, logprobs, structured confidence outputs. Most product integrations ignore these entirely. The output is treated as binary: the model returned something, display it. The confidence information is discarded at the integration layer before it ever reaches the UX.
This is a recoverable design decision. Products that expose even rough confidence signals to users show measurably better downstream trust calibration. When a user sees "this answer is based on limited information" or notices an interface signal that the AI isn't certain, they verify before acting. When everything looks the same, they verify nothing.
The problem is that raw confidence scores are meaningless to most users, and calibrated confidence communication is hard to design well. "73% confident" communicates less than a well-designed visual treatment that distinguishes high-confidence outputs from low-confidence ones without exposing numbers at all.
Agentic UX design patterns have been grappling with a related problem — how to show users what an AI agent is doing so they can meaningfully supervise it. Error state design is the complement: how to show users when the AI is uncertain so they can meaningfully verify it.
Five AI Failure Modes, Five Design Responses
A useful starting taxonomy for design teams:
Hallucination (silent wrong answer): The design response is verification affordance, not error message. UI elements that make it easy to check the output — source citations, "verify this" links, checkable claims presented structurally. Don't tell users you might be wrong; make it easy to check.
Misinterpretation: Show the question the AI understood, not just the answer. "I understood you to be asking about X — here's what I found" lets users correct the premise before acting on the wrong output.
Stale or out-of-scope data: Source timestamps and retrieval context. If a RAG product pulled from documents dated 2023, that's visible information that should be in the UI. "Based on documents from [date range]" changes how users interpret the output.
Low-confidence output: Visual differentiation between confident and uncertain outputs. This doesn't require exposing raw confidence scores. It requires a design system that has a defined pattern for "hedged output" — different visual treatment that tells users to treat this differently.
Capability refusal: Clear explanation and a concrete next step. "I can't answer this because [reason]" plus "Here's what you could do instead" is a vastly better UX than an unexplained rejection. The next step might be to rephrase, to provide more context, or to go to a different source.
What Error Recovery Actually Looks Like
Recovery from AI errors is different from recovery from system errors. In a form submission failure, the recovery is: fix the problem, resubmit. Discrete, clear.
In AI error recovery, the user needs to know: was this wrong? How wrong? Do I need to re-prompt, verify externally, or discard the output entirely?
The design work here is in making the conversation navigable. Products that handle this well tend to share a few patterns:
Persistent source visibility: users can always see what context the AI used to generate an answer. This makes external verification possible and gives users a mental model of why the output might be unreliable.
Edit and regenerate: the ability to modify the prompt or context and regenerate, with the previous output still visible for comparison. This makes the exploration of "was this wrong?" concrete.
Inline flagging: users can flag specific claims within an AI output as suspect, which both guides their own verification work and (if the product collects this signal) helps improve the model.
None of this is revolutionary. All of it requires deliberate design investment that most AI product teams aren't currently prioritizing. The happy path is finished and shipped. The error states are on the backlog.
That backlog is where trust is quietly eroding.
Photo: A broken laptop screen displayed with colorful glitch (Beyzanur K.)