AI Error Handling UX: How to Design for Incorrect or Incomplete AI Responses

Design AI features expecting four kinds of failure: system errors, wrong outputs, incomplete outputs and wrong actions. Preserve user input and offer retry and alternatives when systems fail; make wrong outputs detectable with sources, highlights and side-by-side verification; ask clarifying questions instead of guessing on ambiguous requests; let users edit, regenerate and select alternatives; prevent wrong actions with previews and confirmation, and recover from them with undo, clear change records and escalation to a person.

The engineering side of failure handling, such as retries, fallbacks and circuit breakers, is in LLM application reliability. General patterns are in AI UX design and capturing corrections as feedback in AI feedback UX.

Users can only fix errors they notice. Make verification easy at the point of use: show extracted values next to the source document region, link claims to passages, highlight low-confidence fields, and show diffs for proposed changes. For high-stakes outputs, design review steps that require looking at the evidence. Automation bias, the tendency to accept automated outputs, is reduced when evidence is visible and checking is quick.

When a request is ambiguous and the cost of a wrong guess is meaningful, ask. Good clarifying questions are short, offer likely options ('Do you mean the March invoice or the April one?') and remember the answer for the rest of the task. Do not ask when context makes the answer clear; unnecessary questions feel obstructive.

Offer regenerate with optional guidance ('more concise', 'use only the 2026 policy'), keep earlier versions accessible and preserve the original request. Let users edit outputs directly, and when they do, keep their edits rather than overwriting them on the next generation. Where a correction indicates a systematic problem, such as wrong data, capture it as feedback for the team.

When the AI is unavailable or slow, the interface should never lose the user's input or freeze. Show a brief, honest message, offer retry, and provide a non-AI path where possible: manual entry, standard search results or contacting support. Design these states with engineering so they reflect real fallback behaviour; see LLM application reliability.

Actions are where AI errors cost most. Prevent them with previews and confirmation; recover with undo, a clear record of what changed and guided steps for actions that cannot be undone, such as sent messages. Offer a fast route to a person for consequential mistakes, and log incidents so the team can find the cause.

Refusals are errors from the user's perspective when the request was legitimate. Keep refusals brief, explain scope rather than moralizing, suggest an alternative and avoid repeated refusals for similar safe requests. Track refusal rates and review samples to find over-refusal.

Designing for errors keeps users productive and trusting even when AI is imperfect, and it often matters more to adoption than small accuracy gains. It requires designing many additional states and close coordination with engineering on what failures look like. Prioritize the errors that are most frequent and most costly.

Good AI error messages say what happened in plain language, preserve the user's work and offer the next step. 'I couldn't find this in your policy documents. Try rephrasing, or ask HR directly' is better than 'Error'. Avoid blaming the user, avoid technical codes in the main message and avoid apologizing at length. Vary messages by cause: timeouts suggest retrying, missing data suggests uploading or rephrasing, out-of-scope requests suggest alternatives. Guidance on tone is in UX writing.

Every error state is a data point. Log which error states users hit, how often, what they did next and whether they succeeded. Frequent clarifying questions may mean the AI lacks context it could get automatically; frequent regenerations may signal poor default output; frequent escalations may reveal gaps in knowledge. Feed these patterns into prioritization and evaluation sets; see AI feedback UX and LLM observability.

An illustrative scenario, not a client case: an expense app's receipt reader sometimes reads totals wrongly, and users discover this only when finance rejects claims. The redesign shows the receipt image beside extracted fields, highlights the total when the image is blurry, asks the user to confirm the total for amounts above a threshold and lets them correct it inline. Finance rejections for wrong totals drop.

AI will be wrong sometimes; good design makes errors visible, cheap to fix and safe to recover from. Preserve input, show evidence, ask when unsure, support editing and undo, and keep a person within reach.