The first screen a new user sees is often empty: no data, no history, nothing to act on. Handled poorly, it feels broken. Handled well, an empty state teaches people what your product does and gets them to their first win. This article shows how to design empty states that guide instead of confuse, with concrete patterns, a real scenario, and a checklist you can apply today.
What an empty state actually is
An empty state is any screen or region that has no content to display yet. There are three common causes, and each needs a different response.
First-use empty states
The user has never added anything. This is the highest-value moment. The screen is blank not because something failed, but because the journey has not started. Treat it as onboarding, not an error.
Cleared or user-emptied states
The user deleted everything, archived the last item, or filtered results down to zero. Here the tone is different: the emptiness is expected and often a small success. A completed to-do list should feel like an accomplishment, not a void.
Error or no-results states
A search returned nothing, or a connection failed. The user did something reasonable and got nothing back. The job here is to explain why and offer a way forward, such as adjusting the query or retrying.
Why empty states get neglected
Teams build the full-data experience first, because that is what mockups and demos show. Empty states appear only in production, when a real new account has no rows to render. By then the default is a bare table header or a lonely zero. The nature of the problem is timing: the empty state is the one screen designers rarely see themselves, because their test accounts fill up fast.
Design principles that hold up
Good empty states do three things: they explain what belongs here, they show the value of filling it, and they offer one clear action. Keep the primary action singular. A blank screen with five buttons is as paralyzing as one with none.
Match the emotional register to the cause. A first-use screen can be warm and instructive. A no-results screen should be calm and helpful, never cheeky, because a frustrated user does not want a joke. A destructive-cleared state can be quietly congratulatory.
A real scenario
Imagine a project management tool. A new user lands on the Tasks view and sees a table with columns but no rows. The weak version shows the header and stops. The user assumes the app is confusing and leaves.
The strong version replaces the blank table with a short line: “No tasks yet. Add your first task to start tracking work.” Below it sits a single primary button, “Add task,” and one sentence describing what happens next. Optionally, a faint sample row hints at the layout. Now the empty state is doing the work a tooltip tour would, without interrupting anyone. The difference is not decoration; it is direction.
Common mistakes and how to fix them
- Showing a raw blank region. Fix: never ship a screen that can be empty without designing that condition explicitly.
- Using the same message for all three causes. Fix: distinguish first-use, user-emptied, and no-results. Detect which case applies and write for it.
- Offering too many actions. Fix: pick one primary action; demote the rest to secondary text links.
- Over-illustrating. Fix: a large graphic can push the actual guidance below the fold. Lead with the sentence and the button.
- Blaming the user on no-results. Fix: suggest what to change (“Try a shorter keyword”) instead of stating only that nothing was found.
Action checklist
- List every screen and region that can render with zero items.
- Identify which of the three causes applies to each.
- Write one clear sentence explaining what belongs there.
- Add exactly one primary action per empty state.
- Match tone to cause: instructive, congratulatory, or helpful.
- Test with a brand-new account, not your own filled one.
- Confirm the guidance is visible without scrolling.
Conclusion
Empty states are not edge cases; they are the front door for every new user. Your next step is simple: create a fresh account in your own product right now and screenshot every blank screen you hit. Those screenshots are your priority list.
FAQ
Should every empty state have an illustration?
No. Illustrations can help set tone, but they are optional. The sentence and the action matter more. If a graphic pushes guidance off screen on smaller viewports, remove or shrink it.
How is an empty state different from onboarding?
Onboarding is often a separate flow layered on top of the product. An empty state is inline: it teaches at the exact place where the user will act. The two work well together, but an empty state should stand on its own.
What should a no-results search state include?
Confirm what was searched, explain that nothing matched, and suggest a concrete next step such as removing a filter or trying a broader term. Avoid dead ends.
Do empty states matter for internal tools?
Yes. Internal users are still first-time users once. A clear empty state reduces support questions and speeds up adoption, which matters even when there is no marketing pressure.
References
Nielsen Norman Group publishes well-regarded, freely available research on usability and interface patterns, including guidance on onboarding and error handling that informs empty state design.