Designing for Errors

Ask an engineer how to handle AI errors and the conversation quickly turns to model confidence scores, retrieval accuracy, and fallback logic. All of that matters. But the moment a user sees wrong output, reads a confident fabrication, or watches a feature silently produce nothing, the experience is entirely a design problem. The model may have produced a reasonable token sequence; the product failed to communicate its uncertainty, offer a path forward, or catch the user before they acted on bad information.

The Google PAIR People+AI Guidebook frames this well: AI mistakes are inevitable, so design for them as a first-class use case — not a footnote handled with a generic error banner. The Microsoft Human-AI Interaction guidelines go further, describing the need to help users understand the AI's limitations throughout their experience, not just when something breaks.

That framing changes the design brief. Instead of "what error message do we show?", the question becomes:

• How do we set expectations before the AI responds, so the error is less surprising?
• How do we signal during the response that certainty is not guaranteed?
• How do we make it easy to correct when the output is wrong?
• How do we recover when the user has already acted on a bad output?

These four questions map to the four main topics of this lesson. But first, we need a shared vocabulary for the different ways AI goes wrong, because the design response is different for each.

The stakes are not uniform. An AI writing assistant producing a slightly awkward sentence is a minor inconvenience. An AI medical summary omitting a contraindication is a safety issue. An AI financial analysis inventing a figure that ends up in a board presentation is a reputational crisis. Error design must be proportionate to consequence — and your first task as a product designer is to decide, honestly, which category your feature sits in.

AI errors are not random noise. They fall into recognisable categories, each with a different design signature — the kind of thing that makes it worse or better from a user experience perspective.

Failure mode 1: Hallucination. The AI generates plausible-sounding content that is factually wrong, invented, or unsupported by the source material. The output looks correct; it reads fluently; it may be entirely fabricated. This is the highest-trust failure because users have no natural alarm signal — nothing looks broken. A research assistant confidently citing a journal article that does not exist; a chatbot giving a wrong product price with full confidence; a summarisation tool inventing a statistic that was not in the document.

Failure mode 2: Graceful degradation. The AI is unavailable, times out, or produces output so poor it cannot be used. Unlike hallucination, the product can detect this — the API returned nothing, the confidence score fell below threshold, the output failed a validation check. The design challenge is not signalling uncertainty in the output; it is deciding what the product does instead, and making sure the user can still accomplish their goal.

Failure mode 3: Silent error. The AI produces output that is wrong or unhelpful in a way that is difficult to detect — a subtly incorrect tone in a generated email, a recommendation that happens to be outdated, a categorisation that is systematically biased for a particular user group. These errors do not announce themselves. They accumulate. The design challenge is building correction and feedback surfaces that catch them over time, rather than in the moment.

These three modes rarely appear in isolation. A scheduling agent might hallucinate the conference room booking policy (mode 1), then fall back to a manual booking flow (mode 2), while silently building an incorrect model of the user's preferred meeting times (mode 3). Good error design addresses all three.

The rest of this lesson works through each mode in depth, but the table above is worth committing to memory. When a new AI feature is on the table, run through all three rows and ask: does our design handle this?

Hallucination is the most dangerous failure mode because users cannot see it coming. The design goal is not to eliminate hallucination — you cannot control the model — but to design the interface so that users appropriately calibrate their trust in AI output, check what matters, and are not surprised when something is wrong.

There are four main tools in the hallucination UX toolkit: hedging language, visual uncertainty cues, source attribution, and human-review prompts. Used well, they reinforce each other without making the product feel anxious or unusable.

Hedging language is the most accessible tool. It means writing the interface copy — labels, response prefixes, empty states, and onboarding text — so that users understand the AI is generating, not confirming. The difference between "The answer is..." and "Based on the information provided, this appears to be..." is small in word count and significant in trust calibration.

A before-and-after comparison makes this concrete. Imagine an AI assistant in an HR product that answers policy questions.

Before (overconfident):

"Your notice period is 3 months."

After (appropriately hedged):

"Based on the standard employment contract template, the notice period is typically 3 months. Verify this against your specific contract before acting on it."

The second version is still useful — it answers the question — but it prompts the verification behaviour that matters for a consequential output.

> Examples of hedging language for an AI product interface:
> 
> "Based on [source], this appears to be..."
> "I wasn't able to confirm this — you may want to check..."
> "Here's a suggested answer. Review before sending."
> "This is a draft — some details may need verifying."
> "I'm not certain about this. Here's what I found..."

Visual uncertainty cues communicate confidence without adding words to the output. The approaches that work in practice include:

Source attribution is the single most trust-building pattern available when the AI is working from a document corpus or database. When a user can click through to the exact passage the AI cited, two things happen: they can verify the claim, and they viscerally understand the AI is drawing on real sources rather than confabulating. Perplexity and Bing Chat popularised this pattern; enterprise search and document intelligence products have followed.

Human-review prompts are appropriate when the output is consequential. These are interface elements — not error states — that appear as part of the normal flow: "Review before sending," a confirmation modal before an AI-drafted message is submitted, or a sidebar checklist of things to verify before publishing an AI-assisted report. The key is that they must feel like a natural part of the workflow, not a speed bump. If users find ways around them, the prompt is poorly designed, not the behaviour it is trying to encourage.

Graceful degradation is what happens when the AI component of your product is unavailable, returns unusable output, or falls below a confidence threshold that your system can detect. Unlike hallucination, this is a known failure state — and that means the product can respond purposefully rather than silently.

The worst response to degradation is a broken-looking interface: a spinner that never resolves, an empty results panel with no explanation, or a generic "something went wrong" banner that gives the user nowhere to go. The best response keeps the user productive — either through a fallback experience that uses non-AI means to accomplish the same goal, or through partial output that is clearly labelled as incomplete.

The degradation design matrix. Before writing fallback logic, map each AI-powered surface in your product to this matrix:

The key design insight is that degradation is a spectrum, not a binary. At one end, the AI component is a nice-to-have enhancement and its absence is invisible. At the other end, the AI component is the product, and its absence means the user has no path forward. Every point on that spectrum needs a different design response.

Partial output patterns. Sometimes the AI starts a response but cannot complete it — a generation that times out mid-way, a summarisation that covers the first half of a document but not the second, an extraction that identifies three of five required fields. Partial output is often better than no output, but only if the product is honest about what is missing.

Design principles for partial output:

• Make it visually obvious where the output ends and the gap begins
• Label the gap explicitly: "Could not process the remaining sections"
• Give the user a clear action: manual completion, retry, or contact support
• Never allow partial output to be submitted or shared as if it were complete — build a confirmation or gate

Status messaging during degradation. If the AI is processing asynchronously and the user needs to wait, the interface should communicate progress honestly. "Analysing your document (usually under 30 seconds)" is better than a generic spinner. "This is taking longer than expected — we'll notify you when it's ready" is better than letting the user wonder if they should refresh. The Microsoft Human-AI Interaction guidelines call this "making it easy for users to understand the system's state" — a principle that applies especially when that state is 'not working as expected'.

The moment a user spots an AI error, you have a design decision to make: how easy do you make it to fix it, and what do you offer them beyond a blank edit field? Correction flow design is one of the highest-leverage areas in AI product UX because it directly determines whether users keep trying or give up.

There are three correction mechanisms to design for, and most AI features need all three:

1. Inline editing. The simplest and most universal correction surface. The AI produces output and the user edits it directly, as they would any piece of text. The design questions are subtle: Is the output visually editable (does it look like a text field or a static label)? Does edit history work so users can undo? If the user edits, does the system treat the output as confirmed, or does it try to regenerate over the user's changes?

Common mistake: AI outputs that regenerate automatically when a parameter changes, overwriting the user's manual edits. This destroys the sense of control. Once a user has edited output, their version should be treated as authoritative unless they explicitly ask for a new generation.

2. Regenerate with guidance. The user wants a fresh attempt but wants to steer it differently, without starting from scratch. This is the "try again but..." pattern. The interface offers a way to provide corrective instruction — a prompt field, a set of adjustment sliders, or a list of refinement options — and regenerates with that guidance applied.

> Examples of regeneration guidance surfaces:
> 
> A text field: "Tell us what to change..." (open-ended)
> Preset buttons: [Shorter] [More formal] [Different approach]
> A slider: Tone: Casual ←→ Formal
> A checklist: "What was wrong?" [Too long] [Wrong tone] [Missing detail]

The checklist approach is especially valuable because it gives the product signal about why the output was wrong — implicit feedback that can inform model improvement over time. Lesson 5 covers this feedback loop in depth.

3. Alternative suggestions. Rather than regenerating one new output, the product offers multiple alternatives and lets the user choose. This pattern works well for short outputs where variance is valuable — subject line suggestions, reply options, image captions, product name ideas. GitHub Copilot uses this pattern for code completions; many writing tools use it for sentence rewrites.

The design principle is to show enough alternatives to surface genuine variety (typically three) without overwhelming the user with a wall of options. Each alternative should be meaningfully different — not three paraphrases of the same idea. If the model cannot generate genuinely distinct options, this pattern should not be used; three near-identical suggestions teaches users that the feature is not very powerful.

Surface and timing. Correction affordances must appear at the right moment. Too early (before the user has read the output) and they are invisible. Too late (buried in a settings panel) and the user has already given up. The patterns that work:

Correction flows handle the case where the user spots an error before acting on it. Error recovery handles the harder case: the user acted on bad AI output, the downstream consequences are now real, and the product needs to help them get back to a good state.

This is the domain most AI product teams under-design. The assumption is that because the error happened outside the product (the user sent the wrong email, booked the wrong meeting, submitted the wrong data), recovery is the user's problem. But products that earn long-term trust are those that take some responsibility for the consequences of their failures — even when those failures happened at the model level, not the application level.

Recovery has three phases: detection, triage, and repair.

Detection. The product needs a way to learn that something went wrong. For explicit failures (the API returned an error, the validation rule failed), detection is automatic. For semantic failures (the AI answered confidently but incorrectly), detection depends on user signals: they came back to edit, they clicked "this was unhelpful," they filed a support ticket, or they undid an action. Build these signals into your product as first-class events, not afterthoughts.

Triage. Not all errors need the same recovery path. A usability framework borrowed from incident response works well here:

Repair. The repair path varies by error type, but the design principles are consistent:

• Make the path to recovery as short as the path to the mistake. If a user can publish an AI-generated article in three clicks, they should be able to retract it in three clicks.
• Where undo is not possible, offer the next-best thing: a template to communicate the correction, a log the user can export, or a human contact they can escalate to.
• Acknowledge the failure without burying the user in apology. "We generated incorrect information — here's how to correct it" is better than three paragraphs of corporate hedging.

Designing the full error arc. A complete error-recovery design covers three scenarios:

The happy path: The AI produces correct, useful output. The user acts on it with confidence. No friction, no doubt, efficient task completion. Design this experience first — it should feel effortless.

The subtle error: The AI produces output that is mostly right but has a factual mistake, a wrong tone, or a missing detail. The user catches it before acting on it (or just after). Correction flows come into play. The goal is that fixing the error takes less effort than the error caused — so the user's net experience is still positive.

The catastrophic failure: The AI produced output that was badly wrong, the user acted on it, and the consequences are real. Recovery flows come into play. The goal is to restore the user's confidence in the product — not just fix this instance, but demonstrate that the product learns from its failures and takes them seriously.

> A framework for auditing your error arc:
>
> Happy path: Is the output clearly useful and appropriately confident?
>             Does it invite correction without demanding it?
>
> Subtle error: Does the user have an obvious path to correct?
>              Is correction faster than deletion and retyping?
>              Does the correction provide signal back to the system?
>
> Catastrophic failure: Is there an undo path or next-best alternative?
>                       Is there a clear escalation route?
>                       Does the product acknowledge the failure honestly?

The capstone exercise in this lesson is drawing the three-scenario flow map for an AI feature you are building or evaluating. This is a design artefact that makes error handling explicit, reviewable, and testable — rather than an implicit assumption that "the model will usually be right."

The map has three columns, one per scenario, and five rows:

A completed map for an AI email reply assistant might look like this:

When to build a lighter-weight version. If a full three-scenario map is too heavyweight for your current stage, start with a single question for each scenario:

For the happy path: does the interface help users act on correct output with confidence, without friction?

For the subtle error: if the user spots a mistake, what is the single next action the product offers?

For the catastrophic failure: if something goes badly wrong, is there a human path — a support route, an undo, a way to escalate — that is easy to find?

These three questions, answered honestly, will surface the majority of undesigned error states in most AI features.