Failure UX: What the User Sees When It Is Wrong

Failure UX: What the User Sees When It Is Wrong is the part of the design most teams discover after launch. A feature built on a component that is wrong at some rate will produce wrong answers in front of customers, on a schedule you can predict from the rate, so the wrong answer is a screen with a specification rather than an incident with a postmortem.

Key takeaways

• Four states need designing: working, unsure, wrong and caught before the commit, and wrong after the commit. Most products design the first and improvise the rest.
• Nielsen's heuristics still apply. Keep the user informed about what is happening, and write errors in plain language that name the problem precisely and suggest a way forward.
• Provenance is the cheapest correctness affordance there is. Showing the source beside the claim converts an unverifiable output into a checkable one without touching the model.
• Make correcting as cheap as accepting. If the fix path is slower than the accept path, users will accept things they believe are wrong, and your metrics will call that success.
• Never present unverified output in the same visual register as verified fact. A silent quality drop spends trust the product earned under different conditions.

Read this after Chapter 10, which needs the signals this surface collects, and before Chapter 12, which uses the same signals to decide whether the feature should exist. Chapter 4 built the reversal this chapter has to expose, and Chapter 5 built the decline it has to present.

The design review covers the happy path in detail. The error state is one line in the spec: show an appropriate error message.

What ships is a red box reading Something went wrong. Please try again. It appears for a timeout, for a rate limit, for a malformed response, and for the case where the model returned a confident answer that failed the policy check.

Four different situations, one message, no route forward. The support team learns to ask users to screenshot the box, because the box says nothing.

The wrong answer is a screen with a specification

Treating failure as an exception rather than a state is the root mistake, and the arithmetic makes it indefensible.

If a feature is wrong four times in a hundred and runs ten thousand times a week, it produces four hundred wrong answers a week. That is not an edge case. It is a forecastable event with a volume, and anything with a weekly volume in the hundreds deserves a designed surface.

The reframing that helps is to stop calling it an error. An error implies a malfunction. Here the system worked exactly as specified: it produced its best guess, and the guess was wrong. Chapter 1 established that as a property rather than a defect, so the interface has to represent it as a normal condition.

That distinction changes the copy, the visual weight and the controls. A malfunction gets an apology and a retry. A normal wrong answer gets a correction path and a way to tell you about it.

Four states, and most products design one

Enumerating the states is the fastest way to find the gaps in an existing design.

Working is the first. The system is doing something, and the user needs to know what, which is Nielsen's first heuristic: the design should always keep users informed about what is going on through appropriate feedback within a reasonable time. For an AI feature that means named stages rather than a spinner, because the stages also tell the user what the system is looking at, and a stage list is the cheapest form of explanation there is.

Unsure is the second, and it is the one Chapter 5 built. The system declined, the request went somewhere, and the user needs to know both facts. This is a state, not an error, and it should not look like one.

Wrong and caught is the third, and it is the state a drafting feature exists to create. The output is on screen, the user has spotted the problem, and the whole design question is how fast they can fix it. Every millisecond of friction here converts into an accepted mistake.

Wrong and committed is the fourth, and it is the one nobody specifies. The action already happened. The user needs to know what happened, when, what its effects were, and which control reverses it, and they need that without opening a support ticket.

An honest failure message has three parts

Nielsen's ninth heuristic gives the shape, and it has held up for three decades, so it is worth applying literally.

The heuristic, published by Jakob Nielsen in 1994 and updated on the Nielsen Norman Group site in January 2024, says error messages should be expressed in plain language rather than error codes, precisely indicate the problem, and constructively suggest a solution. Three requirements, and most AI failure messages satisfy none of them.

Plain language means naming what the system was doing, in the user's terms. Not a stack trace. Not a model name. Not the word inference. The supplier name on this invoice does not match any supplier in your records is plain language. Extraction validation failed is not.

Precisely indicate means being specific about which part failed. A message that condemns the whole output when one field was wrong makes the user redo work that was fine. That is the difference between a two-second fix and a two-minute one.

Constructively suggest means offering the next action, and for AI features three are usually worth offering: correct this specific thing, send it to a person, or discard it. Try again is only a real suggestion when the failure was transient. For a wrong answer it usually is not, since the same input will often produce the same mistake.

Provenance is the cheapest correctness affordance

Of everything in this chapter, showing the source beside the claim buys the most per unit of engineering effort.

The mechanism is simple. Each extracted field links to the region of the document it came from. Each sentence of a summary links to the passage behind it. Each figure in an analysis links to the query that produced it. Nothing about the model changes, and the reviewer's task changes completely.

What it changes is Chapter 2's verifiability gate, from the product side. An unverifiable output becomes verifiable when the evidence arrives with it, because the reviewer's job drops from recalling the source material to comparing two things placed next to each other. That is the single most reliable way I know to move a feature out of the quadrant where it should not ship.

Provenance also improves the failure state specifically. When the answer is wrong, the source usually shows why in one glance: the retrieval pulled the wrong contract, the value came from the prior year's column, the passage was about a different product. A user who can see the cause writes a useful report. A user who cannot writes it did not work.

There is a discipline required. A link to a source that does not support the claim is worse than no link, because it borrows the credibility of citation without earning it, so provenance needs a check that the cited passage actually contains the asserted content.

Make correcting as cheap as accepting

This is the design rule with the largest effect on real quality, and it is usually violated by accident.

Consider the asymmetry in a typical drafting interface. Accepting is one click on a prominent button. Correcting means clicking into a field, selecting text, retyping, tabbing onward, and re-reading the rest for consistency. Accepting costs a second. Correcting costs thirty.

Users under time pressure resolve that asymmetry the way anyone would. They accept things they suspect are wrong, because the suspicion is cheaper to carry than the correction, and your acceptance-rate metric records it as a success. That is Chapter 3's rubber-stamp drafting arriving through the interface rather than through the format.

Closing the gap is ordinary interaction design. Make each field individually editable in place. Offer the second-ranked alternative as a single click where one exists. Keep keyboard focus moving in the order a reviewer reads. Let a partial acceptance commit the good fields and route the bad one back.

The measurement that tells you whether you succeeded is the ratio of corrections to rejections. A feature where users overwhelmingly reject whole outputs rather than fixing parts of them has a friction problem in the interface, not necessarily a quality problem in the model.

What the four states owe the flywheel

Every one of these surfaces is also a collection point, and designing them together is much cheaper than retrofitting the instrumentation.

The last column is the one to design deliberately, because Chapter 10 showed that corrections and reversal reasons are the highest-value evidence the product can generate. A reversal button that records nothing about why is a wasted opportunity repeated a thousand times.

One field is worth adding everywhere: time to detection. How long between the wrong output landing and somebody noticing. That number tells you whether review is working, and it is the input to Chapter 4's argument about window length.

Three things the interface must never do

Some patterns are actively harmful rather than merely weak, and it helps to name them so they get caught in review.

Never present unverified output in the same visual register as verified fact. If three fields came from a system of record and two came from a model, they should not look identical, because the user is entitled to know which claims carry which warranty. Silent equivalence spends credibility the product earned elsewhere.

Never blame the user for the system's uncertainty. Copy along the lines of try rephrasing your question puts the failure on the person who asked, and while it is occasionally true, it is usually the interface avoiding an admission. Say what the system could not find, then offer the route.

Never let a failure state be a dead end. Every wrong answer needs at least one control that moves the user forward: a fix, a person, or an honest discard. A screen with only an apology on it is the one users screenshot and send to their account manager.

A worked example, composited and labelled

The details here are composited from ordinary production shapes rather than one system, and the shape is exact.

An expenses product photographs a receipt, extracts merchant, date, amount and category, and files the claim. The original interface showed four filled fields and a Submit button, with a single generic error state.

The redesign addressed all four states. Working shows the stages, so the user sees reading image, then finding amount, then matching merchant, which also explains the two-second wait. Unsure leaves the merchant field empty with the note that the logo was unreadable, and offers the three most recent merchants as one-click options. Caught before commit shows each field beside a crop of the region of the photo it came from, so checking the amount is a glance rather than a memory test. And wrong after commit puts a banner on the filed claim for twenty-four hours with an undo and a one-tap reason picker.

The reason picker mattered more than anyone expected. Because it was fast, people used it, and the five reasons they picked identified two systematic extraction failures within a fortnight.

Nothing here required a better model. It required deciding that the wrong answer was a state with an owner.

The objection: showing uncertainty destroys user trust

The commercial fear is that visible hedging makes the product look unreliable, and the fear has some evidence behind it in the wrong direction.

Kalai, Nachum, Vempala and Zhang argue in their September 2025 arXiv paper that language models are trained and evaluated under scoring regimes that reward confident guessing over acknowledging uncertainty, because a guess sometimes scores and an abstention never does. The same incentive operates on product teams: a confident interface demos better, so confident interfaces get built. The mechanism is identical, and so is the consequence.

The counter-evidence is what happens second. A user who acted on a confident wrong answer does not lose a little trust, they lose all of it, along with the willingness to use the feature unsupervised. A user who saw a flagged uncertainty and checked it retains a working model of when the feature is reliable, which is the thing that makes them use it more.

Where the objection is right is about volume and register. Uncertainty shown on most outputs is noise, and a hedge attached to everything teaches users to ignore hedges. So flag the specific field rather than the whole answer, keep the rate low enough that a flag means something, and phrase it as information rather than apology.

Chapter summary

A feature wrong four times in a hundred at ten thousand runs a week produces four hundred wrong answers a week, which is a forecastable event with a volume rather than an edge case. Calling it an error misdescribes it. The system worked as specified and its best guess was wrong. Four states need designing: working, which owes the user named stages rather than a spinner under Nielsen's first heuristic about keeping people informed; unsure, which is Chapter 5's decline and must not look like a fault; wrong and caught before the commit, where the only question is how fast the fix is; and wrong after the commit, which owes the user what happened, when, what it affected and which control reverses it. Nielsen's ninth heuristic gives the message shape, requiring plain language rather than codes, precise indication of which part failed, and a constructive next action. For AI features the useful actions are fix this field, send it to a person, or discard. Try again is only honest for a transient failure. Provenance is the cheapest correctness affordance available, since linking each claim to its source converts an unverifiable output into a checkable one and usually reveals the cause of a wrong answer at a glance, provided the cited passage is checked to support the claim. Correcting must cost about what accepting costs, because an interface where accepting is one click and correcting is thirty seconds produces accepted mistakes that the metrics record as success. Each state should be designed as a collection point for the flywheel, with time to detection recorded everywhere. And three patterns are forbidden: unverified output in the same visual register as verified fact, copy that blames the user for the system's uncertainty, and any failure state with no control that moves the user forward.

All of this assumes the feature deserves to keep existing. Some do not, and the evidence for stopping is usually available long before anybody is willing to read it. Chapter 12 is Deciding to Cut the Feature.