Conversational UI design: the six parts every chat interface needs

TL;DR: Conversational UI design is the visible part of a chat feature: the input bar, message history, status cues and the spot where sources show. Six parts, one rule. Answer first, and keep the assistant to one job. Below: the six parts, five rules for every design review, what sits under the surface, how to test it, and what Australian privacy guidance asks of it.

Conversational UI design is the visible part of a chat feature. The input bar. The message history. The typing dots. The spot where sources show up. It's the surface people touch when they talk to software in plain words.

One rule sits over all of it. Give the answer first, and keep the assistant to one job. Every checklist in this post serves that rule.

Conversational UI vs conversation design

People mix these two up. They're different layers.

Conversational UI is the surface. The chat window, the buttons, the message bubbles, the status cues.

Conversation design is the logic under it. The persona, the tone, the decision tree that decides what the system says and when.

You can have great conversation design wrapped in a clumsy UI. The reverse happens just as often. A slick chat window with nothing sensible behind it.

When chat earns its place

Chat wins when the task is narrow. One fact, or a short set of steps. The other option is digging through menus or docs.

Chat loses when the task needs comparing, browsing or scanning. A table or a form still does those jobs better.

Three ways teams get this wrong:

• They build a chatbot for a job a search bar or FAQ page already does faster.
• They hide the chat entry point, so users never find it.
• They let the assistant answer questions outside its job. Trust dies the first time it gets one wrong.

Not sure if you need chat at all? Our post on adding a chatbot to your website walks through the widget-or-custom call. And if the job needs the system to act, not just answer, read chatbot vs AI agent first.

The six parts every chat interface needs

Every production chat interface needs the same six building blocks. Doesn't matter what industry, or which model sits behind it.

1. A header and identity marker. A label that stays on screen and tells the user they're talking to an AI, not a person.
2. Message history. A record of the conversation you can scroll and search. It has to survive a page refresh.
3. An input bar. The text entry point. Ideally with voice input and quick-reply chips.
4. Status cues. Typing dots, a "searching" state, loading cues. Anything that stops the user wondering if the system has stalled.
5. Suggested prompts. Example questions shown before the first message. They fix the blank-box problem every new user hits.
6. A disclosure surface. A visible way to see sources, citations or the reasoning behind an answer.

The parts are the easy bit. The interaction pattern matters more than the visual polish.

Answers lead with the direct response. Then they offer more detail for anyone who wants it. When the system isn't sure what the user means, it asks a short clarifying question instead of guessing. When it fails, it gives a way out: a rephrase suggestion, or a handoff to a person. Never a dead end.

Accessibility gets the same care as any other UI. Keyboard navigation through message history. Screen reader labels on status cues. Enough colour contrast that a status change isn't the only signal of what happened.

Tip: test your suggested prompts with people who've never seen the product. If they can't guess what to type after reading three examples, the prompts are doing the wrong job.

Five rules for every design review

Nielsen Norman Group has studied how people use site chatbots. Their findings give you a short checklist that holds up across industries.

• Answer first, detail on demand. People treat chat like a search bar. They want the core fact now, then a way to dig deeper. NN/g's research on site chatbots calls this the truncated pyramid. Give only the essential answer first. Then offer follow-up prompts so the user can pull more detail on demand.
• Competence over personality. For work tools, sounding capable builds more trust than sounding friendly. NN/g's research on trust in AI found people trust AI more when it seems smart than when it seems to have feelings. Fake emotion can cut trust in factual, task-focused work.
• Write for scanning. Short paragraphs. Bullets. Numbered steps. Never a wall of text.
• Name the AI and show its sources. Never let a user mistake the assistant for a human. Never show a citation without a way to check it.
• Set scope limits and build a fallback. Decide up front what the assistant won't try. Give it a clean way to say so and hand off to a person.

Run these five as a checklist in every design review. Do it before the visual polish gets any attention.

What sits under the surface

The interface is only as trustworthy as what happens beneath it.

Retrieval-augmented generation, or RAG, lets a system ground its answers in documents you chose. It's not relying on what the model memorised in training. That's what makes checking an answer possible at all. Our guide to building a RAG pipeline covers the plumbing. AI-Led shows the whole thing end to end in how to build a RAG application.

One problem though. Citations in chat interfaces are often wrong. NN/g's research on explainable AI in chat found citations are often hallucinated and point to URLs that don't exist. Their advice: favour interactive checking. Deep links and source previews a user can click, not static text citations that quietly make things up. They show Copilot's clickable source chips, with a preview on hover, as one example.

What Australian privacy guidance asks

The Office of the Australian Information Commissioner has published guidance on privacy and commercially available AI products. The short version:

• Do due diligence before you adopt a commercial AI product. Check it's been tested for the job you want it to do.
• Work out how human oversight fits into the process.
• Work out who gets access to the personal information going in and coming out.
• Update your privacy policy and notices to say how you use AI. Any public-facing chatbot must be clearly identified as one.

None of this is a box-ticking exercise. It shapes what your UI has to disclose, and when a person needs to step in.

In practice, that means four things:

• Log every AI-generated answer and the sources it used, so a dispute can be traced.
• Route high-stakes or unclear queries to a human reviewer before the answer reaches the user. Our post on human in the loop covers how to do that without burning out the reviewers.
• Limit access to conversation logs to the people who need them.
• Update privacy notices whenever a new AI feature touches user data.

For the checks that sit between the model and the user, see our post on LLM guardrails. AI Orchestrators covers the same ground for agents in AI agent guardrails.

Know who's on the other end

A chat assistant for a founder debugging an API needs a different tone and depth than one for a shopper asking where their order is.

Persona work for chat starts with the usual questions. Who is the user? What do they want? What do they already know? What happens if the answer is wrong?

Here's the difference. With chat, the persona shapes the assistant's words and pacing directly. There's no visual layout to cover for a mismatch. A support assistant for shoppers answers in plain words and short sentences. A technical assistant inside a developer tool can use precise terms and assume the user knows the domain.

Most user bases span a range of technical skill. One chat flow rarely suits everyone. Some products adjust response depth based on how the user phrases the question. Others offer a toggle between a quick answer and a detailed one.

Either way, do the persona work before the first prompt gets written. Retrofitting tone and scope after launch means rewriting the logic, not just the copy.

Vague personas are the most common reason a chat assistant feels generic. Specific ones, tied to real tasks and real consequences, produce assistants that feel built for the job.

Other languages

Chat carries more localisation risk than static UI. The content is generated on the fly, not translated once and reviewed. A phrase that reads fine in English can come out stiff, unclear or plain rude in another language. And no translator checks each response before it lands.

Handle dates, currency, units and honorifics at the template or prompt level. Don't leave them for the model to guess. Formality varies a lot between languages too. A tone that feels direct in one market feels rude in another. Give the system explicit rules for this, not one global persona.

Right-to-left languages bring their own interface work. Message bubbles, timestamps and input bars all need mirroring. Mixed-language chats, where a user types in one language while the interface labels show another, need a clear fallback.

The safe approach is to treat each supported language as its own conversation design job. Its own tone rules. Its own testing pass. Teams that skip this find the gaps after launch, when users in a second market report responses that feel off without being able to say why.

Remember the right amount

A chat assistant that forgets what you said two messages ago feels broken. One that remembers too much raises its own problems, like holding sensitive information longer than it should. Context management is the balance between the two.

In practice, split context into two kinds. Session context is the current task and the last few exchanges. Persistent context is user preferences and past history. Be explicit about which applies to what. A follow-up like "what about next month?" needs the system to carry the subject forward without the user repeating it.

Multi-turn design also needs a clear point where context resets. If the user changes subject, the system should notice, not force the old context onto the new question. This is where a lot of chatbots visibly fail. They keep answering as if the conversation never turned.

Context windows are a technical limit too, not just a UX one. Long chats outgrow what a model can hold at once. So the interface needs a plan for summarising or dropping older turns without losing what the user needs kept. Make that trade-off visible rather than silent. Trust holds up better when the system's memory limits show in the open.

We cover the limits in what is an AI context window and the design side in agent memory design. AI Orchestrators has a plain-words take on what an agent should keep and what it should forget.

When it gets it wrong

Every chat interface will get something wrong. It'll misread a question, pull the wrong document, or have no answer. The design question isn't whether errors happen. It's whether the interface helps the user recover fast.

The weakest pattern is a generic "I didn't understand that" with no next step.

A stronger pattern names the reason ("I couldn't find pricing for that plan") and pairs it with a way forward. A rephrase suggestion. A related topic. A direct handoff to a person. Be specific. A vague error leaves the user guessing whether to try again or give up.

Recovery needs an escalation path. When the assistant has failed twice on the same question, repeating the same answer a third time kills trust fast. The interface should spot the repeat and offer a different route: a human, a support article, or a plain admission that it can't help with this one.

Silent failures are the worst case. An answer that sounds confident but is wrong, with no signal to the user that something might be off. This is where the sourcing patterns above double as error handling. A visible citation lets a careful user catch a wrong answer before they act on it, even when the system doesn't know it made a mistake.

How to test it

Testing a chat interface means moderated sessions. Real users try to finish a task. Then you read the transcripts for where they got stuck, rephrased, or gave up.

Track these six:

1. Task success rate. Did the user get a correct, usable answer without escalating?
2. Time to answer. From first message to resolution.
3. Escalation rate. How often the assistant hands off to a person.
4. Hallucination rate. How often an answer holds an unsupported claim. Spot-check against the source documents.
5. Source-check clicks. How often users open the citations you gave them. It's a strong proxy for trust.
6. Satisfaction per answer. Not just per session.

Roll out changes in stages. A/B test prompt wording, or where the disclosure sits, before a full release. A design that scores well in the lab but spikes escalation in production usually has a scope problem, not a wording one.

For the wider set of AI UX patterns, our post on AI UX for SaaS products covers trust ladders, explanations and user controls.

Tools, and when to buy instead of build

Most teams stitch a few categories of tooling together rather than one all-in-one platform.

• An LLM API for the generation layer.
• A retrieval framework to ground answers in your documents.
• A front-end component library for the chat window, bubbles and input controls.
• Analytics and logging to track the metrics above.

For the logic layer, Google's conversation design guidance is a solid reference. It was written for Assistant, but the thinking on how a conversation should flow carries well beyond Google's own products.

Some teams shortcut the build with a specialist provider. AmmarAI's chatbot products, for example, aim at businesses that want a virtual assistant without building the platform under it. That suits a narrow, well-defined use case. You trade customisation for speed. Fair call when the chat feature isn't core to what makes your product different.

Here's the thing though. If the chat layer is part of a bigger platform, it has to share data, logic and governance with the rest of the product. There, a custom build holds up better over time. The sourcing, logging and access controls above need to be consistent across the whole system, not just the chat window. Our enterprise chatbots guide covers that architecture layer by layer. AI-Led ranks the three ways to add an AI chatbot to a website by effort and cost.

Competence beats charm

The urge to make an assistant sound warm and human is understandable. For a work tool, it's usually the wrong bet. Trust comes from getting the answer right and showing your working, not from a friendly tone. Build for competence you can measure: clear sources, visible limits, and a user who stays in control of the next step.

*James*

Where Devwiz fits

Most conversational UI problems aren't visual. They're structural. An assistant scoped as a demo and never redesigned for the edge cases production traffic throws at it.

When we build a chat feature into an AI platform, the retrieval, the logging and the human review get designed in from the first discovery session. Not bolted on after a prototype gets approved. We build AI apps and turn programs into AI platforms. The chat layer sits inside that, sharing the same data and governance as the rest of the product.

Devwiz has shipped 200+ apps, including work for NSW Government (Justice and Corrective Services), Briometrix, Vivid and Huskee.

Weighing up whether your chat feature needs a proper platform build or a wrapper around an off-the-shelf model? A discovery phase is the fastest way to find out. Worth a chat.

Frequently asked questions

What is conversational UI design?

It's the design of the visible surface people use to talk to software in plain words. The input bar, the message history, the status cues, the suggested prompts and the place where sources show. Good conversational UI design leads with the answer and keeps the assistant to one clear job.

What's the difference between conversational UI and conversation design?

Conversational UI is the surface: the chat window, buttons and message bubbles. Conversation design is the logic under it: the persona, tone and decision tree that decide what the system says and when. You need both, and a good one doesn't save a bad one.

What are the 8 golden rules of UI design?

They're Ben Shneiderman's rules for any interface: keep things consistent, give frequent users shortcuts, give informative feedback, design dialogues that close, prevent errors, make actions easy to undo, keep the user in control, and keep the load on short-term memory low. For chat, the checklist in this post covers the same ground: answer first, show sources, name the AI, and build clear fallbacks.

Is UX getting replaced by AI?

No. AI is changing what UX designers spend their time on. More effort goes to conversation logic, sourcing and governance, and less to pure screen layout. But working out what users need, and testing against it, still sits with a human designer.

How do you test a conversational UI?

Run moderated sessions where real users try to finish a task, then read the transcripts. Track task success rate, time to answer, escalation rate, hallucination rate, source-check clicks and satisfaction per answer. Roll out changes in stages and A/B test prompt wording before a full release.