When a product ships, the empty state is usually the last screen anyone thinks about. It gets designed in the final week, if it is designed at all, by whoever drew the short straw. The result is predictable: a grey panel, a slightly sad illustration, and a button that says "Create your first project" or, worse, just the words "No data yet."
The assumption behind this is that an empty state is a gap. Something missing. A place where content will eventually live. So the goal becomes filling the space with something inoffensive and moving on.
That assumption is wrong in a specific and important way. For a brand new user, the empty state is not a gap. It is the product. It is the first screen they see after signing up, the moment the product has to explain what it does and what the user should do next. A first-time dashboard with no data is not an error to be hidden. It is the product's best opportunity to teach.
Think about what a user feels when they land on an empty screen. They have just committed to trying your product. They are mildly optimistic, mildly skeptical, and looking for a reason to keep going. If they see "No data yet" and nothing else, the product has told them exactly one thing: that there is nothing here. That is not a neutral message. It is an invitation to leave.
This is why the empty state deserves the same attention as the login screen or the pricing page. It is a conversion moment.
The three states that all look the same
Part of the problem is that teams collapse three different situations into a single "empty" concept.
The first is the genuinely new user. Nothing exists because the user just arrived. This state should teach: what the product does, what a full workspace looks like, and the single best first action.
The second is the "no results" state. The user searched or filtered and found nothing. This is not about teaching the product; it is about recovering from a dead end. The user needs to understand why nothing matched and how to widen the search, not a greeting.
The third is the error or loading-failure state. Data existed but failed to load. Confusing this with "empty" hides a real problem and erodes trust.
These three states look similar, which is exactly why they need to be designed differently. A single generic empty state does three jobs badly instead of one job well.
What a good empty state actually does
A well-designed empty state does three things at once. It explains what is possible. It guides the user to one clear next action. And it reduces the anxiety of "am I doing this right?"
Consider a project management tool. A new user opens it and sees an empty board. A weak version shows an illustration and a button. A strong version shows a sample project already populated with example cards, labeled "This is a sample project. Edit it or delete it and start your own." Now the user can see the shape of the product without risking anything. They understand what a board looks like, what a card looks like, and that they can safely experiment.
Consider an analytics product with no data yet. A weak version says "No data" and stops. A strong version shows a dashboard with grey placeholder charts and a caption like "This is what your dashboard will look like once you connect a data source." The product has turned an empty moment into a preview and a clear next step: connect your data.
The pattern is consistent. The best empty states do not describe absence. They describe possibility.
The anti-patterns to avoid
The most common failure is the empty state that states the obvious and offers nothing. "No projects." No explanation of what a project is. No reason to create one. No hint of what happens next. This is the product equivalent of a closed door.
A second failure is the decorative empty state. An expensive illustration with no information and no action. It looks polished in a design review and does nothing for a user. Decoration is not communication.
A third failure is the empty state that lies. A button that says "Get started" but leads to a screen with no further guidance. The empty state promised a path and then dropped the user.
The common thread in all three is the same mistake: treating the empty state as a visual task rather than a copywriting and information-architecture task. The illustration is the least important part. The message and the next action are everything.
Making it part of activation, not a chore
The practical shift is to move the empty state out of the "polish" bucket and into the activation funnel. That means a few concrete things.
Write copy that describes what is possible, not what is missing. Instead of "No integrations," write "Connect your first integration to start syncing data." The difference is the presence of a next step.
Give exactly one primary action. Empty states that offer four buttons are asking the user to make a decision before they understand the product. One clear action, everything else secondary or hidden.
Use sample content where it makes sense. A sample project, sample data, a demo workspace. This removes the fear of breaking something and gives the user a sandbox.
Set expectations. If a product needs data before it shows anything useful, say so and show what is coming. Surprise is the enemy of retention.
And measure it. The empty state is a step in a funnel like any other. If a meaningful share of new users see it and never return, that is a design signal, not a data-availability problem.
Every empty screen is asking the user a single question: is there a reason for me to keep going? The design's job is to answer it before the user does.
This is also where empty states connect to a larger principle. A screen that wastes attention on the interface instead of the task will always bleed users, whether it is empty or full. Cognitive load is a budget, not a preference, and the empty state is where that budget is most fragile.
The takeaway
The empty state is where a product either earns a user's trust or quietly loses it. It is cheap to get right, because the fix is usually copy and structure rather than engineering. And it is expensive to ignore, because it sits at the exact moment a new user is deciding whether to stay.
The next time someone says "we'll just throw in an empty state," the right response is: no, this is the screen that teaches a new user what the product is. Let's treat it that way. That instinct, caring about the problem a screen is solving rather than the screen itself, is the whole difference between designing UI and doing product design.
