How to Design AI Chat Interfaces: UX Patterns for LLM Products
Advanced4 minInnovialabs editorial team
In short
A good AI chat streams answers as they generate, helps users start a prompt, shows sources and the limits of its confidence, lets people edit and regenerate, handles errors and refusals honestly — and is used only where dialogue beats a form.
What makes AI chat interfaces different
In a regular interface the result of an action is predictable. In an LLM product the answer is new every time and may be long, inaccurate or a refusal. So the design has three jobs: make waiting tolerable, help people phrase their request, and give them control over the result and a basis for trusting it.
Streaming responses
Streaming means text appears as it is generated rather than all at once at the end. It is the main way to reduce perceived waiting.
What to plan:
- State before the first token: a short "thinking" indicator, or a stage status ("Searching documents") if there are intermediate steps.
- A "Stop" button during generation — users often see early that the answer is going the wrong way.
- Auto-scroll that turns off when the user scrolls up, plus a "jump to bottom" button.
- Stable markdown rendering: tables and code blocks should not jump while they are being drawn.
- Copy for the whole answer and for individual code blocks.
Prompt suggestions
An empty input field is the biggest barrier. What helps:
- Starter suggestions on the empty screen tied to real tasks in the product, not generic "Tell me a joke".
- Follow-up suggestions after an answer: clarify, shorten, turn into a table.
- Templates and parameters for recurring tasks — sometimes a tone or length selector beats asking people to type it.
- A placeholder with an example request, not "Type a message".
Sources and uncertainty
A model can sound confident and still be wrong. The interface should help people verify:
- Source links next to claims or listed under the answer, opening the exact passage of the document.
- Explicit boundaries: if the answer relies only on uploaded documents, say so; if nothing was found, "not found in the knowledge base" beats an invented answer.
- Visual separation of retrieved facts and generated conclusions where it matters.
- A persistent but unobtrusive note that answers should be checked — especially in medicine, finance and law.
Do not show a "confidence percentage" unless the system can calculate it reliably: false precision hurts trust more than its absence.
Editing and regenerating
Users should be able to correct the course of a conversation easily:
- Edit their own message and get a new answer from that point.
- Regenerate an answer; with several versions, offer a switcher between them.
- Edit the result inline or in a separate editor when the answer is a document, code or an email.
- Branches are shown clearly: after an edit it is obvious which answer belongs to which version of the prompt.
Error and refusal states
Different problems need different states:
| Situation | What to show |
|---|---|
| Network or server | A clear message and "Retry" without losing typed text |
| Rate or length limit | What exactly was exceeded and what to do: wait, shorten, start a new chat |
| Interrupted generation | Keep the part already received and offer to continue |
| Model refusal | A neutral explanation that the request is out of scope and a hint about what it can help with |
| No data | An honest "I don't know" and an offer to clarify or upload a source |
A refusal should never sound like it blames the user. And do not hide errors inside the answer text — they must be visibly distinct from a normal message.
Feedback controls
- Answer rating (thumbs up / down) next to each message.
- A reason after a negative rating: wrong, off topic, too long — a short list plus an optional comment.
- Clarity for the user about how feedback is used and what reaches the team.
When chat is the wrong interface
Chat works for open questions, exploration and drafts. It loses when:
- the task is structured input: an application, filters, settings. A form is faster and more reliable;
- people need to compare and scan a lot of data — a table or dashboard beats a long message feed;
- the action is repeated — a button or template is faster than typing a prompt every time;
- the result is an artifact to edit: generating directly inside the document or code editor works better.
Often the best solution is AI inside a familiar interface: a "Generate description" button next to a field, smart suggestions in a form, rather than a separate chat window.