Designing Great AI UX

Bottom Line First

Most AI products fail on UX before they fail on capability. The model is usually good enough. What kills them is the wrapper: a blank loading state that hangs for eight seconds, a confident answer with no way to verify it, a chat interface bolted onto a workflow that needed a form, no way to edit or undo. Users don’t leave because the AI was wrong — they leave because the product made them feel helpless when it was wrong.

Great AI UX is not about making AI look smarter. It is about designing for the specific failure modes of probabilistic systems: latency, unpredictability, hallucinations, and variable quality. Every pattern in this article is a direct response to one of those failure modes. Get them right, and users will forgive a lot. Get them wrong, and no model upgrade will save you.

Why AI UX Fails

Before the patterns, it helps to name the root causes clearly. AI products fail on UX for four reasons that are unlike anything in traditional software.

1. Latency Is an Order of Magnitude Worse

A typical REST API responds in 50–200ms. A typical LLM call takes 200–700ms for the first token on standard models (10+ seconds when using reasoning), and the full response can take 30–60 seconds for long outputs. This is not a performance problem you can optimize away. It is a design constraint you must design around.

The failure mode: showing a spinner and freezing the UI while waiting for a complete response. Users interpret silence as failure. After 3 seconds with no feedback, most assume something is broken.

2. Outputs Are Unpredictable in Shape and Length

A deterministic function returns a predictable shape. An LLM returns whatever length and structure it decides is appropriate. Sometimes it is three words. Sometimes it is five paragraphs. Sometimes it starts mid-sentence because the prompt was ambiguous.

The failure mode: designing a fixed layout for AI output, then watching it break when the model returns 10x more or less content than expected.

3. Hallucinations Are a UX Problem, Not Just a Model Problem

Every LLM hallucinates. The question is whether your UX makes hallucinations costly or recoverable. A product that presents AI output as authoritative fact, with no source, no confidence signal, and no edit path, turns every hallucination into a broken trust event. A product that says “here’s what I found — check these sources” turns the same hallucination into a recoverable mistake.

The failure mode: treating hallucinations as purely a model quality issue and ignoring the UX scaffolding that lets users detect and recover from them.

4. Users Do Not Know the Capability Boundary

With deterministic software, users learn quickly what the system can and cannot do. With LLMs, the capability boundary is fuzzy and context-dependent. The model can draft a great email and then completely fabricate a statistic in the same response.

The failure mode: no affordance for users to understand what the AI is good at, what to double-check, and what to avoid asking it entirely.

The Principles That Work

Stream Everything

If your LLM call takes more than two seconds, you must stream the response. This is not optional. Streaming moves the UX from “waiting for a result” to “watching something happen,” which changes the psychological experience entirely.

Cursor streams completions character by character. Perplexity streams the answer while simultaneously showing sources building in real time. Claude streams responses progressively. None of these feel fast — the underlying models are not fast — but they feel responsive because the user sees work happening immediately.

The implementation is straightforward with most provider SDKs. The harder part is designing the UI to handle partial content gracefully: don’t render markdown mid-token, don’t jump layout as content streams in, and show a clear “generating” indicator that disappears when complete.

Progressive Disclosure for Long Outputs

Long AI outputs are cognitively overwhelming. The instinct is to dump the full response and let the user read it. The better pattern is progressive disclosure: lead with a short summary or the most actionable point, then offer the full detail on demand.

Notion AI does this well for its “improve writing” feature — it shows a diff view with the key changes highlighted, not a wall of revised text. GitHub Copilot shows the first completion inline and lets you cycle through alternatives. The user gets the answer without having to process everything.

Apply this at two levels:

• Response level: summary first, detail on expand
• Section level: headers and bullets that let users scan before reading

Make Uncertainty Visible

Users can handle uncertainty. What they cannot handle is hidden uncertainty — confident-sounding output that turns out to be wrong with no signal it might be wrong.

The patterns that work:

• Inline citations: Perplexity anchors every claim to a source with numbered footnotes. Users know exactly what to verify.
• Confidence language in the output: Prompt the model to hedge appropriately. “Based on the documents you provided” or “I’m not certain, but” signals calibration.
• Distinguish what the model knows from what it retrieved: RAG-based systems should make the retrieval step visible — “I found 3 relevant documents” — so users know whether the answer is grounded.
• Explicit limitations: Superhuman AI’s email summarization explicitly notes when it cannot access attachments. The constraint is surfaced rather than silently ignored.

Always Provide an Edit Path

Every AI output should be editable. This sounds obvious but is frequently missed. Products ship AI features where the output is read-only, or where editing means starting over from scratch.

The right model: AI output is a first draft, not a final answer. The UX should reflect that. Inline editing, regeneration with modified instructions, and partial acceptance (accept this paragraph but not that one) are table stakes for AI writing features.

Cursor makes this concrete: every Copilot suggestion can be accepted, rejected, or modified inline. There is no mode where you are stuck with the suggestion. The user is always in control of the final artifact.

Design for Graceful Degradation

What happens when the model returns garbage? When the API times out? When the structured output fails to parse? Most AI products have no answer to these questions — they just break.

Graceful degradation means:

• Fallback content: if the AI can’t generate a summary, show the raw text
• Partial results: if only 3 of 5 sections generated successfully, show those 3
• Clear error states: “We couldn’t generate this” with a retry option beats an empty state or a cryptic error message
• Timeout handling: set a hard timeout and handle it explicitly rather than hanging

Reduce Perceived Latency with Skeleton Loaders

For LLM outputs that have predictable structure — a list of action items, a document outline, a structured summary — use skeleton loaders that match the expected output shape. This does two things: it tells the user what kind of answer is coming, and it makes the loading state feel intentional rather than broken.

The pattern:

1. User submits request
2. Skeleton loader appears immediately, shaped like the expected output (list, card, form fields)
3. Content streams in and fills the skeleton
4. Final state snaps into place

This is more work to implement than a generic spinner, but it meaningfully reduces perceived latency because the user’s attention is on the skeleton being filled rather than the clock.

Conversational Forms vs. Chat: Choose the Right Interaction Model

One of the most common mistakes in AI product design is defaulting to a chat interface when the task is better served by a guided form or a workflow step.

Chat works well for:

• Open-ended exploration
• Tasks where the user doesn’t know what they want upfront
• Multi-turn reasoning where the user’s question depends on previous answers

Forms and structured workflows work better for:

• Tasks with known input requirements (generate a job description: title, level, responsibilities)
• High-stakes outputs where precision matters more than flexibility
• Users who are not comfortable with prompt engineering

The hybrid pattern works best in practice: a form that collects structured inputs, optionally augmented by a free-text field for additional context, feeding into an AI generation step. Notion AI’s “generate from template” flow does this — you pick a template, fill in a few fields, and the AI generates a full document. The user never has to write a prompt.

The mistake is treating chat as the universal interface. It is not. Chat is good for exploration. Structured flows are good for production.

Patterns Table

What the Best AI Products Do Differently

They Treat the AI as a Collaborator, Not an Oracle

Cursor does not try to be right every time. It tries to be useful enough, fast enough, that accepting or rejecting a suggestion takes less time than writing from scratch. The bar is not accuracy — it is whether the suggestion moves the user forward. The UX is designed for this: accept with Tab, reject with Escape, cycle alternatives with Option+]. The interaction model acknowledges that many suggestions will be wrong.

Compare this to products that present AI output as the answer. When those products are wrong, the UX has no recovery path. When Cursor is wrong, the user is already hovering over the reject key.

They Surface the Model’s Work, Not Just Its Output

Perplexity shows you the search queries it ran, the sources it retrieved, and the reasoning path that led to the answer. This serves two purposes: it lets you verify the output, and it teaches you how to get better results. Users who understand how the system works trust it more and use it more effectively.

GitHub Copilot’s recent features show what context it pulled — open tabs, repository contents, selected code — so you know why it generated what it generated.

They Optimize for Recovery, Not Prevention

Good AI UX does not try to prevent bad outputs (impossible). It makes bad outputs recoverable. Undo, edit, regenerate, reject — these are not afterthoughts, they are the core interaction model. A product where every AI action is reversible in one step is a product users will push hard, because they know they can always undo.

They Set Scope Expectations Early

Superhuman AI tells you it can help with writing and summarization but not scheduling. Claude’s interface is explicit about knowledge cutoffs and what it cannot access. These are not disclaimers bolted on for legal reasons — they are UX decisions that reduce the frustration of hitting an unexpected capability wall.

Common Mistakes

Showing a spinner and nothing else for 10+ seconds. Start streaming or show a skeleton immediately. Silence is interpreted as failure.

Making AI output read-only. Everything should be editable. If you can’t implement full inline editing, at minimum provide a regenerate button and a copy-to-edit affordance.

No source or grounding for factual claims. If the model makes factual claims and you can ground them (via RAG, search, or retrieval), show the source. If you cannot, hedge the language.

Defaulting to chat for structured tasks. Build forms for tasks with known inputs. Chat is for exploration, not production workflows.

Ignoring error states. API timeouts, malformed outputs, empty responses — all of these need explicit, recoverable UX. An empty state is not an error state.

Building for the best-case output. Design for p50, not p95. Your layout, your copy, your error handling — all of it should assume the model will sometimes be wrong, slow, or verbose.

Not streaming long outputs. If you know the response will take more than 2 seconds, streaming is not a nice-to-have. It is table stakes.

The One Metric That Matters

If you want a single number to tell you whether your AI UX is working, track re-engagement rate after a bad AI output. Not overall retention. Not task completion. Specifically: when the AI produces an output the user signals is wrong (edits it heavily, rejects it, regenerates) — do they try again?

If they do, your UX is working. They trust the system enough to give it another chance. That trust is built entirely by the patterns in this article: streaming, editability, uncertainty signals, graceful degradation. The model did not earn that trust. The UX did.

Build for recovery, not perfection. That is the whole job.