Chatbot UI Design: Chat Interface Patterns That Work

A chat interface is not just a message list attached to a model. It is a workspace where people provide context, wait through uncertain operations and decide whether an answer is safe to use. The interface must explain those boundaries without requiring users to understand the underlying system.

Start with the job people need to finish. A support assistant, document researcher and code editor may all accept messages, but they need different evidence, controls and recovery paths. Familiar chat conventions help only when they support that job.

Choose conversation only where it helps

Use conversation when requests vary and clarification is genuinely useful. Keep predictable actions such as choosing a billing period or setting a date in ordinary controls. Mixed interaction often works better than a blank composer: a structured selection establishes scope, then conversation handles the ambiguous part of the request.

Define the assistant's scope boundary near the point of entry. Say what it can access and what it cannot do. “Ask questions about the documents selected below” is more helpful than “Ask me anything.” If the assistant cannot change account settings, do not offer suggestions that imply it can.

Explore implementation options through the AI UI design tools directory, but evaluate the generated interface against your own task model. A fashionable floating panel may be a poor fit for comparing long source passages. For document-heavy work, a side-by-side answer and evidence layout may reduce navigation considerably.

Before designing screens, write down the user's success condition. “Found the applicable policy and checked its effective date” is more meaningful than “received an answer.” That distinction changes what the interface must display and what your usability study should observe.

Make the composer explain the contract

A useful composer communicates input type, selected context and the next action. Show attached files as removable items with names and processing status. Distinguish uploading from indexing: a transferred file is not necessarily ready for retrieval. Context visibility prevents users from assuming that the assistant has read something it cannot yet access.

Provide a visible send button and an explicit keyboard convention. In a multiline field, people need a predictable way to insert a new line. Do not hide basic editing behind an unfamiliar shortcut. Preserve a draft when an attachment fails, and give the user a way to remove the failed item without clearing everything.

Use starter prompts that teach realistic tasks rather than advertise vague intelligence. A useful example describes both the requested output and its evidence boundary:

Compare the cancellation terms in the two selected contracts.
Quote the relevant clauses and identify their section headings.
Flag missing information instead of assuming the terms match.

Explain limits before submission when possible. If scanned documents are unsupported, say so at attachment time rather than returning a confident empty summary later. Link to detailed guidance only after the immediate problem and remedy are clear. The composer should reduce uncertainty, not become a wall of disclaimers.

Treat response generation as a stateful process

Design distinct response states for queued, retrieving, generating, complete, stopped and failed. These labels should reflect events the application can actually observe. Do not display “checking sources” because it sounds reassuring if no source verification step exists. An honest general status is better than fabricated operational detail.

Streaming text can reassure people that work is progressing, but it also creates reading and focus problems. Keep a stable stop control available. Do not move keyboard focus into each new paragraph or announce every token. The WAI guidance on status messages helps distinguish important updates from changes that should not interrupt the user.

Respect scroll intent. Follow incoming content while the reader remains near the end, but stop following when they scroll back. Offer a clear return-to-latest control instead of pulling the viewport down repeatedly. Keep the composer accessible without covering the last lines of the response on small screens.

When generation stops early, label the answer incomplete and retain what is already useful. A retry should state whether it regenerates the whole response or continues from a checkpoint. The broader AI feature state guide can help align these behaviours with loading and recovery elsewhere in the product.

Make evidence and actions inspectable

Put source references next to the claims they support. A general list of documents below a long answer does not show which source supports which sentence. Provide enough context to inspect a reference: document title, relevant passage and location where available. Traceable evidence is stronger than a confidence badge with no defined meaning.

Separate generated content from actions that change external systems. Drafting an email and sending it require different levels of consent. Before an irreversible action, show the recipient, content and consequences in a review step. Do not treat the user's approval of wording as automatic permission to execute every suggested operation.

When answers contain code or formatted text, provide scoped copy controls and label what will be copied. Preserve meaningful line breaks and show whether citations are included. Let users edit drafts without overwriting the original answer, so they can compare changes or return to earlier wording.

The Microsoft human-AI interaction guidelines offer useful principles for communicating capability and supporting correction. Apply them to observable interactions rather than decorating the interface with general assurances that the assistant is reliable.

Test reading, accessibility and recovery together

Long answers expose layout problems that short demos hide. Use the CSS clamp calculator to derive bounded fluid type values for response headings, then test them with browser zoom and narrow viewports. Keep body text readable without allowing heading growth to squeeze source controls off-screen. Readable typography includes line length and spacing, not just font size.

Use native buttons and labelled fields where possible. Check focus order through the transcript, citations and composer. Provide a way to navigate long conversations without tabbing through every repeated action. The WAI Authoring Practices Guide is a reference for interaction patterns, not a reason to add complex roles to otherwise simple markup.

Test failure recovery with expired sessions, network interruptions, rejected files and unavailable sources. Preserve the user's prompt after failure and make duplicate submissions avoidable. If refreshing loses the conversation, disclose that limitation before users invest substantial work, not after the session disappears.

Observe people completing a real task, including checking a wrong answer. Measure whether they notice unsupported claims and can repair the context. Raw message counts and thumbs-up totals cannot show whether the interface helped someone make a sound decision. The goal is a workspace that remains understandable when the model is slow, mistaken or unable to help.

Key takeaways

• Use conversation for ambiguity and ordinary controls for predictable choices.
• Make selected context, attachment readiness and assistant limitations visible.
• Design streaming, stopping, scrolling and failure as separate interaction states.
• Keep evidence close to claims and require review before consequential actions.
• Test long responses, keyboard access and recovery with realistic tasks.