By Mehdi HassanChat became the default AI interface because it is easy to ship. That doesn't make it easy to design well. Most AI chat products look alike at first glance, and the differences that matter sit in the details: what the empty state suggests, how the stream scrolls, what happens when the answer is wrong. This guide labels each part of a chat UI, lists the mistakes we see most, and adds notes for building it in React. It belongs to our wider guide on AI product UX.
What are the key parts of an AI chat interface design?
An AI chat interface has six parts: the composer, the message thread, the response states, sources, per-message actions and conversation management. Each part has a job, and most weak chat products skip at least two of them.
Part | What it includes | Its job |
|---|---|---|
1. Composer and empty state | Input, suggested prompts, attachments, mode picker, send and stop | Help users ask well |
2. Message thread | User and AI messages, markdown, code, tables | Make long answers readable |
3. Response states | Queued, thinking, tool use, streaming, done, failed | Show what the system is doing |
4. Sources | Inline citation markers, source panel | Let users check answers |
5. Message actions | Copy, edit, regenerate, feedback, share | Make recovery and reuse easy |
6. Conversation management | History, rename, search, delete, new chat | Let users return to past work |
The empty state belongs with the composer, but it behaves like its own screen, so design it as one. Treat this table as the anatomy diagram for a review: walk through a chat product part by part and note which are missing or weak.
How should the composer and empty state work?
The composer should tell users what they can ask and what the AI can see, and the empty state should offer a few specific starting points. A blank box with "Ask me anything" puts all the work on the user and invites requests the product can't handle.
- Scoped placeholder: "Ask about your invoices, customers or payouts" beats a generic prompt.
- Three to five suggested prompts: based on the user's role or current page, and clickable.
- Visible context: chips that show which files, records or pages the AI will use.
- Multi-line input: grows with the text, Enter to send and Shift+Enter for a new line, with the shortcut shown.
- Stop replaces send while a response streams, in the same position, so users find it without looking.
Our guide to inline AI patterns beyond the chatbox covers cases where a chat composer isn't the right entry point at all.
How should the message thread display AI responses?
The message thread should make long, structured answers easy to scan: a comfortable line length, clear separation between user and AI turns, and proper rendering of headings, lists, tables and code. AI answers are often long, so the thread is closer to a document reader than to a messaging app.
Two layout choices make the biggest difference. First, keep line length readable, around the width of a book page, even on wide screens. Second, don't put AI answers in speech bubbles. Bubbles suit short human messages, but they squeeze tables and code. Many strong chat products show the user's message in a subtle bubble and the AI's answer as full-width content.
Rendering details that matter in long answers
Code blocks need a language label, a copy button and horizontal scroll rather than wrapping. Tables need horizontal scroll on mobile and a sticky header on long ones. Headings inside an answer should be smaller than the page's own headings, so a long answer doesn't look like a new page. Links should open in a new tab or a side panel, so the conversation isn't lost.
What loading and streaming states does a chat UI need?
A chat UI needs separate states for queued, thinking, using a tool, streaming text, done and failed. One spinner for all of them tells users nothing, and waiting without information is when they lose patience and trust.
Queued
The message is sent but the model hasn't started. Show the user's message immediately so the send feels instant.
Thinking
The model is reasoning before output. A short label like "Thinking" with a subtle animation, optionally expandable to show the steps.
Using a tool
Name the action: "Searching your documents" or "Reading 3 files". It explains the wait and adds transparency.
Streaming
Text appears progressively with a cursor or fade, without layout jumps.
Done
Message actions appear, sources become clickable and focus returns to the composer.
Failed
Keep partial text, say what failed in plain words and offer retry or continue.
Our guide to AI loading states shows how to design each one, including longer multi-step waits.
How should sources and message actions work?
Sources should appear as small numbered markers next to the claims they support, opening the exact passage in a panel or popover. Message actions should sit under each AI message and include copy, regenerate, edit the prompt, and feedback, visible on hover on desktop and always visible on touch screens.
Citations are the main way a chat UI earns trust for factual answers, so they deserve real design time. Our guide to showing sources and citations in AI answers covers marker styles and source panels. Editing the user's previous message and re-running from there is often the fastest recovery path, and our guide to recovery patterns for AI errors explains how to pair it with regenerate and undo.
What are the most common AI chat UI mistakes?
The most common AI chat UI mistakes are a blank empty state, one generic loading spinner, auto-scroll that drags the reader away, a stop button that doesn't really stop, answers squeezed into bubbles and no way to find old conversations. Each one is cheap to fix during design and expensive after launch.
Mistake | What users experience | Fix |
|---|---|---|
"Ask me anything" empty state | Don't know what to ask | Scoped suggested prompts |
One spinner for every wait | No idea if it's stuck | Distinct named states |
Forced auto-scroll | Can't read while it streams | Stick to bottom only until user scrolls up |
Cosmetic stop button | Text stops, cost doesn't | Abort the request on the server |
Answers in narrow bubbles | Tables and code are unreadable | Full-width AI responses |
No history or search | Lose past work | Named, searchable conversations |
Chat for everything | Too much typing for simple tasks | Use inline actions where they fit |
The last row is the strategic one. Our comparison of copilot vs agent vs chat helps decide when chat is the right model, and agentic UX covers what to design when the AI should act, not answer.
How do you build a streaming chat UI in React?
Build a streaming chat UI in React by streaming the response from a server route, appending tokens to the last message in state, rendering only that message on each update, and wiring stop to an abort signal. Most of the difficulty is in scrolling, markdown parsing and failure handling, not in receiving tokens.
- Stream from the server: a Next.js route handler can return a streamed response, and the client reads it chunk by chunk. Chat SDKs wrap this, but know what they do underneath.
- Re-render only the active message: memoize finished messages so a long thread doesn't re-render on every token.
- Abort properly: pass an AbortController signal to the fetch, and cancel the model request on the server when the client disconnects.
- Smart auto-scroll: track whether the user is near the bottom. Follow the stream only if they are, and show a "jump to latest" button if not.
- Safe incremental markdown: unclosed code fences and half-finished tables break naive renderers. Render a plain fallback until the block closes.
- Accessibility: use a polite live region that announces when a response finishes, not every token, and keep focus in the composer.
- Long threads: virtualize very long conversations so the page stays responsive.
As these pieces repeat across features, turn them into shared components. Our guide to design systems for AI products covers which ones to standardize, and web app UI design covers the surrounding product layout.
