How to Create a Chatbot UI: A Step-by-Step Process

On this page12 sections

• Step 1: Decide whether chat is the right interface
• Step 2: Write the conversation before designing it
• Step 3: Design the empty state and the first message
• Step 4: Design the message anatomy
• User and assistant messages
• Rich content inside answers
• Sources and citations
• Message actions
• Step 5: Design the waiting and streaming states
• Step 6: Design the failure states
• Step 7: Design history last
• Then: prototype inside the real product

Creating a chatbot UI means designing every state of a conversation, not just the happy path: the empty screen before anyone types, the message layout, what happens while the model is thinking, what happens when it fails, and how people come back to old conversations. The order you design those in matters more than any single screen, because each step exposes requirements the next one depends on.

This is the process we use when we design chat interfaces for AI products. It is written for founders and product teams doing it themselves, and it is deliberately opinionated about sequence: most expensive chat rework comes from designing the message bubbles first and discovering the failure states last.

Step 1: Decide whether chat is the right interface

Chat is the default answer to "how do we add AI to this?", and it is wrong roughly half the time. It suits tasks that are open-ended and exploratory: research, drafting, questions across a large body of information. It suits structured tasks badly.

Ask three questions before designing anything:

• Does the user know what to ask? If not, a blank chat box is a poor starting point; guided choices do better.
• Is the output structured? Configuring a report or filling a record through conversation is slower than a form.
• Would two clicks do it? If a button can finish the job, a conversation is friction dressed up as intelligence.

If chat still wins, continue. If not, the same AI capability usually works better as an inline suggestion or a copilot panel; we cover that choice in our guide to AI copilot UI design.

Step 2: Write the conversation before designing it

Open a plain text file and script five realistic exchanges: real user phrasing, realistic answers, and at least one failure, one refusal and one "I'm not sure". Do it before opening a design tool.

This step feels skippable and is the one that saves the most time. The script shows you how long real answers are, whether they contain lists, tables or code, when the assistant needs to cite a source, and what the user does after a bad answer. Every one of those is a design requirement you would otherwise discover in development.

Step 3: Design the empty state and the first message

The screen before the user types is the highest-traffic screen in the whole feature. Design it next, while the script is fresh:

• A first message that says what the assistant is for, what it cannot do, and suggests a first move.
• Three to five starter prompts that show the range of tasks and model good questions.
• An input with clear placeholder text that reinforces the scope.

We go deep on this screen in designing the first message in a chat interface.

Step 4: Design the message anatomy

Now the conversation itself. Decide, once, how each part of a message is structured:

User and assistant messages

Make the two sides clearly distinct, by alignment, background or both. Long assistant answers read better unboxed and full width, with the user's messages compact; chat-bubble symmetry works for short exchanges and fails for long ones.

Rich content inside answers

Lists, tables, code and links all need to render cleanly inside a message. Decide how wide tables scroll, how code blocks get a copy button, and how long answers are broken up.

Sources and citations

If answers are grounded in documents or data, attach sources to the claims they support, inspectable in place. It is the single strongest trust signal a chat interface has.

Message actions

Copy, retry, edit the question, and give feedback. Each should be one action, visible on hover on desktop and always available on touch.

Step 5: Design the waiting and streaming states

A response moves through several states between the user pressing send and the answer finishing: thinking, streaming, complete, and sometimes stopped or failed. Design each one:

• A thinking indicator so a pause never looks like a broken screen.
• Streaming that adds text without the layout jumping, especially around tables and lists.
• A stop button, always visible while the assistant is generating.
• What a stopped response leaves behind: the partial answer, clearly marked, with a way to retry.

Step 6: Design the failure states

This is where chat interfaces earn or lose trust, and where most teams have designed nothing.

• Errors appear inline next to the message that failed, not as a banner at the top of the window.
• Low confidence is shown as uncertainty with a way to verify, not delivered in the same tone as everything else.
• Refusals explain why and offer a useful next step, instead of a dead end.
• Limits, such as rate limits or usage caps, say when access returns, in plain language.

Our guide to handling AI errors and uncertainty covers these patterns in detail.

Step 7: Design history last

Conversation history, naming, search, sharing and deletion matter, but only once conversations are worth returning to. Designing them first is a common way to spend a week on the least important part of the feature.

When you get here, decide: how conversations are named automatically, how people find an old one, what happens when they are deleted, and whether they can be shared with a colleague.

Then: prototype inside the real product

Put the chat interface inside the actual product shell before calling it done. A window that looks balanced on a blank canvas routinely breaks next to a dense dashboard, a sidebar and a real amount of content. The fix usually belongs to the surrounding layout, not the chat, which is why it has to be tested in place.

If you are building a website widget rather than an in-product assistant, the layout questions are different; see chatbot window UI design. For the full set of chat patterns, from starters to rate limits, see our AI chatbot UI design guide. And if you would rather have the whole thing designed as build-ready Figma, that is what our AI chatbot UI design service does.