Empty states are the screens nobody designs for. You build a dashboard, you fill it with mock data, you ship it. Six months later somebody opens it for the first time and gets a blank rectangle with the words “No items to show.” That’s the moment they decide whether your product respects them or not, and most products fail it.
I think about empty states a lot for a thing nobody ever asks me about. They’re the one place in a UI where the design has to do real work, because there’s no content to hide behind. No data to make it look busy. Just you, the user, and a question: what now?
The four empty states that exist
Roughly, you’ve got four kinds, and they need different treatments:
- First-time-user empty – they’ve just signed up. Nothing exists yet because they haven’t done anything. This is the highest-stakes empty state because it’s also the onboarding moment.
- Cleared empty – they used to have stuff here and now they don’t (inbox zero, finished todo list, sold-out cart). This is a celebration, not a problem.
- Filtered empty – the data exists, but their search or filter returned nothing. Different problem entirely. The fix is usually “clear the filter” or “try a broader query.”
- Error empty – something is supposed to be here but the request failed. This is genuinely an error state and should look like one. Don’t pretend it’s a normal empty.
Most teams treat all four the same way. “No items to show.” Then they wonder why activation is low.
What a good one does
It does at minimum two things, and ideally three.
First, it tells you what the thing is for. Not in marketing language. In one sentence, plain. “Your invoices will appear here.” “Saved drafts go in this folder.” If the user is staring at an empty screen and can’t work out what’s supposed to go in it, the empty state has failed the most basic test.
Second, it points at the next move. A button, a link, an example. “Create your first invoice.” “Import from Stripe.” “Try one of these templates.” The friction between an empty box and a working flow should be one click, not five.
Third, optionally, a tiny bit of personality. An illustration that’s not a stock checkmark. A line of copy that sounds like a person wrote it. This is the part that’s easy to overdo. If the joke is louder than the function, you’ve made a t-shirt instead of a UI.
The ones I steal from
Linear’s “you’re all caught up” screen, the one you get when your inbox is empty, is my favorite. It’s a single sentence, a small illustration that changes randomly (sometimes a dog, sometimes a plant, sometimes a tiny rocket), and that’s it. It does no work to suggest a next step, because the next step is “close the tab and go do something else.” The product trusts you to know that. Most products don’t.
Things 3, the Mac to-do app from Cultured Code, has empty lists that just say nothing at all. The list is empty. There’s a faint placeholder that says “This list is empty” in a really light grey, and the cursor is already in the new-task input. That’s the whole empty state. It’s perfect. The next action is so obvious they don’t have to label it.
Notion’s blank workspace is more ambitious, maybe too ambitious, but I respect what it’s doing. When you create a new page it shows you a slash-command hint, three template suggestions, and a tiny “or just start typing” line. It’s trying to teach you the product through the empty state, which is hard, but for Notion specifically it works because the product is genuinely confusing on day one.
Stripe’s dashboard, when you have no payments yet, gives you a sample charge to look at and a giant “create your first payment link” button. Same idea, different domain. The empty state pre-loads enough fake data to teach you what the populated state will feel like.
The ones I won’t name but you’ve seen
Project management tool, big enterprise vendor, $40 a seat per month. Empty board says “No tasks yet.” That’s it. No button. No suggestion. No hint that this is a kanban board with columns you can rename. Just the assertion that there are no tasks. I’ve watched real users sit on this screen for forty seconds before clicking around to find the new-task button, which was hidden in a kebab menu.
Analytics tool, also big, also expensive. The empty filtered-search state shows the same generic “No data” panel as the no-data-at-all state. So you can’t tell whether your filter is too narrow or your tracking is broken. Two completely different problems, one identical screen. I lost half a day to this once.
E-commerce platform, name withheld for kindness reasons. The empty cart says “Your cart is empty.” No suggested products. No “continue shopping” button. No link back to the homepage. You’re just stuck, looking at a sad rectangle, in a checkout flow you can’t escape without using the browser back button.
How I’d actually build them
When I’m designing a new feature, I do the empty state first. Not last. Because the empty state forces you to write the explanation of what the feature is, in user-facing language, before you’ve built any of the populated UI to lean on. If you can’t write a one-line empty-state explanation that makes sense, the feature probably doesn’t make sense yet.
I sketch four versions on paper: first-time, cleared, filtered, error. Different copy, different actions, different tone. Then I check that the empty state isn’t carrying more visual weight than the populated one, because if it is, you’ve designed a screen that punishes success.
For more on small UI details that get overlooked, the older piece on How to Add Hints and Tooltips to Web Forms covers some of the same ground (different feature, same mindset). And if you’re new to UI thinking generally, the UI Interfaces for the Web piece is a decent starting point.
Anyway. Go look at the empty states in the product you’re working on right now. I’ll bet at least one of them says “No items to show.”