The anatomy of a good empty state

Every product has empty states. Not every product thinks about them.

The first time a user hits an empty state, they're usually in one of a few situations: they just signed up and haven't done anything yet, they searched for something and found nothing, or they deleted everything and are starting over. In all three cases they're uncertain about what to do next.

That's when your empty state is doing its job. Most of the time, it isn't.

The failure mode

Here's the empty state I see most often: a friendly illustration that probably took a designer two days, and below it, some text that says "No items yet" with a plus button.

The illustration communicates effort. The text communicates nothing. The button exists, but there's no reason to trust it. The user has landed somewhere unfamiliar and the product is telling them... nothing is here.

The problem isn't the illustration. It's that the screen has no point of view about what the user should do, or why it's worth doing.

What an empty state is actually for

An empty state is your first real conversation with a new user. Or a disappointed user. Or a confused one. At that moment, your product can either help them understand what to do and why it's worth doing. Or it can shrug.

The best empty states do three things:

Acknowledge where the user is. Not just "empty" but why it's empty. "You haven't added any projects yet" is different from "No projects match your search" is different from "Your inbox is clear." These feel obviously different when you read them. They're often treated identically in implementation.

Tell them what to do. One thing. Not three options. Not a tooltip. One action, described clearly, with a button or link that does it.

Give them a reason to bother. This is the one that almost always gets cut. "Start your first project" is an instruction. "Start your first project and invite your team" tells you something about what this thing is actually for. The empty state is one of the few moments in a product where you can remind someone why they signed up. Without it feeling like a pitch.

The taxonomy matters

Not all empty states are the same, and treating them identically is where most products go wrong.

First-run empty states are for users who haven't added data yet. The tone is inviting. There's often a small value proposition embedded. This is probably the highest-leverage moment in the whole product. The user is primed to act and they're looking for a reason to.

No-results empty states are for users who searched and found nothing. The tone is helpful and specific. Acknowledge the search. Offer a path back or a related option. "No results for 'quarterly reports'" is better than "No results." Much better.

Error-triggered empty states happen when data fails to load. Don't design these as empty states. Design them as errors. They need an explanation, a retry action, and a contact path if the retry fails. Treating a data load failure like an empty state confuses the user about whether the problem is theirs or yours.

User-cleared empty states are for users who deliberately finished or deleted everything. The tone here can be celebratory. Think Gmail's "You're all caught up." Don't celebrate when the user hasn't earned it; an empty search result is not a win. But do acknowledge the accomplishment when they genuinely cleared something.

The illustration question

Most empty states have illustrations. Most illustrations are generic. Generic illustrations signal that the empty state was designed as a reusable component rather than a specific moment.

Illustrations are fine. They add warmth and break up what would otherwise be a stark, text-only screen. But they shouldn't carry the communicative weight. The text has to work without the illustration. If removing the illustration would make the screen useless, the illustration is doing a job it can't reliably do. Especially for users on slow connections or with images disabled.

My general rule: the illustration expresses mood, not message. Inviting, calm, celebratory. Those are things an illustration communicates well. "Here's exactly what you should do next" is not.

Writing the copy

Empty state copy is product copy. It should be written with the same care as button labels and error messages. Which is to say, more care than most teams give it.

A few things that matter:

Speak to the specific state. "No results" doesn't need to exist as a string in your codebase. "No results for {query}" takes 30 seconds more and is always clearer.

Use second person. "You haven't added any X yet" is warmer and more direct than "No X have been added." One of these sounds like a person. One sounds like a system log.

One call to action. If you have two calls to action in an empty state, you've lost confidence in the moment. Pick one.

Don't overexplain. The goal is to get the user to act, not to give them a tutorial. If you need three sentences to explain what the CTA does, the product has a bigger problem than the empty state.

---

Empty states are small. They feel like details. But they're one of the few moments in a product where the user is alone, uncertain, and looking for a signal. What you put there matters more than the attention it typically receives.