Empty states are a design opportunity, not an afterthought.
The first thing a new user sees is usually an empty screen. Most products never design for that moment on purpose.
An empty state is the first real screen most new users see, before any of their own data exists — and most products leave it undesigned by default. It’s usually just a blank list, an unstyled placeholder, or nothing at all, at exactly the moment someone is deciding whether the product is worth their time, which is a strange moment to leave unconsidered.
Why the blank screen matters more than it looks
A new user hasn’t added anything yet. What they’re looking at is the product’s default state, and a badly handled default state quietly tells them the product wasn’t finished with them in mind. It’s a small signal, but small signals compound quickly in someone’s first few minutes with a product, and first impressions carry disproportionate weight in whether someone continues past that point at all.
There’s also a practical problem with undesigned empty states: they’re often genuinely confusing, not just unpolished. A blank list with no explanation leaves a new user wondering whether something is broken, whether they’re missing a step, or whether the product simply doesn’t have the content they expected it to have.
What a good empty state actually does
A good empty state does three things: it explains what belongs here, it shows what it will look like once something does, and it gives one clear action to take next. It replaces confusion with a next step, instead of leaving the user to guess what they’re supposed to do to move forward.
Explaining what belongs in a space seems obvious, but it’s frequently skipped because the team building the product already knows what belongs there — they’ve been looking at populated versions of the screen throughout development, and the empty version simply never got the same attention. Showing what the populated version will eventually look like is a further step that’s even more commonly skipped, even though it does real work: it sets expectations and builds anticipation rather than leaving the space feeling like a dead end.
The pattern that generalizes
This same logic applies anywhere a product can be “empty”: zero search results, a fresh account, a cleared inbox, a filtered view that happens to match nothing. Each is a moment where the interface is talking, whether anyone designed the words or not — the only choice is whether that message was chosen deliberately or left to whatever the framework’s default happened to be.
Treating every empty state as worth the same care as a populated one is a reliable signal of a product that’s been considered end to end, not just in its most commonly seen states.
Common questions
Are empty states only relevant for brand-new users? No — any moment where a view returns nothing (a search with no matches, a filtered list, an inbox after clearing everything) is functionally an empty state and deserves the same three elements: explanation, preview, and next action.
How much design effort does a good empty state actually require? Often surprisingly little relative to the impact — a clear sentence, a simple illustration or icon, and one obvious call to action usually cover the majority of cases. The effort is mostly in remembering to design it at all.
What’s the most common mistake teams make with empty states? Leaving them as an unstyled default because the team rarely encounters them personally during development, having already populated their own test accounts with data.
Takeaway: design the empty screen as carefully as the full one — for a new user, it’s the only screen that exists.