Why empty state design deserves more than a shrug emoji
An empty state is any screen or component that appears when there is no data to display: a fresh dashboard, a search that returns zero results, an inbox with nothing in it, a cart nobody has filled yet. Most teams treat these screens as edge cases and ship a grey illustration with the words “Nothing here yet”. That is a mistake, because empty states are almost always the first screen a new user sees.
Good empty state design does three jobs at once: it explains system status, it teaches the product, and it pushes one specific next action. Get those three right and a blank screen stops being a dead end and becomes the highest-intent conversion surface in your interface.
This guide breaks down the four contexts that matter most (dashboards, search results, inboxes, carts), gives you nine annotated examples you can copy, and finishes with a checklist of the mistakes that leave users stuck.
The four types of empty states (and why the difference matters)
Before you write a single line of copy, identify which type you are designing. Each type has a different user mindset, so each needs a different next action.
| Type | When it appears | User mindset | Primary goal |
|---|---|---|---|
| First use | New account, new workspace, new module | Curious but unsure what the product does | Activation: create the first object |
| No results | Search or filters return nothing | Frustrated, goal-driven, in a hurry | Recovery: relax the query, suggest alternatives |
| Cleared / completed | Inbox zero, all tasks done, no alerts | Satisfied, momentarily idle | Reward, then offer a useful side action |
| Blocked / error | Offline, permission denied, failed load, sync pending | Confused, suspects a bug | Explain cause, give a retry or a contact path |
The single biggest error in the wild: using the same generic component for all four. A filtered-out table and a broken API call look identical to the user, so they blame your product for both.
The anatomy of an empty state that converts
Every high-performing empty state we audit contains the same five ingredients, stacked in the same order. Empty State UX Examples & Best Practices tackles the same question from another angle.
- Visual anchor: an icon, a spot illustration or a ghost preview of the future content. Small, neutral in tone, never bigger than the action button in visual weight.
- Headline (3 to 6 words): states the situation in plain language, not a joke.
- Support line (1 to 2 sentences, under 140 characters): explains why the screen is empty and what will fill it.
- One primary action: a single button with a verb that matches the headline.
- One secondary escape: import data, view a sample, read the doc, contact support. Text link, never a second button of equal weight.
The copy formula
Use this template when you are stuck. It works for almost every empty screen:
[What is missing] + [why it is missing or what it will do for you] + [the one action that fixes it]
Example: “No invoices yet. Invoices appear here once you send your first one and get paid. Create an invoice.”
Illustration: when to use one, when to skip it
Illustrations are the most abused part of empty state design. Rules that hold up in usability testing:
- Use an illustration for first-use states, where you have room and want to reduce the feeling of a broken page.
- Use a small icon or nothing for no-results states inside dense tables and dropdowns. A 400px astronaut floating above a filtered table is noise.
- Never make the illustration carry meaning alone. Screen readers announce nothing from an SVG; the text must stand on its own.
- Ghost content beats metaphor for dashboards. Showing a faded skeleton of what a filled chart looks like teaches the layout before data exists.
- Keep humour under control. A joke that lands on first use is irritating on the fifth failed search.
9 empty state examples, annotated
1. The SaaS dashboard on day one (project management)
Pattern: ghost cards showing the layout of a populated board, plus a single “Create your first project” button and a “Start from a template” link.
Why it works: the ghost preview answers the unasked question “what is this screen supposed to look like?”. The template link removes the blank-page paralysis for users who do not know what to create.
Copy to steal: “Your projects will live here. Start with a template or build one from scratch.”
2. The analytics dashboard waiting on an integration
Pattern: a status-led empty state. Headline names the blocker (“No data from Stripe yet”), support line sets an expectation (“Data usually appears within 15 minutes of connecting”), action is “Check connection”, secondary is “See sample dashboard”.
Why it works: it separates empty because new from empty because broken. The sample dashboard keeps the user engaged during a wait they cannot control.
3. Zero results inside a B2B app search
Pattern: echo the query back (“No results for invoicce“), suggest a spelling correction, and list the active filters as removable chips.
Why it works: most in-app zero-result screens are caused by filters the user forgot they applied. Showing filters as one-tap chips turns a dead end into a one-click recovery.
Anti-pattern to avoid: clearing the search box automatically. Users lose their query and have to retype it.
4. E-commerce search with no matching products
Pattern: a short apology-free line, then a merchandised fallback: popular items in the closest category, plus “Notify me when this is back”.
Why it works: a zero-result page in retail is high intent and near-total revenue loss. Filling it with related products recovers a meaningful share of otherwise lost sessions. Feed the fallback with category-level bestsellers rather than random recommendations.
5. The empty shopping cart
Pattern: headline “Your cart is empty”, one primary button “Continue shopping” pointing at the last category browsed (not the homepage), plus a row of recently viewed items and any saved-for-later products.
Why it works: the last category browsed preserves context. Recently viewed items are the strongest re-entry signal you have. Add a low-key reassurance line (free returns, secure checkout) because the cart is where trust decisions happen.
6. The empty wishlist or saved items list
Pattern: teach the mechanic. “Tap the heart on any product to save it here.” Include a small visual of the heart icon in context.
Why it works: this is an instructional empty state. The user is not blocked, they simply do not know the feature exists. Showing the exact icon they need to look for is more effective than any illustration.
7. Inbox zero in a support or messaging tool
Pattern: a genuine reward moment. Short celebratory headline, a stat (“You cleared 14 conversations today”), then a useful onward action such as “Review snoozed” or “Open team queue”.
Why it works: a completed state is the one place where personality pays off. Adding a number turns a decorative screen into a performance signal agents actually care about.
8. The empty team or permissions state
Pattern: “You do not have access to this workspace” with an explicit path: “Request access from Maria Lopez (workspace admin)” as the primary action.
Why it works: blocked states must name the person or process that unblocks them. “Contact your administrator” without naming the administrator is a dead end and a support ticket.
9. The offline or failed-load state
Pattern: distinct visual language from your other empty states (a warning tone rather than a friendly illustration), a plain explanation, a “Try again” button, and cached content displayed underneath where possible.
Why it works: users forgive a failure they understand. They do not forgive a cheerful cartoon that implies everything is fine when nothing loaded.
One screen, one next action
The discipline that separates good empty state design from decoration is ruthless prioritisation of the call to action. For each blank screen, answer one question: what is the single behaviour that moves this user forward?
| Screen | Single next action | Secondary escape |
|---|---|---|
| First-run dashboard | Create first object | Load sample data / template |
| In-app no results | Clear filters | Broaden search or search all workspaces |
| Store no results | Browse closest category | Back-in-stock alert |
| Empty cart | Return to last category | Recently viewed / saved items |
| Inbox zero | Open next queue | Review snoozed items |
| Blocked / error | Retry | Contact named admin or support |
Accessibility and technical details teams forget
- Announce the state change with
aria-live="polite"so screen reader users know a search returned nothing. - Give decorative illustrations
alt=""andaria-hidden="true"; keep all meaning in real text. - Reserve the vertical space the empty state occupies so the layout does not jump when data loads.
- Use skeleton loaders while fetching, and only swap to the empty state once the request resolves. Showing “No results” during loading is the fastest way to make a fast product feel broken.
- Check contrast on muted grey text. Empty state copy is the most commonly failing text in accessibility audits.
- Localise carefully: playful English copy often translates into something odd or rude.
Checklist: 12 mistakes that leave users stuck
- Using the same component for first-use, no-results and error states.
- Writing “No data available” and stopping there.
- No call to action at all, or three competing ones.
- A giant illustration that pushes the button below the fold.
- Humour on an error or blocked state.
- Wiping the user’s search query when zero results are returned.
- Hiding which filters caused the empty result.
- Sending empty-cart traffic to the homepage instead of the last browsed category.
- “Contact your administrator” without naming the administrator.
- Showing the empty state during loading instead of a skeleton.
- Text baked into an SVG, invisible to screen readers and translation files.
- Never measuring it: no event on impression, no event on CTA click.
How to measure whether your empty states work
Instrument every empty state as a real screen. Track three numbers per state:
- Impression rate: how many sessions hit this blank screen. A high number on a no-results state points at a search or catalogue problem upstream.
- CTA click-through rate: the direct measure of whether your copy and action are working. Anything under 20 percent on a first-run state is worth rewriting.
- Exit rate: the share of users who leave the product or the session from that screen. This is your “stuck” metric.
Empty states are small, isolated components, which makes them unusually cheap to A/B test. Rewriting a headline and a button label is a one-day change that can move activation more than a redesign of the screen behind it.
A 30-minute audit you can run this week
- List every screen in your product that can be empty. Include modals, dropdowns, tables, side panels and notification trays.
- Classify each one: first use, no results, cleared, or blocked.
- Screenshot the current version of each and paste it into one board.
- Mark every screen with no clear next action in red.
- Rewrite the red ones with the copy formula above, then ship the copy changes before you commission a single illustration.
In most audits we run, copy alone fixes more than half the problems. The illustration budget can wait.
FAQ
What is an empty state in UX?
An empty state is a screen or component shown when there is no content to display, for example a new dashboard, a search with zero results, an empty inbox or an empty cart. It communicates system status and guides the user toward the action that will fill the screen. Related reading: SaaS Empty state page design examples.
Do empty states always need an illustration?
No. Illustrations help on first-use screens where you have space and want to soften a blank page. In dense tables, dropdowns and inline results, a small icon or plain text performs better and loads faster.
How long should empty state copy be?
A headline of three to six words and a support line of one or two sentences under roughly 140 characters. If you need more than that, the underlying flow is probably too complicated.
What is the difference between an empty state and an error state?
An empty state means the system worked and there is legitimately nothing to show. An error state means the system failed. They should look and sound different, because the user’s next action is different: create or search versus retry or get help.
Should an empty state have one button or several?
One primary button, plus at most one secondary text link. Two equally weighted buttons force a decision the user is not equipped to make on a screen they did not expect to land on.
How do I design an empty state for a filtered list?
Keep the query visible, show the active filters as removable chips, offer a one-click “Clear all filters” action, and suggest a broader scope such as searching across all workspaces or the full catalogue.
Takeaway
Blank screens are not gaps in your product, they are moments where the user is paying full attention and has nothing else to look at. Treat each one as a designed screen with a job: name the situation, explain it in one sentence, and offer one obvious next step. Do that consistently and your empty states will quietly become one of the best-converting surfaces you own.
