Empty States That Don't Feel Empty: A Designer's Field Guide
Most empty states are wastelands. The four jobs an empty state actually has to do, the patterns that work, and the anti-patterns we keep removing in product reviews.
Table of contents +
Open most products, navigate to a feature with no data yet, and you’ll find an empty state. Three out of four times, it’s the same thing: a grayscale illustration of a dog or a magnifying glass, the words “Nothing here yet,” and a button that doesn’t quite know what to do.
Empty states are the most-skipped part of product design. They get the least attention, they appear at the worst possible moment (the user’s first encounter), and they often determine whether a feature gets adopted or abandoned. A well-designed empty state is one of the highest-leverage screens in a product. A bad one is a quiet drain on activation.
What an empty state actually has to do
A useful empty state has four jobs:
- Tell the user what this screen is for. Without data, the user can’t infer the purpose from context.
- Tell them why it’s empty. Is this their first time? Did a filter exclude everything? Did something fail?
- Show them how to fill it. What’s the action that produces the first item?
- Lower the stakes. Reassure them this is normal and recoverable.
Most empty states fail at job 3 and ignore job 4 entirely.
Three flavors of empty
Not all empty states are the same. The patterns that work for each differ:
- Cold empty. The user has never used this feature. They need orientation: what is this, why would I use it, what’s the next step.
- Hot empty. The user has used this before but the current state is empty (filter, search, recently cleared). They don’t need orientation; they need a way to recover.
- Error empty. Something failed. Network, permission, broken integration. They need to know what happened and what to do.
Designing one empty state for all three produces something that helps in none of them.
Patterns that hold up
A few specific moves we apply across product work:
Action-first composition
The biggest button on an empty state should be the action that ends the empty state. Not “Learn more,” not “Explore docs,” not “Take a tour.” If this is your project list and it’s empty, the button is “Create project.”
This sounds obvious. The number of products that get this wrong is enormous.
Prefilled examples
Where possible, an empty state isn’t fully empty: it shows what filled would look like, in a disabled or sample state. The user can see the shape of the feature before they invest in creating their first real item.
This requires the empty state to be designed with the populated screen in mind. Too many empty states are designed as separate artifacts, with no shared visual logic with what comes after.
Explanation that’s actually useful
“You don’t have any projects yet” is technically true and operationally useless. Replace with: “Projects organize your work and let you invite collaborators. Create your first one to get started.”
The second version takes two more seconds to write and saves the user thirty seconds of reading docs.
Recoverability for filter empty states
If the user filtered to nothing, the empty state should include the filter chips, a clear “Clear filters” button, and a count of what’s hidden. The user did this to themselves and the way out should be obvious.
Anti-patterns we keep removing
When we audit empty states across products, the patterns we remove repeatedly:
- Cute illustrations with no copy. The illustration tells the user nothing about what to do.
- Long onboarding text masquerading as an empty state. Read me an essay before I do anything.
- A CTA that links to docs. Send the user away from the feature to learn about the feature.
- The same empty state for every empty screen. A generic “Nothing here yet” component used across the app, which means it’s not really designed for any specific screen.
- Hidden empty states behind authentication walls. Logged-out users see an empty version of the dashboard with no way to log in or sign up from there.
When the empty state is the product
For some features, the empty state is the most-seen screen, period. Most users never get to the populated version because they bounced from the empty one. In that case, the empty state isn’t a fallback screen, it’s the primary surface of the feature.
This applies most often to:
- Onboarding screens that gate the rest of the app
- Search interfaces before a query is entered
- Dashboards before connections are made
- Lists that take work to populate (CRM, project management, etc.)
For these, treat the empty state with the same care as the marketing page. It’s the same job.
Closing
Empty states are a small surface that does outsized work. Designing them well is one of those quiet investments that doesn’t show up in a portfolio but shows up in retention.
If you’re auditing your product and noticing drop-off at points where data hasn’t been entered yet, the empty state is often the place to look first. Talk to us if you want a fresh pair of eyes on your product’s onboarding and empty surfaces.
Key takeaways
- The biggest button on an empty state should be the action that ends the empty state, not 'Learn more' or 'Take a tour'.
- Cold, hot, and error empties need different designs, one generic empty state fails at all three.
- Prefilled examples or sample data let users see the shape of the feature before they invest in creating their first real item.
- Filter-empty states should show the active filter chips, a 'Clear filters' button, and a count of what's hidden, the user did it to themselves and the way out should be obvious.
- For features where most users never see the populated version, the empty state IS the product surface, design it with the same care as a marketing page.
Frequently asked
What jobs does an empty state actually need to do? +
Four jobs: tell the user what this screen is for (without data they can't infer purpose from context), tell them why it's empty (first time, filtered, failed), show them how to fill it (the action that produces the first item), and lower the stakes by reassuring them it's normal and recoverable. Most empty states fail at job three and ignore job four entirely.
What are the different types of empty states? +
Three flavors that need different designs: cold empty (user has never used this feature, needs orientation), hot empty (user has used it but the current state is empty due to filter, search, or recent clearing, needs a way to recover), and error empty (something failed and they need to know what and what to do). Designing one empty state for all three produces something that helps in none of them.
What's the most common empty state anti-pattern? +
A cute illustration with no copy, paired with a CTA that links to docs instead of taking the action that would fill the screen. The user is sent away from the feature to learn about the feature. The biggest button on an empty state should be the action that ends the empty state, if the project list is empty, the button is 'Create project'.
When is the empty state actually the most important screen? +
For features where most users never get to the populated version because they bounce from the empty one, onboarding screens that gate the app, search before a query, dashboards before connections are made, lists that take work to populate like CRM or project management. In those cases the empty state is the primary surface and deserves the same care as a marketing page.