The empty state of an AI chat: what to show before the first message

Why does an empty chat need design?

A blank screen is not neutral. Someone who arrives may think the app did not load, the assistant does not work or they do not know what to do. A well-designed empty state replaces that doubt with an idea of how to use it. SetProduct’s empty-state guide sums it up: an empty state is not an error but a chance to guide, and it should say why the screen is empty and which action fills it.

In a chat the problem weighs more than in other interfaces. The input field looks like a search box and does not say what can be asked. A first-time visitor has to invent the first question without knowing the assistant’s limits.

Microsoft’s 18 guidelines for human-AI interaction (HAX, presented at CHI 2019) have a rule for this. The first, G1, says: “Make clear what the system can do”. The second, G2, asks to make clear how well it does it. The empty state is the first place where they are met or missed.

What should it include?

The greeting “How can I help?” sounds friendly, but it says nothing about scope. It invites any request, including ones the assistant cannot handle. The prompt starters pattern from AI UX Playground also advises against vague options such as “Ask me anything”.

The minimum elements are four:

1. A purpose sentence. What the assistant does and for whom, in one line.
2. A primary action. One concrete first step, such as “Summarize a document” or “Draft an email”. SetProduct recommends one clear path over three vague options.
3. Optional suggestions. Three or four short tasks that work as a menu of capabilities. Tapping one should drop its text into the input field so the person can edit it, and the suggestions disappear once the conversation starts. How to write them is covered in prompt suggestions.
4. The input field, visible and usable. Someone who wants to type freely should not have to hunt for it.

What should it NOT do?

• Look like an error. An empty chat is not a failure. If the system is down, that is a different state: an error with its recovery path, as covered in AI errors and how to recover.
• Blame the person. Phrases such as “No data” or “We found nothing” in a new chat sound like a reproach or a fault. Describe what can be done, not what is missing.
• Use illustrations that get in the way. The illustration is optional and must not replace the text. Avoid generic ones, and avoid humor in serious contexts such as banking or health.
• Cover the input field. If the empty state fills the screen and pushes the field out of view, people have to scroll before they can start.
• Overpromise. If a suggestion advertises something the assistant does badly, the first use already breaks trust.

How does it change with history and in other contexts?

When the person has earlier conversations, the empty state changes role. It is no longer an introduction but a starting point: recent conversations and the new field are shown. If the conversation history is well designed, the empty chat can be shorter.

It also helps to tell apart three screens that look alike but are not the same:

SetProduct asks that no-results states look different from first-use ones, and the same logic applies to errors.

An elaborate empty state is not always needed. If people open the tool every day with persistent conversations, a large welcome block gets in the way. And if the AI lives inside another screen, such as a comment in a document, inline AI usually needs a much smaller state.

How do you make it accessible?

People with screen readers or keyboard-only navigation use it too. Check four things:

• Focus order. When the chat opens, focus should reach the input field without going through every suggestion first.
• Suggestions as real buttons. If they can be tapped, they must be buttons with a clear name, reachable by keyboard.
• Contrast of the purpose text. Welcome lines often use light grey, and that is exactly the text that matters most.
• Status messages. If the conversation empties after an action, WCAG 2.2 success criterion 4.1.3 (level AA) asks for the message to be identified in code, for example with role="status", so a screen reader announces it without moving focus.

If there is animation, WCAG criterion 2.2.2 (level A) requires a way to pause, stop or hide it when it starts on its own and lasts more than five seconds.

How do you know it works?

Measure how many people send a first message and how long it takes them. SetProduct suggests tracking time to first value and use of the main button. If most people tap a suggestion, the empty state works as a menu; if almost nobody types anything, the screen does not explain its purpose well. Numbers tell you something is off, but not why. For that, ask someone who has never used the tool to open it and think aloud.

Example

Illustrative example: an assistant for a design studio shows an empty chat that only says “How can I help?”. A new person opens it, types “Hi”, gets a generic answer and closes the tab.

The team changes the state. Now there is one sentence, “Assistant for research and design review”, one primary action, “Summarize interview notes”, and three short suggestions. The input field stays visible below. Tapping a suggestion fills the field with editable text. The first message is no longer “Hi” but a concrete task.

Common mistakes

• Leaving only the empty field, with no purpose or example.
• Writing a generic greeting as the only guidance.
• Using the same state for a new chat and for a search with no results.
• Sending a suggestion automatically when tapped, with no chance to edit it.
• Showing animated illustrations with no way to pause them.
• Putting the primary action outside the first visible screen.

Sources

• HAX Design Library: guidelines and patterns (Microsoft)
• Guidelines for Human-AI Interaction: Eighteen best practices for human-centered AI design (Microsoft Research)
• Prompt Starters (AI UX Playground)
• Empty state UI design: turn blank screens into next steps (SetProduct)
• Understanding SC 4.1.3: Status Messages (W3C)
• Understanding SC 2.2.2: Pause, Stop, Hide (W3C)