The empty state is the screen a user hits before they have done anything. No data, no history, no content. It is also, for a lot of products, the very first thing a new user sees after signing up. Teams pour weeks into the populated version of a screen and ship the empty one as an afterthought, usually a grey illustration and the word “Nothing here yet.” That blank screen is doing more work than almost any other view in the product, and it deserves the attention to match.
What an empty state actually is
An empty state is any view where the expected content is absent. That sounds narrow, but it covers more ground than most people assume. There are at least four kinds, and they are not interchangeable.
First-use empty states appear before a user has created anything. A new project board, a fresh inbox, an analytics dashboard with no events yet. These are onboarding moments wearing a different hat.
Cleared empty states appear after a user finishes something: an inbox at zero, a completed task list, a cleared notification tray. The emotional register here is reward, not instruction.
No-results empty states appear when a search or filter returns nothing. The content might exist; the query just missed it. The job is to help the user recover, not to congratulate them.
Error empty states appear when something failed: a network drop, a permissions block, a server that did not respond. These look like empty states but they are not. They need a different tone and a different action.
Designing one when you needed another is the most common mistake I see. A “no search results” screen that reads like a celebratory onboarding card feels broken. An error that pretends to be a friendly first-use prompt hides the actual problem and wastes the user’s time.
The job each one has to do
Every empty state answers three questions, in order. Where am I? Why is this empty? What do I do next? If your design skips any of those, it is decoration.
The first-use state is the one worth obsessing over, because it sets the trajectory of the whole relationship. A user who lands on a blank dashboard and understands, in one glance, what the product does and what their first move is, will activate. A user who lands on the same screen and feels confused or judged will leave. The blank screen is a fork in the road.
An empty state is not a gap in the product. It is the product introducing itself before there is anything to show.
This is why I treat first-use empty states as part of onboarding rather than part of the screen they belong to. So the question shifts. Instead of asking “what does this view look like with no data,” ask “what is the single next action that moves this person forward,” then design backward from that action.
A practical framework
Here is the sequence I run for any empty state that matters.
- Name the type. First-use, cleared, no-results, or error. Get this wrong and everything downstream is wrong. Write it down before you open the design tool.
- Define the one action. Every empty state should have a primary action, and ideally only one. Create your first project. Import contacts. Adjust your filters. Two equal buttons is usually a sign you have not decided what matters most.
- Write the words first. The copy is the design here, more than the illustration. Lead with the benefit of taking the action, not a description of the emptiness. “Add your first client to start tracking time” beats “No clients yet.”
- Decide if you need a visual at all. An illustration can warm a screen or it can be filler that pushes the real content below the fold. If it does not clarify, cut it.
- Map the transition. What happens the instant the user takes the action? The empty state should resolve into the populated state cleanly, ideally with the first item already visible. That moment is where momentum is won or lost.
Step three is the one teams skip, and it is the one that pays. Copy carries the entire emotional weight of an empty state. The muscle that writes good interface microcopy is the same one that writes good website copy, so give both the same care instead of treating one as filler.
Trade-offs worth naming
Illustration versus speed. A custom illustration set looks considered, but it is weight on the page and time on the roadmap. For a content-heavy product with twenty distinct empty states, bespoke art for each is rarely worth it. Pick the three highest-traffic states and invest there.
Helpful versus patronising. There is a tone trap in empty states. Over-explain and you talk down to returning users who hit a cleared inbox for the thousandth time. Under-explain and you abandon the first-time user. The fix is to detect which one you are serving and write for them specifically, not to average the two.
Pre-filled versus truly empty. Some products fake a populated state with sample data so the screen never looks bare. This can ease the first impression, but it risks confusing users about what is real and what is a demo. If you go this route, label the sample data unmistakably and make it one tap to clear.
Static versus responsive. A no-results state that simply says “nothing found” is a dead end. One that reflects the query (“No results for ‘invoces’, did you mean ‘invoices’?”) and offers a way back is a recovery tool. The second costs more to build. On high-traffic search, it earns its keep.
Where empty states connect to the rest of the interface
Empty states are not a standalone discipline. They sit inside the broader system of how an interface communicates state, which is the territory of micro-interactions. The moment an empty state resolves into content, that transition is a micro-interaction, and it should feel intentional rather than abrupt.
They also follow from the same first principles as everything else on screen. The hierarchy, the single clear action, the restraint with visual noise: these are the UI design principles you would apply anywhere, just applied to a screen that happens to be blank. And because the most important empty states are first-use onboarding, they share a lot with the discipline of designing forms people complete. Both are about reducing the friction between intent and action.
How Strynal approaches empty state design
We design empty states alongside the populated views, not after them. When a screen gets specced, its zero-data version is part of the same brief, with the same scrutiny applied to copy, action, and transition. Because every engagement starts on a blank page, we are not inheriting a stock empty-state component that was drawn for a product that is not yours. We design the first-use moment as the onboarding step it actually is, then build the path out of it.
If your product has empty states that feel like apologies rather than invitations, that is usually a sign the onboarding logic was never mapped. Our UI/UX design work treats those screens as a first impression worth getting right. If you want a senior look at where your interface loses people before they ever see it full, get in touch.