# First-run state > The most common screen in the product is an empty box, and it has to teach without running a tour. - Canonical: https://patterns.konigi.com/ai-assistants/first-run-state - Group: Input and invocation - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: empty chat, onboarding state, zero state --- ## Problem The empty conversation is the screen people see most often, and it's the same screen for someone on their first visit and someone on their four-hundredth. It has to explain an unbounded product to a newcomer and then get out of the way forever, without a modal, a tour, or a coach mark. ## Solution Treat it as a permanent screen that happens to be a newcomer's first, rather than as onboarding that happens to recur. That inversion decides everything else: it has to be quiet enough to look at daily and dense enough to teach once. Four things belong on it, and the ordering is by how expensive they're to learn the hard way: 1. **What this assistant is for.** One line, specific to this product. An in-product assistant should say what it can see, since that is the thing a viewer cannot guess and the thing that makes it worth using instead of a general chatbot. 2. **A few concrete examples.** Prompt starters do this work, and they carry most of the capability message. 3. **What it cannot do, or does badly.** HAX guideline 2 asks for this and almost nobody ships it, because it reads as an apology. Stated plainly and briefly it prevents the failure that actually loses people, which is asking a reasonable question, getting a confident wrong answer, and concluding the product lies. 4. **What happens to what they type.** Retention, training, and whether the conversation is visible to an employer are questions people have at the moment of first input, and answering them somewhere other than a settings page is the difference between cautious use and none. The hard constraint is that a returning user sees this every time they start a conversation. Anything that reads as instruction on the first view reads as nagging on the tenth. It wants to be small and dense, with nothing modal, nothing animated, and nothing that has to be dismissed. A veteran's eye should be able to skip the whole composition and land on the input without effort, which in practice means the input is the visual centre and everything else is quieter than it. The empty state also has a second audience nobody designs for: the person whose conversation list is empty because they just deleted everything, or because they're in a fresh workspace. They know the product and have no history, so the screen shouldn't congratulate them on arriving. ## Use when Any assistant with a persistent surface people return to. ## Don't use when The assistant is summoned to a specific object and dismissed, like an inline rewrite or a command-bar invocation. There the selection is the context, the invocation carries the intent, and a teaching screen in front of it's an obstacle. ## Trade-offs Everything on this screen competes with the input, and the input is what people came for. Capability claims age badly and are rarely revisited, so a screen written at launch quietly misdescribes the product a year later. Stating limitations is honest and depresses first use, which is why it keeps getting cut. A privacy line at the point of input is the right place for it and makes the first screen feel legal rather than welcoming. Every team wants to put an announcement here, because it's the highest-traffic surface in the product. That's exactly why it should be defended. ## Checklist - Does the screen say what this assistant can see, not just what it can do? - Does it state a limitation, and does that survive review by someone protecting adoption numbers? - Is the data question answered here rather than in settings? - What does this look like on the four-hundredth visit? - Does anything require dismissing, and does the dismissal persist? - Is the composer the visual centre? - Is it pleasant for a returning user with an empty history? - Who owns updating the capability claims when the product changes? - Does it work at a phone width with the keyboard up? - Is there a path from here to previous conversations? ## Compare **ChatGPT** keeps the screen close to empty with the composer centred and a small rotating set of examples, betting that the product is well enough known that explanation costs more than it returns. **Claude** changes the screen inside a project, where it describes the project's material and makes the assistant's scope the subject rather than the product's features. **Perplexity** fills the empty state with live example queries and trending searches, It teaches question shape, and it doubles as something to browse when the viewer hasn't got a question yet. **Microsoft Copilot** inside an Office application spends the screen on what it can reach in the current document and tenant, which is the right call for an assistant whose main unknown is its scope rather than its ability. ## Related Prompt starters are the part of this screen doing most of the teaching. Composer is the element everything else defers to. Conversation history is the other thing this screen has to offer a path into. Refusal is what a viewer meets when the capability claims here were too generous. Memory chip is where the data question raised here becomes concrete. ## Related patterns - [Prompt starters](https://patterns.konigi.com/ai-assistants/prompt-starters) — An empty box tells a first-time viewer nothing about what the thing can do. - [Composer](https://patterns.konigi.com/ai-assistants/composer) — One box has to take a word, a page, a file and a keyboard shortcut without growing into the whole screen. - [Conversation history](https://patterns.konigi.com/ai-assistants/conversation-history) — The useful exchange was three days ago and the viewer remembers one word from it. - [Refusal](https://patterns.konigi.com/ai-assistants/refusal) — The assistant will not do the thing, and the viewer needs to know whether to rephrase or give up. - [Memory chip](https://patterns.konigi.com/ai-assistants/memory-chip) — The assistant knows something about the viewer that the viewer never agreed to in this conversation. ## Sources - [Microsoft HAX Toolkit, Guideline 1, Make clear what the system can do](https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-what-the-system-can-do/) - [Microsoft HAX Toolkit, Guideline 2, Make clear how well the system can do what it can do](https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-how-well-the-system-can-do-what-it-can-do/) - [Google PAIR, Mental Models](https://pair.withgoogle.com/chapter/mental-models/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.