Lead · 9 chapters
AI product UX
Streaming, progressive disclosure, citations, confidence signals, edit-not-accept flows, undo, feedback capture, latency perception
AI systems lose user trust at the product surface when uncertainty, reversibility, and waiting are handled as implementation details.
Read these first
What you will know
Design a UI that shows uncertainty honestly
Calibrated labels, visible source boundaries, and partial-result states should prevent users from treating fluent output as verified fact.
Choose edit-not-accept where a wrong answer is costly
Preserving the original, making changes reversible, and requiring an explicit apply step limits damage when generated text affects records, code, or external actions.
Make citations checkable in one action
A source can be technically present yet useless if it opens the wrong passage, is stale, or cannot support the specific claim beside it.
Capture feedback without nagging
Sampling prompts, contextual affordances, and passive signals reduce response bias while avoiding privacy leakage and interruption fatigue.
Measure perceived latency against abandonment and task completion across streaming states
Time to first token, time to useful content, and completion time can diverge, while fake progress or layout shifts may make a fast response feel unreliable.
Chapters
- 1
Fluent output wears the surface features of a checked answer
Model output arrives confident, well-formed and complete, and nothing in the prose separates the sentence a retrieved passage supports from the one the model filled in. The interface has to draw that line instead, through visible source boundaries, honest partial states while evidence is still arriving, and labels the system can defend. This chapter sets the standard that the citation, edit and latency chapters then implement.
- 2
Lead with the answer and keep the reasoning one action away
Progressive disclosure is not a collapsed panel around everything long. It means answering in a sentence or two, then offering reasoning, sources and raw retrieval to the reader who wants to audit rather than skim. Putting the chain of thought first buries the result and teaches users to scroll past it. You will decide what belongs in the opening lines and what has to survive exactly one click.
- 3
A citation is checkable only when it opens the supporting passage
Three citations that open a forty-page PDF at page one are decoration, and users learn within a week that following them costs more than re-answering the question themselves. When trust is low the fix is rarely more citations; it is anchoring each one to the passage supporting the specific claim beside it, and confirming that passage is not stale. Measure follow-through and post-check corrections, not citation count.
- 4
Mark the spans a source supports, and decide what the unsupported sentence gets
A citation that resolves to the right passage still does not say which words of the answer that passage supports. Render support at span level, then make the decision the reader most needs and the one nobody writes down: for the sentence with no citation at all, do you mark it, suppress it, or refuse the whole answer. Streaming forces the second half of this, because prose is on screen before attribution has resolved, so the interface has already committed to a fluent sentence before the system knows whether it will stand behind it. Design that partial state deliberately, with unresolved spans that visibly settle, rather than letting an answer look verified while its evidence is still arriving.
- 5
Show the change as a diff and make the user press apply
Where a wrong answer damages a record, a file of code or an outbound action, generated text should arrive as a proposal beside the original rather than in place of it. A diff with an explicit apply step keeps the original recoverable, makes the scope of the edit legible before it commits, and turns a silent overwrite into a decision. Accept-by-default is what turns a plausible error into a permanent one.
- 6
An undo the user cannot reach in time is not an undo
The diff handles what has not committed yet; a message already sent and a ticket already created need the other half, and reversibility as a system property is not yet an affordance anyone can use. Decide how long the undo window stays open, where it lives once the toast has faded, and how a user who has moved on gets back to it, because an undo that exists for five seconds in a corner of the screen protects nobody. Where the action genuinely cannot be recalled, say so at the moment of the action rather than after it, and move the friction in front of the commit.
- 7
Time to first useful content, not time to first token
A 300ms time to first token that streams "Great question, let me look into that" measures the preamble, not the wait; what predicts abandonment is when the user first sees something usable. With 22% abandonment on a six-second answer, buying a faster model is a guess, while naming the real stage, searching, reading three sources, drafting, often does more. Fake progress and layout shift make a fast answer feel unreliable.
- 8
Sampled prompts and passive signals beat a rating on every answer
Asking every user to rate every answer yields a response set skewed toward the annoyed and the delighted, and teaches everyone else to ignore the widget. Sample the explicit prompt instead, and read the signals users produce anyway: edits to generated text, copies, retries, abandonment, and the version they finally accepted. This chapter covers what each signal can support and where logging what a user typed crosses a privacy line.
- 9
A fluent wrong answer gives no warning, so the friction must exist already
The moment worth designing is not the error state; it is a well-formed, well-cited, wrong answer with a user about to act on it. Nothing fires at that instant, so the protection has to have been paid for earlier: the diff, the apply step, the anchored citation, the reversible action, the coarse uncertainty label. Each costs a click, some conversion and some perceived speed, and this chapter prices that trade honestly.
External resources
- Design Principles for Generative AI Applications (CHI 2024)dl.acm.org
Peer-reviewed principles for imperfection, control, exploration and mental models
- AI SDK: Multi-Step & Generative UIvercel.com
Working code for streaming, progressive disclosure of tool steps and partial output
- Patterns for Building LLM-based Systems & Productseugeneyan.com
UX patterns for reliable LLM products, including uncertainty handling and feedback loops.
- UX for Language User Interfaces (LLM Bootcamp)The Full Stack
The canonical talk on designing interfaces around a probabilistic text engine
- The UX of AI: Research-Backed Best Practices for Designing AI InterfacesGreat Question
Evidence on latency perception, trust signals and how users react to AI errors