When AI Gets It Wrong: Designing Error States for Generative Features

Traditional software has a clean relationship with failure. Something breaks, a clear error appears, the user understands something went wrong and knows what to do next. Generative AI features break this contract entirely. They return output confidently regardless of whether that output is correct, partially correct, or entirely fabricated. Most teams shipping AI features design for the success state. Almost none design seriously for the failure states. That gap is where user trust collapses.

Why AI Failure Is Fundamentally Different

When a form submission fails, the interface shows a red border around the field that caused the problem. The error is localized, explicable, and fixable. The user knows exactly what went wrong and what to do. The failure mode is transparent.

Generative AI failure has none of these properties. The model does not know when it is wrong. It does not have a mechanism for distinguishing between a response it is confident about and a response it is guessing at. Both arrive in the same format, at the same speed, with the same tone of authority. The user receives the output and has no immediate way of knowing whether to trust it.

This is not a temporary limitation of current models. It is a structural characteristic of how large language models work. They are trained to produce fluent, contextually appropriate text. Fluency and accuracy are independent dimensions, and the model optimizes for the former without any direct feedback loop from the latter. Vectara's 2026 hallucination benchmark reports a best-case hallucination rate of 3.3% for current frontier models, with several reasoning models exceeding 10%. On niche or recently-updated topics, hallucination rates on factual citation tasks rise to 15 to 20% for leading models, according to research tracking GPT-4o and Claude across medical and legal domains in 2025 and 2026.

For a product team, this means that any AI feature producing factual claims, recommendations, summaries, or decisions will generate incorrect output at a statistically meaningful rate. The only design question is what happens to the user when it does.

The Psychology of Confident Wrongness

The damage that AI failure does to user trust is disproportionate to the frequency of the failure, and the reason is psychological.

Researcher Berkeley Dietvorst's work on algorithm aversion, published in the Journal of Experimental Psychology, found that people often prefer flawed human judgment over algorithmic decision-making after witnessing even a single algorithmic error. The effect is not gradual. It is a cliff edge: one clearly visible mistake is enough to cause users to abandon the algorithmic system entirely in favor of a slower, less accurate human alternative. That research was conducted on traditional algorithmic systems. Generative AI makes the phenomenon more acute because the errors are harder to anticipate, harder to detect in the moment, and more jarring when they are discovered.

The NNg State of UX 2026 report captures what is already emerging in user behavior: users are fatigued by AI features that fail them without warning, and the backlash against what they describe as AI slop is accelerating. When an AI feature produces incorrect output confidently, users do not just lose trust in that specific output. They recalibrate their trust in the entire product. The interface signed the check that the model could not cash.

This is why the McKinsey 2025 Global Survey on AI found that nearly one-third of respondents reported consequences from AI inaccuracy within their organizations, and why 51% of organizations using AI had seen at least one negative consequence. The damage is not theoretical. It is operational, reputational, and in regulated industries, legal.

A Taxonomy of AI Failure States

Designing effective error states for generative features requires a precise understanding of the different ways those features can fail. They are not all the same, and they do not all call for the same design response.

1. Total fabrication

The model produces output that has no factual basis. Names, citations, dates, statistics, and conclusions are invented from whole cloth. The output sounds plausible and is formatted correctly. There is no internal signal to the user that anything is wrong.

This is the failure mode documented by NeurIPS 2025 analysis, where 66% of hallucinated citations in academic papers fell into the total fabrication category. It is also the failure mode most likely to go undetected in products where users are not domain experts and cannot easily evaluate factual claims.

A legal AI product that fabricates a case citation causes immediate, severe, and visible harm when the user acts on it. A consumer product that fabricates a product recommendation or a health statistic causes harm that is diffuse, delayed, and harder to trace back to the feature.

2. Partial attribute corruption

The model produces output that is mostly correct with specific factual details wrong. A real person is cited, but their affiliation, year, or specific claim is incorrect. A real study is referenced, but the finding is misrepresented. The genuine content creates plausibility. The corrupted detail creates the damage.

This category represented 27% of hallucinated citations in the NeurIPS 2025 analysis. It is significantly harder to detect than total fabrication because users who recognize the real components often extend trust to the corrupted ones.

3. Semantic drift

The model produces output that is technically accurate at the word level but incorrect or misleading in its meaning or implication. A summary that captures all the facts but assigns them different relative weight than the source. A recommendation that is literally true but contextually inappropriate for the user's situation. A paraphrase that subtly changes the meaning of the original.

Semantic drift is the failure mode most resistant to fact-checking because the individual claims survive scrutiny while the overall output misleads. It is particularly dangerous in summarization features, where users rely on the model to accurately represent a larger body of information they have not read themselves.

4. Scope failure

The model attempts to answer a question that is outside its reliable knowledge, either because the topic is too recent, too niche, or too domain-specific for the model's training to support a reliable response. Rather than declining, the model extrapolates, producing output that sounds authoritative but is structurally unsupported.

This is the failure mode that drives high hallucination rates on recent or niche topics. The model has learned that confident, complete-sounding responses are rewarded in training. Producing a confident response to a question it cannot reliably answer is, from the model's perspective, behaving correctly.

5. Intent misalignment

The model understands the literal request correctly but misses the underlying intent. A user asking to "clean up" an email receives a completely rewritten email when they wanted only light proofreading. A user asking for a summary of a document receives a condensed version that omits the specific section they needed. A user asking the AI to "help" with a task receives a completed version of that task rather than assistance with it.

Intent misalignment rarely produces factually wrong output. The output is often high quality on its own terms. The failure is in the relationship between what the user wanted and what the model produced. It is frequently invisible in accuracy metrics and consistently visible in user satisfaction data.

6. System and context failure

These are failures caused not by the model but by the infrastructure around it: a timeout that returns an empty response without explanation, a rate limit that silently degrades output quality, a context window that is exceeded and causes the model to lose track of earlier parts of a conversation. These failures are deterministic rather than probabilistic, which makes them more designable, but they are often treated as purely engineering problems and not given UX design attention.

AI Failure State Reference

Why Most Teams Are Not Designing for These States

The failure to design for AI error states is not usually a failure of awareness. Most product teams can describe the failure modes above when asked about them. The failure is structural.

AI features are typically built in three stages: the feature is prototyped, the happy path is refined, and the feature ships. Error state design is either deferred to a later sprint that never comes, delegated to engineering as a graceful degradation problem, or simply not included in the feature scope at all.

The NNg State of UX 2026 analysis describes this pattern directly: teams pour resources into making their AI look good in success states and ignore the experience of failure. This is the opposite of what trust-building requires. Users who never encounter a failure do not form strong trust in a product. Users who encounter a failure that is handled well form significantly stronger trust than they had before the failure occurred. Service recovery research has documented this effect in traditional products for decades. The same dynamic applies to AI features, but with higher stakes because the failures are less predictable and more jarring.

Design Principles for AI Error States

Designing for AI failure states requires a different set of principles than traditional error state design. The goal is not just to communicate that something went wrong. It is to maintain user confidence, preserve the user's work and context, and provide a clear path forward, all in a situation where the nature and extent of the failure may not be fully knowable.

Principle 1: Make uncertainty visible before failure occurs

The most effective trust-building intervention happens before the failure is detected, not after. Designing confidence signals into the AI interface gives users the context to apply appropriate scrutiny to outputs that warrant it, rather than treating all AI output as equally reliable.

PlantNet, the plant identification app, displays probability percentages alongside every identification. A result showing "92% match: Japanese Maple" communicates reliability. A result showing "48% match" communicates that the user should verify before acting. That single design decision transforms blind trust into calibrated judgment without requiring the user to know anything about how the model works.

The key design judgment is selectivity. Confidence indicators attached to every output create noise and erode the signal value of the indicator itself. Roger Attrill's April 2026 analysis of resilient conversational AI design notes this directly: confidence scores can feel like a gimmick if applied indiscriminately. Use them where errors have meaningful consequences, such as medical queries, financial recommendations, irreversible actions, and factual claims on high-stakes topics.

Principle 2: Keep the user's original input intact

One of the most damaging aspects of AI failure is the loss of context. A user who submits a carefully crafted prompt and receives a wrong or misaligned response needs to be able to recover without starting over. Error states for AI features should always preserve the original prompt, the conversation history up to the point of failure, and any user-provided context.

The UX Patterns for Developers AI error state framework identifies this as a core requirement: keep the original prompt visible for recovery. This is not just a convenience feature. It is a trust signal. A product that preserves the user's work when the model fails communicates that the product is on the user's side. A product that loses the user's input on a model failure communicates indifference.

Principle 3: Name the failure type honestly

Generic AI error messages, such as "Something went wrong" or "Please try again", are inadequate for generative features because the nature of the failure determines the appropriate recovery path. A scope failure calls for a different response than a system timeout. A response the model is uncertain about calls for a different treatment than a response that was cut off by a context window limit.

Users can accept honest uncertainty from an AI feature. What they cannot accept is being treated as if the failure is unimportant or unexplainable. The Smashing Magazine analysis of AI trust design, published in September 2025, frames this precisely: prioritize the "I don't know" experience as a critical feature rather than an error state. A well-designed refusal, citing the specific reason the model cannot reliably answer, builds more trust than a confident wrong answer. Teams should lobby for the engineering and content resources required to make this experience genuinely useful.

Principle 4: Provide a specific recovery path for every failure type

Each AI failure type calls for a different recovery action, and the interface should make that action explicit rather than leaving users to figure it out themselves.

• Total fabrication and scope failure: offer to connect the user with a human expert, a curated source, or a search-based alternative. Do not invite a retry on the same prompt without giving the user tools to ground the response.
• Partial attribute corruption: surface the sources the model drew from, with direct links, so the user can verify specific claims. Perplexity's approach of inline numbered source citations that show gaps in coverage makes the verification path explicit without adding friction to the main flow.
• Semantic drift: offer the user a path to see the original source material alongside the AI output, making comparison possible without requiring them to leave the product.
• Intent misalignment: design a lightweight correction mechanism that lets users specify what was wrong about the output rather than starting from scratch. A clarification prompt that asks "was this more or less detailed than you wanted?" or "should I change the tone?" recovers from intent misalignment in two interactions rather than requiring the user to rewrite their original prompt.
• System and context failure: be explicit about the cause and the fix. "The response was too long for this session" with a button to continue in a new context is forgivable. A blank response with a spinner that eventually times out is not.

Principle 5: Design the feedback loop as a product feature

User feedback on AI output quality is one of the highest-value data inputs a product team can collect, and most products design the feedback mechanism as an afterthought. A thumbs up or thumbs down at the bottom of every response is not a feedback mechanism. It is a gesture toward one.

Meaningful feedback design for AI features collects information about which specific part of a response was wrong, what type of error it was, and what the user expected instead. This information is the foundation of the product's ability to improve output quality over time, to identify systematic failure modes that affect specific user segments, and to build the trust metrics that Smashing Magazine's 2025 framework recommends: hallucination rate, successful fallback rate, and correction acceptance rate alongside standard engagement metrics.

AI Error State Design Checklist

What This Looks Like for Specific Feature Types

The principles above apply broadly, but the specific implementation varies significantly by feature category. These are the categories where AI failure state design most commonly falls short.

Summarization features

Summarization is one of the most common AI features in enterprise and productivity products, and one of the most prone to semantic drift and scope failure. Users who rely on a summary to represent a longer document they have not read have no immediate mechanism for detecting when the summary has misrepresented the original.

Effective error state design for summarization features includes showing the word count and section coverage of the original alongside the summary, flagging when the source document contains content in a language or format the model handled with lower confidence, and offering direct navigation to the specific sections of the source that correspond to key claims in the summary.

Recommendation features

Product recommendation, content suggestion, and action recommendation features are prone to intent misalignment and scope failure. The model optimizes for the most statistically likely interpretation of the user's request, which may not match the user's actual need.

Effective error state design here includes a lightweight "not what I was looking for" path that lets users correct the model's interpretation without rewriting their request, a visible explanation of why each recommendation was surfaced, and a hard fallback to a human-reviewed set for users who repeatedly reject AI recommendations.

Content generation features

Writing assistance, email generation, and document drafting features are primarily prone to intent misalignment. The output is often high quality in isolation while being wrong for the specific context.

Gmail Smart Compose demonstrates a well-designed recovery pattern: predicted completions disappear instantly when the user types something different. The model's suggestion is non-committal by design. The user retains complete control without any explicit rejection action required. This pattern, a non-sticky default that yields to user input without friction, is one of the clearest examples of designing AI output so that the cost of being wrong is minimal.

The Teams That Win at AI Are the Ones Who Design for Failure

The companies building the most trusted AI-powered products in 2026 are not the ones with the highest model accuracy. They are the ones whose products behave well when the model is wrong.

That distinction matters because model accuracy is largely outside the product team's control. The difference between a 3.3% hallucination rate and a 5% hallucination rate is significant at scale, but it is determined by the underlying model and the grounding infrastructure around it. The difference between a product that handles a 5% failure rate gracefully and one that handles it badly is entirely a design decision. It is made in wireframes, content strategy sessions, and sprint planning meetings, not in model training.

Users who encounter a failure that is handled honestly, preserves their context, and gives them a clear path forward do not lose trust in the product. Research on service recovery consistently finds that customers who experience a problem that is handled well report higher satisfaction than customers who never experienced a problem at all. The same dynamic is available to AI product teams. It requires treating failure state design as a first-class design problem rather than an afterthought.

The AI feature that admits it does not know something is more trustworthy than the one that fabricates an answer. The product that preserves the user's work when the model fails is more trustworthy than the one that loses it. The interface that tells users when to be skeptical is more trustworthy than the one that presents everything with equal confidence. These are design decisions, not model improvements. They are available right now, to every team shipping AI features, regardless of which model they are using.