AI chat interface design: the states, trust patterns and details most products skip
Chat became the default AI interface by accident of history, and most products implement it as a text box and a scrolling list. The interesting design work is everything around the messages: the waiting, the failing, the trusting and the undoing.
Why chat won, and what that costs you
Chat won because it needs no explanation. Everyone alive has sent a message. That familiarity is also the trap: users import expectations from messaging humans that your model cannot meet.
A human correspondent remembers yesterday, knows when they are guessing, and can be asked why. A model does none of these by default. The interface has to supply what the medium implies. That is the actual job of AI chat design: closing the gap between what chat promises and what the model delivers.
You are not coding with AI, you are choosing a control model. The interface is where that choice becomes visible: who can see what the system did, who can correct it, and who is accountable when it is wrong.
The anatomy of a good AI chat surface
- A first-run screen that shows three things the assistant is genuinely good at, as tappable prompts, not a wall of capability copy.
- Messages that distinguish user, assistant and system visually, so the conversation reads as a record of who said what.
- Actions attached to responses: copy, retry, edit the prompt, and rate. The response is an object you work with, not a transcript you scroll past.
- A persistent, honest indicator of what the assistant can see: which documents, which tools, which memory.
- Conversation management that treats old threads as findable work, with real titles, not a list of truncated first messages.
The states everyone forgets
| State | What users need | What most products ship |
|---|---|---|
| Streaming | A sense of progress and the ability to stop | A typing indicator, then text arriving too fast to read, no cancel |
| Retry | The original prompt preserved and editable | A regenerate button that hides what was asked and burns a new answer |
| Refusal | Why, and what would work instead | A generic apology that teaches the user nothing |
| Low confidence | Calibrated language and a way to verify | The same tone for a guess as for a fact |
| Tool use | Visibility into what was called and what came back | A spinner labeled thinking, which hides the interesting part |
| Empty | Orientation and a first move | A blinking cursor and the entire burden on the user |
| Rate limited | When it resets and what still works | An error toast at the moment of highest intent |
Design these first, on paper, before the happy path. In AI products the unhappy path is not an edge case. It is a daily occurrence for every user.
Trust patterns: citations, confidence and undo
- Citations that open the exact passage used, not just a link to a document. Verification must be cheaper than doubt.
- Confidence shown through language and structure: short declarative answers when sure, visible hedging and sources when not.
- Undo and edit as first-class actions. Users forgive wrong answers; they do not forgive being trapped with them.
- A visible boundary of knowledge: this assistant knows your docs up to a date, and says so, rather than improvising.
- Feedback that visibly does something. A rating that changes nothing teaches users that reporting errors is pointless.
Input design beyond a text box
The empty text box is the hardest possible prompt: it offers no affordance and accepts anything. Good AI interfaces narrow the gap between intent and prompt.
- Suggested prompts drawn from the user's actual data, refreshed, so suggestions never go stale.
- Attachments with visible parsing status, so a PDF upload never silently fails into a confident wrong answer.
- Slash-style shortcuts for the five actions that make up most usage.
- Voice input where the context supports it, with a transcript the user can edit before sending.
- A character of the composer that matches the product: terse for developer tools, guided for consumer products.
When chat is the wrong interface
Chat is a poor fit when the task has a known shape. If the user does the same thing every time, give them a form, a button or an automation, and let AI work behind it. Chat is for open-ended, exploratory, conversational work. Reaching for it everywhere usually means the product has not decided what it is for.
- Repetitive structured tasks: build a form with AI defaults, not a conversation.
- Monitoring and alerts: push to the user; do not make them ask.
- Bulk operations: a table with an action beats fifty messages.
- Anything where the cost of a wrong answer is high: constrain the input before you polish the output.