Most chatbot designs get the happy path right: a clean input, a tidy bubble and a good first answer. Then a real user asks something the bot cannot do, the reply takes eight seconds, or the connection drops halfway through a sentence. The interface has no plan for any of it.
This guide walks through the six states of an AI chat interface, from the empty start screen to the failed reply. You will get a table of what each state should show, the best practices for each, an accessibility checklist and a test you can run this week.
Key takeaways
A chat has six states, not one. Design each of them: start, send, wait, stream, finish and fail.
Say what the bot can and cannot do before the first message, with real examples.
Make waiting visible, and let people stop a reply that is going the wrong way.
Announce new messages to assistive technology without stealing focus.
Plan the failure state first. It is the moment users remember.
What makes AI chatbot UX different from a normal form or page?
An AI chatbot answers in an open ended way, so the interface cannot predict what comes back. The reply may be slow, wrong, partial or off topic, and the user has no menu to guide them.
That puts more weight on the frame around the conversation. The interface has to set expectations, show progress, make output easy to check and give people a way out when a reply fails. Microsoft’s human AI interaction guidelines (Amershi et al., CHI 2019) start from the same place: make clear what the system can do and how well it can do it, and support efficient correction.
This guide covers the chat window itself. To decide whether your assistant should be a chat at all, or inline suggestions, a side panel or an agent that acts, see AI Copilot UX Patterns. For the trust side, see How to Design Trust Into AI Interfaces.
What is the Six State Chat Model?
The Six State Chat Model describes one chat message from empty screen to finished reply or failure. Design the interface for each state in turn.
State | What the user is doing | What the interface should show |
|---|---|---|
1. Start | Deciding what to ask | Scope, example prompts, limits |
2. Send | Submitting a message | The message appears at once, input stays usable |
3. Wait | Waiting for a reply | A clear progress signal, a way to cancel |
4. Stream | Reading while it writes | Text that stays readable, a stop control |
5. Finish | Judging the answer | Sources, copy, retry, feedback |
6. Fail | Recovering from a problem | Plain explanation, retry, a human route |
Most chatbots are polished in states 1, 2 and 5. The gaps are in 3, 4 and 6.
How do you design the start state?
Tell people what the bot is for, what it is not for and what a good question looks like. A blank input with a blinking cursor makes users guess, and a wrong guess feels like the bot’s failure.
Write a one line scope: “Ask about your orders, returns and delivery times.”
Add three to five clickable example prompts taken from real questions.
State one or two limits plainly: “I cannot change your account details.”
Say when a person is available, and how to reach them.
Pro tip: Build the example prompts from your actual chat logs, not from what the team wishes people would ask. The real questions are shorter and messier than you expect.
How should the wait and stream states work?
Show that something is happening, show roughly what, and let the user stop it. Silence for more than a couple of seconds reads as a crash.
Display the message the moment it is sent, before the reply starts.
Use a typing or working indicator, and name the step when it is long, such as “Searching your documents.”
Stream text in readable chunks and keep the scroll position stable while it grows.
Provide a stop button that works at any point, and keep what was already written.
Do not move the input while a reply is writing.
If a reply takes a long time because the bot is using tools or searching, show the steps. People tolerate a wait they understand.
How do you design the finish state?
Give people what they need to judge the answer and act on it. The finish state is where trust is built or lost.
Element | Why it helps |
|---|---|
Sources or the basis for the answer | Lets users check it in one click |
Copy, retry and edit | Keeps the user in control |
Feedback controls | Collects signal, and tells users it matters |
Suggested follow ups | Moves a stalled user forward |
A clear label on generated content | Separates generated text from facts the system looked up |
Do not bury the answer under extra buttons. Put the actions below the message and keep them quiet until the user reaches for them.
How do you design the fail state?
Say what happened in plain words, what is still safe and what to do next. A good error message is short, specific and never blames the user.
Name the problem: “I could not reach your order history.”
Say what is unaffected: “Your messages so far are saved.”
Offer the next step: a retry button, a rephrase suggestion or a link to a person.
For a reply the bot cannot give, say so and offer a route: “I cannot help with refunds. Here is how to reach support.”
Never show a raw error code as the whole message.
A handoff to a human should carry the conversation with it, so people do not repeat themselves.
How do you make a chat accessible?
Treat the message list as a live region, keep keyboard control and test with a screen reader. Chat interfaces change content without moving focus, which is exactly the case WCAG addresses.
WCAG 2.2 success criterion 4.1.3, Status Messages (level AA), asks that status changes be exposed to assistive technology without moving focus. W3C’s guidance lists role status for result and state messages and role log for sequences of updates. It also warns that assertive announcements for unimportant content are a failure, because they interrupt users.
Mark the message list so new replies are announced politely, not assertively.
Announce state changes such as “Reply ready” or “Something went wrong.”
Keep every control reachable by keyboard, including stop and retry.
Keep focus in the input after sending, and make focus order match reading order.
Check color contrast on bubbles, timestamps and placeholder text.
Test with a screen reader, because streaming text can be read out in fragments.
Do not announce every streamed word. Announce when the reply is complete, or in readable chunks.
Where do AI chat interfaces frustrate users?
Users get frustrated when the bot hides its limits, goes silent while it works or leaves them stuck after an error. Six to fix first:
No scope on the start screen. Users ask for things the bot cannot do.
Silent waits. A pause with no signal reads as broken.
No stop button. Users must sit through a wrong answer.
Answers with no source. The user cannot check anything.
Dead end errors. The conversation ends with no next step.
Hiding the human route. Frustrated users cannot escape.
How do you test a chatbot this week?
Test the three hard states with five users and a script that breaks things on purpose.
Ask each user to complete a real task, such as finding the status of an order.
Add a slow reply and see whether they wait, stop or leave.
Add one question the bot cannot answer and watch how they recover.
Switch the network off mid reply and watch what the interface does.
Pass if users recover without help in two of the three cases.
Pro tip: Record a transcript of every failed chat for a week and sort it by state. You will usually find that most complaints come from two states, not six.
Also read: Onboarding and Empty States for AI Tools, How to Show AI Accuracy and Trust on a Landing Page.
To see how we design AI product interfaces, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
Which state of your chat is weakest?
Send us a chat flow and we will mark the states that have no design. Book a design review · See our work
AI chat interface FAQs
Six: start, send, wait, stream, finish and fail. Start sets scope with example prompts, send shows the message at once, wait and stream show progress with a stop control, finish gives sources and actions, and fail explains the problem and offers a next step or a person.
Say what happened in plain words, say what is still saved, and give a next step such as retry, rephrase or contact a person. Avoid raw error codes and avoid blaming the user. Test the failure state with real users, because it is the moment people remember most.
Expose new messages to assistive technology with a polite live region or log role, keep full keyboard control, keep focus in the input after sending and check contrast. WCAG 2.2 criterion 4.1.3 covers status messages. Test with a screen reader, since streamed text can be read in broken fragments.
Often yes, because users see progress sooner and can stop a wrong answer early. Keep the text readable as it grows, keep scroll position stable and provide a stop button. For screen readers, announce completion or readable chunks rather than every word.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the chat states, the empty and error screens and the pages that explain the product, so the experience and the message stay consistent.
Put a one line scope and three to five example prompts on the start screen, and state one or two limits plainly. Show when a person is available. Correct wrong expectations early, because users who expect too much judge the whole product by one failure.
Run a task test with about five users and break three things on purpose: slow the reply, ask something the bot cannot answer and drop the connection mid reply. Watch whether people recover without help, then sort real failed chats by state each week.
About the author
Aneri is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Amershi et al., Guidelines for Human AI Interaction, Microsoft Research, CHI 2019
Understanding Success Criterion 4.1.3: Status Messages, WCAG 2.2, W3C, read Nov 3, 2026 (w3.org/WAI/WCAG22/Understanding/status-messages)
Six State Chat Model: Kraftbase framework, not a published standard
Design review
Which state of your chat is weakest?
Send us a chat flow and we will mark the states that have no design.
Most chatbot designs get the happy path right: a clean input, a tidy bubble and a good first answer. Then a real user asks something the bot cannot do, the reply takes eight seconds, or the connection drops halfway through a sentence. The interface has no plan for any of it.
This guide walks through the six states of an AI chat interface, from the empty start screen to the failed reply. You will get a table of what each state should show, the best practices for each, an accessibility checklist and a test you can run this week.
Key takeaways
A chat has six states, not one. Design each of them: start, send, wait, stream, finish and fail.
Say what the bot can and cannot do before the first message, with real examples.
Make waiting visible, and let people stop a reply that is going the wrong way.
Announce new messages to assistive technology without stealing focus.
Plan the failure state first. It is the moment users remember.
What makes AI chatbot UX different from a normal form or page?
An AI chatbot answers in an open ended way, so the interface cannot predict what comes back. The reply may be slow, wrong, partial or off topic, and the user has no menu to guide them.
That puts more weight on the frame around the conversation. The interface has to set expectations, show progress, make output easy to check and give people a way out when a reply fails. Microsoft’s human AI interaction guidelines (Amershi et al., CHI 2019) start from the same place: make clear what the system can do and how well it can do it, and support efficient correction.
This guide covers the chat window itself. To decide whether your assistant should be a chat at all, or inline suggestions, a side panel or an agent that acts, see AI Copilot UX Patterns. For the trust side, see How to Design Trust Into AI Interfaces.
What is the Six State Chat Model?
The Six State Chat Model describes one chat message from empty screen to finished reply or failure. Design the interface for each state in turn.
State | What the user is doing | What the interface should show |
|---|---|---|
1. Start | Deciding what to ask | Scope, example prompts, limits |
2. Send | Submitting a message | The message appears at once, input stays usable |
3. Wait | Waiting for a reply | A clear progress signal, a way to cancel |
4. Stream | Reading while it writes | Text that stays readable, a stop control |
5. Finish | Judging the answer | Sources, copy, retry, feedback |
6. Fail | Recovering from a problem | Plain explanation, retry, a human route |
Most chatbots are polished in states 1, 2 and 5. The gaps are in 3, 4 and 6.
How do you design the start state?
Tell people what the bot is for, what it is not for and what a good question looks like. A blank input with a blinking cursor makes users guess, and a wrong guess feels like the bot’s failure.
Write a one line scope: “Ask about your orders, returns and delivery times.”
Add three to five clickable example prompts taken from real questions.
State one or two limits plainly: “I cannot change your account details.”
Say when a person is available, and how to reach them.
Pro tip: Build the example prompts from your actual chat logs, not from what the team wishes people would ask. The real questions are shorter and messier than you expect.
How should the wait and stream states work?
Show that something is happening, show roughly what, and let the user stop it. Silence for more than a couple of seconds reads as a crash.
Display the message the moment it is sent, before the reply starts.
Use a typing or working indicator, and name the step when it is long, such as “Searching your documents.”
Stream text in readable chunks and keep the scroll position stable while it grows.
Provide a stop button that works at any point, and keep what was already written.
Do not move the input while a reply is writing.
If a reply takes a long time because the bot is using tools or searching, show the steps. People tolerate a wait they understand.
How do you design the finish state?
Give people what they need to judge the answer and act on it. The finish state is where trust is built or lost.
Element | Why it helps |
|---|---|
Sources or the basis for the answer | Lets users check it in one click |
Copy, retry and edit | Keeps the user in control |
Feedback controls | Collects signal, and tells users it matters |
Suggested follow ups | Moves a stalled user forward |
A clear label on generated content | Separates generated text from facts the system looked up |
Do not bury the answer under extra buttons. Put the actions below the message and keep them quiet until the user reaches for them.
How do you design the fail state?
Say what happened in plain words, what is still safe and what to do next. A good error message is short, specific and never blames the user.
Name the problem: “I could not reach your order history.”
Say what is unaffected: “Your messages so far are saved.”
Offer the next step: a retry button, a rephrase suggestion or a link to a person.
For a reply the bot cannot give, say so and offer a route: “I cannot help with refunds. Here is how to reach support.”
Never show a raw error code as the whole message.
A handoff to a human should carry the conversation with it, so people do not repeat themselves.
How do you make a chat accessible?
Treat the message list as a live region, keep keyboard control and test with a screen reader. Chat interfaces change content without moving focus, which is exactly the case WCAG addresses.
WCAG 2.2 success criterion 4.1.3, Status Messages (level AA), asks that status changes be exposed to assistive technology without moving focus. W3C’s guidance lists role status for result and state messages and role log for sequences of updates. It also warns that assertive announcements for unimportant content are a failure, because they interrupt users.
Mark the message list so new replies are announced politely, not assertively.
Announce state changes such as “Reply ready” or “Something went wrong.”
Keep every control reachable by keyboard, including stop and retry.
Keep focus in the input after sending, and make focus order match reading order.
Check color contrast on bubbles, timestamps and placeholder text.
Test with a screen reader, because streaming text can be read out in fragments.
Do not announce every streamed word. Announce when the reply is complete, or in readable chunks.
Where do AI chat interfaces frustrate users?
Users get frustrated when the bot hides its limits, goes silent while it works or leaves them stuck after an error. Six to fix first:
No scope on the start screen. Users ask for things the bot cannot do.
Silent waits. A pause with no signal reads as broken.
No stop button. Users must sit through a wrong answer.
Answers with no source. The user cannot check anything.
Dead end errors. The conversation ends with no next step.
Hiding the human route. Frustrated users cannot escape.
How do you test a chatbot this week?
Test the three hard states with five users and a script that breaks things on purpose.
Ask each user to complete a real task, such as finding the status of an order.
Add a slow reply and see whether they wait, stop or leave.
Add one question the bot cannot answer and watch how they recover.
Switch the network off mid reply and watch what the interface does.
Pass if users recover without help in two of the three cases.
Pro tip: Record a transcript of every failed chat for a week and sort it by state. You will usually find that most complaints come from two states, not six.
Also read: Onboarding and Empty States for AI Tools, How to Show AI Accuracy and Trust on a Landing Page.
To see how we design AI product interfaces, read our ORYN AI agent monitoring landing page case study, or browse all of our case studies.
Which state of your chat is weakest?
Send us a chat flow and we will mark the states that have no design. Book a design review · See our work
AI chat interface FAQs
Six: start, send, wait, stream, finish and fail. Start sets scope with example prompts, send shows the message at once, wait and stream show progress with a stop control, finish gives sources and actions, and fail explains the problem and offers a next step or a person.
Say what happened in plain words, say what is still saved, and give a next step such as retry, rephrase or contact a person. Avoid raw error codes and avoid blaming the user. Test the failure state with real users, because it is the moment people remember most.
Expose new messages to assistive technology with a polite live region or log role, keep full keyboard control, keep focus in the input after sending and check contrast. WCAG 2.2 criterion 4.1.3 covers status messages. Test with a screen reader, since streamed text can be read in broken fragments.
Often yes, because users see progress sooner and can stop a wrong answer early. Keep the text readable as it grows, keep scroll position stable and provide a stop button. For screen readers, announce completion or readable chunks rather than every word.
Yes. Kraftbase is a product messaging and UI/UX design studio for AI and B2B SaaS companies. We design the chat states, the empty and error screens and the pages that explain the product, so the experience and the message stay consistent.
Put a one line scope and three to five example prompts on the start screen, and state one or two limits plainly. Show when a person is available. Correct wrong expectations early, because users who expect too much judge the whole product by one failure.
Run a task test with about five users and break three things on purpose: slow the reply, ask something the bot cannot answer and drop the connection mid reply. Watch whether people recover without help, then sort real failed chats by state each week.
About the author
Aneri is a designer at Kraftbase, a product messaging and UI/UX design studio in Vadodara, India, that helps AI and B2B SaaS teams in the US, UAE and India explain and design what they’ve built.
Sources
Amershi et al., Guidelines for Human AI Interaction, Microsoft Research, CHI 2019
Understanding Success Criterion 4.1.3: Status Messages, WCAG 2.2, W3C, read Nov 3, 2026 (w3.org/WAI/WCAG22/Understanding/status-messages)
Six State Chat Model: Kraftbase framework, not a published standard
Design review
Which state of your chat is weakest?
Send us a chat flow and we will mark the states that have no design.