Designing empty states that don't feel broken

Most design attention goes to screens that are full: the homepage with a hero image, the dashboard with data, the product page with photos. Almost none goes to the screens that are empty, like a search with no results, a new account with no orders yet, or a dashboard before any data has been entered. These moments get treated as edge cases, but for a real user they can be the very first thing they see, and sometimes the only thing they see before deciding whether to keep going.

An empty screen with no explanation reads as a mistake. Did the search fail? Is the page broken? Did I do something wrong? A well-designed empty state answers those doubts before the user has to ask them.

Why empty states get ignored

Design work naturally focuses on the ideal case: the page as it looks once it's full of content, orders, or results. Empty states are what's left when reality doesn't match that ideal, and they're often an afterthought added right before launch, or not added at all, leaving a raw, unstyled fallback that looks like something failed to load.

This matters more than it seems, because empty states disproportionately happen to new users. A brand-new account has no orders, no saved items, no history. First impressions are exactly the moment a business can least afford to look broken, and a blank, unexplained screen at exactly that moment can quietly undo whatever good impression the rest of the site made.

There's also a practical reason this gets skipped: an empty state is hard to picture during design, because most design tools and most mockups are populated with sample data by default. A dashboard mockup with realistic-looking charts and numbers looks finished and convincing. Nobody designs the version with nothing in it unless someone specifically asks for it, so it tends to fall through the cracks between the design phase and the build phase, ending up as whatever the underlying framework shows by default.

It's worth being specific about the cost here, because "looks unfinished" undersells it. A blank screen with no explanation is genuinely ambiguous to the person looking at it. They cannot tell, from the screen alone, whether the feature is broken, whether they made an error, whether the data simply hasn't loaded yet, or whether this is exactly what it's supposed to look like right now. Every one of those possibilities implies a different next action, and an empty screen with no context leaves the user to guess among all of them at once.

The three things every empty state needs

A good empty state answers three questions immediately: why is this empty, is that normal, and what should I do now. Skip any one of them and the screen reads as a dead end rather than a starting point.

Match the empty state to the reason it's empty

Not every empty screen has the same cause, and treating them identically misses the chance to actually help. A search with zero results needs a different message than a first-time user's empty dashboard, and both need something different again from a list that's empty because a filter is too narrow.

• •No results for a search or filter. Explain that nothing matched, suggest broadening the search or clearing filters, and confirm the search itself worked correctly rather than leaving the user unsure whether it ran at all.
• •First-time use, nothing created yet. Welcome the user, briefly explain what will appear here once they act, and give a direct button to take that first action instead of leaving them to guess what to do.
• •Everything was cleared or completed, for example an empty inbox or an empty to-do list. This is often a small win worth acknowledging with a brief, positive note rather than treating it as a gap that needs fixing.
• •A temporary loading or syncing state. Make clear that content is on its way, not simply missing, usually with a loading indicator rather than empty-state copy, since the two situations look identical but mean very different things.

Getting this distinction wrong is easy to do without noticing, especially when a team builds one generic "nothing here" component and reuses it everywhere, regardless of why the screen is actually empty. It saves a bit of development time up front, but it means every one of these different situations gets the same flat, uninformative treatment, which is worse than solving none of them well and better than solving all of them the same mediocre way.

How to write empty-state copy

1. 1
   Say what's missing, plainly

   "No orders yet" beats a vague "Nothing here." Specificity removes doubt about what the screen is supposed to show.
2. 2
   Keep the tone calm, not apologetic

   An empty state is usually normal, not a failure. Avoid language that implies something went wrong when it didn't.
3. 3
   Give exactly one next step

   A single clear button or link outperforms several vague suggestions. If there are multiple valid actions, pick the most common one as the primary.
4. 4
   Keep the visual simple

   A small icon or simple graphic is enough. An elaborate illustration on every empty state adds load time and design maintenance for little benefit.
5. 5
   Test it as a first-time user would see it

   Create a fresh account or clear all filters yourself and look at the resulting screen before launch, not after a user reports it looks broken.

• ✓An unexplained empty screen reads as broken, even when it isn't.
• ✓Every empty state should explain why it's empty and what to do next.
• ✓Match tone and message to the actual cause: search, first use, or completion.
• ✓Give exactly one clear next action, not several competing ones.
• ✓New users see empty states more often than anyone, so get them right first.