UX patterns for AI

The big idea

Ordinary software is fast and predictable: you click Save, it saves. An AI feature is neither. It can take ten seconds to answer, it can be confidently wrong, and the same question can get a different answer tomorrow. An interface designed as if the AI were a normal function makes those weaknesses the user's problem: they stare at a spinner, trust a made-up fact, or discover too late that the assistant sent the wrong email.

Good AI UX is designed around those weaknesses. Think of a good junior colleague. They tell you they are working on it, show you where they found things, say "I am not sure about this part", ask before doing anything you cannot take back, and when they cannot do something, they say so and suggest what to do instead. You trust them more, not less, because they are honest about their limits.

Six patterns turn that behavior into an interface: streaming, citations, confidence cues, undo, approvals and graceful failure. Underneath all of them is one goal: set the user's expectations about what the AI can and cannot do, and keep the user in control.

How it works

1. Set expectations, show progress Say what the assistant can do. The moment the user asks, show that work has started.
2. Stream the answer Show text as it is generated, so reading starts in under a second instead of after the whole answer.
3. Cite sources Link claims to the passages they came from, so the user can check them in one click.
4. Show uncertainty When evidence is weak, say so, ask a clarifying question, or decline to answer.
5. Approve, then allow undo Show exactly what will happen and wait for a yes. After acting, keep an undo window open.
6. Fail gracefully On errors and timeouts, explain plainly, keep the user's input, and offer a retry or another way.

Set expectations first

Before anyone types, the interface should say what the assistant is for and how reliable it is: "Answers questions about your orders and our policies. It can make mistakes; check important details." Example prompts that show the intended use help more than a blank box. Users who expect magic are disappointed by good systems; users who know the scope forgive limits.

Streaming and progress

A model generates its answer token by token. StreamingSending a model's output to the user piece by piece as it is generated, instead of waiting for the whole answer. forwards each piece as it arrives, usually over server-sent events, so the user starts reading after the time to first tokenThe time from sending a request until the first token of the answer arrives. instead of after the whole answer. Total time does not change; perceived waiting drops sharply. For multi-step agents, stream the steps too ("Searching orders... Reading refund policy..."), so a 30-second task does not look frozen. The serving side is covered in Streaming responses to users .

Two details matter. Render streamed markdown carefully, because half a table or an unfinished code block looks broken. And give the user a Stop button: if the answer is going the wrong way, they should not have to wait for it.

Citations

When an answer draws on retrieved documents ( Why RAG? ), show which passage supports which claim: a numbered marker that opens the source, with the matching text highlighted. Citations turn "trust me" into "check me". They also expose bad retrieval: a citation that does not support its sentence is a visible bug instead of a hidden one. Cite only what was really retrieved; a link the model invents is worse than none.

Confidence cues and abstaining

Models sound equally sure when right and wrong, so the interface has to carry the uncertainty ( Hallucinations ). Cues that work are based on evidence the system can check: "No source found for this; answer based on general knowledge", "Your question matches two products. Which one?", or plain refusal when nothing relevant was retrieved. Raw percentages ("87 percent confident") usually do not help unless they are calibrated, meaning that 87 percent of answers shown that way are actually right.

Undo and editability

AI output is a draft. Let users edit it before it is used, regenerate it, and undo it after. Undo is cheap insurance: if the assistant reorganized a document or applied a filter, one click should restore the previous state. Design actions to be reversible where you can, such as moving to trash instead of deleting, saving a draft instead of sending, or scheduling an email with a short delay.

Human-in-the-loop approvals

For actions that cost money, reach other people or cannot be undone, the assistant proposes and the human decides. An approval screen shows exactly what will happen, with the real values: "Refund 49 dollars to card ending 4417 for order B42. Approve?" Vague prompts ("Allow the assistant to proceed?") train users to click yes without reading. Scale the friction to the risk: no prompt for reading data, one click for low-risk changes, explicit review for payments and messages to customers ( Coding agents and computer-use agents ).

Graceful failure

Model calls time out, providers have outages, and output sometimes fails validation. Failing gracefully means the user never loses work and always has a next step: keep their message so they can retry, explain the problem in plain words, fall back to a simpler path (a search results page, a smaller model, a human agent), and never show a raw stack trace or an empty bubble. This is graceful degradation from classic systems ( Load shedding and graceful degradation ) applied to AI.

Try it

1. Keep the defaults and press Play. How long does the user stare at a spinner in each version? The total time is identical.
2. Set the answer length to 1000 tokens and the speed to 20 tokens per second. Without streaming, how long is the wait? With it?
3. Raise the time to first token to 5 seconds. Streaming no longer saves the start of the wait. What would you show during those 5 seconds?

Now sort some real interface decisions:

Trade-offs

Common mistakes

• A spinner for 10 seconds with no streaming and no progress, then a wall of text.
• Showing citations the model generated rather than passages that were actually retrieved.
• Approval dialogs that hide the details ("Proceed?"), so users approve without knowing what happens.
• Displaying uncalibrated confidence percentages that users take as facts.
• Error states that lose the user's input or show nothing, so the user has to start over.

In the wild

Microsoft Research

Guidelines for human-AI interaction design (opens in a new tab)

Researchers collected more than 150 AI-related design recommendations, condensed them, and validated the result into 18 guidelines published at CHI 2019. The guidelines are grouped by when they apply: initially (make clear what the system can do and how well), during interaction, when the system is wrong (support efficient correction, scope services when in doubt, explain why it acted) and over time (encourage granular feedback, notify users about changes). Most patterns in this lesson map to one of them; the authors stress they are not a simple checklist.

Check yourself

Recap