The empty state is the first thing a new user sees on every screen of a product. It is also, in most software, an afterthought. A grey illustration. A line of placeholder text that says "No items yet." A button that triggers a feature the user has not yet been told they need.
I treat empty states as a primary surface. They are not a fallback for the absence of content. They are the moment where the product teaches itself to a user who has not yet learned its conventions.
The "Talk to AI" trap
The pattern AI products gravitate toward is to gate every empty state behind a conversation. No emails yet? Ask the AI to generate some. No content pieces? Ask the AI. No campaigns? Ask the AI. The empty state becomes a portal to the chat panel and nothing else.
This sounds elegant on a product roadmap. In practice it is hostile. It assumes the user always wants to start by talking. It assumes the user knows what to ask for. It assumes the AI is the only path forward, which trains users to feel helpless without it.
I try to do the opposite. Every empty state in Cleo offers a manual creation action and a guided creation action. If you want to write an email yourself, you can. If you want the AI to draft one for you, you can. If you want to talk through what you might write, that is also there. Three doors, not one, and none of them locked.
What an empty state needs to do
A good empty state answers four questions in roughly this order. What is this screen for. What can I do here. What should I do first. How do I learn more.
The first three are not text. They are layout. The arrangement of the empty state should make the answer to "what is this screen for" obvious before the user reads a single word. A content library that is empty should still feel like a content library, not a generic placeholder. The structural shape that will eventually hold content should already be visible, just unfilled.
The fourth question is text, and it should be the smallest part of the page. A sentence, maybe two. Not a paragraph explaining the feature. Not a guided tour. Just a quiet pointer for the curious.
The cold start problem
The hardest empty state is the one a brand new user sees on their very first visit. There is no data, no history, no preferences. The temptation is to fill the screen with onboarding material. Tooltips. Tutorials. A wizard that walks through every feature.
I have learned to resist this. The user did not come to the product to do a tutorial. They came to do a thing. The right empty state for a first-time user is the same as the empty state for a returning user with nothing in this section, with one small addition: a clear path to the most likely first action. Not a wizard. A path.
What this discipline costs
Designing empty states this way takes longer. You cannot reuse a generic component across every screen. Each empty state needs to be considered in the context of the screen it lives in. The content library empty state is different from the email campaign empty state, which is different from the ad performance empty state. Each one teaches a different thing.
The cost is real. The dividend is a product where every screen, even when empty, feels intentional. The user is never told "there is nothing here." They are shown what could be here, and given several honest ways to begin.
Empty states are not the absence of content. They are the presentation of possibility.