---
title: Empty State
slug: empty-state
kind: pattern
summary: What a screen shows when it has nothing to show — which is either someone's first impression of the feature, or proof that their work is done.
problem: >-
  A list with no rows renders as a blank area or the word "None". The person
  cannot tell whether the feature is broken, whether their filter is too narrow,
  or whether they are supposed to do something — so they leave.
family: [orient, recover]
data_shape: [collection]
principles: [orientation, friction]
interaction: [scanning]
density: low
complexity: low
status: stable
visibility: public
use_when:
  - Any list, table, board, queue or search result can legitimately be empty.
  - A new account starts with nothing, so the empty state is the first screen anyone sees.
avoid_when:
  - Never. Every collection needs one — the only question is which of the four kinds it is.
alternatives:
  - slug: loading-skeleton
    when: The content is not empty, it has not arrived yet. Those must look different.
ask_leo: |
  Give every empty collection in this app a real empty state, and pick the right
  one of the four kinds.

  FIRST USE — nothing exists yet. Say what this feature is for in one sentence,
  show the primary action as a button, and if setup is involved, say how long it
  takes. This is the highest-value screen in the product; do not waste it on the
  word "None".

  FILTERED TO NOTHING — records exist but none match. Say which filters are
  active, give the total that exists without them, and offer to clear the
  filters. Never show the first-use screen here; it implies their data is gone.

  ALL DONE — a queue or task list someone emptied. Say so as success, in plain
  words, and offer where to go next. Do not show a "create one" button; nobody
  finishing a queue wants to add work.

  ERROR — the data could not be loaded. Say that clearly, offer retry, and never
  let it look like "you have nothing". A failure that reads as emptiness makes
  people think their records were deleted.

  In every case: no bare "No results". Say what is empty, why, and what to do.
related:
  - title: Filter Bar
    url: /patterns/filter-bar
    summary: Where the filtered-to-nothing state comes from, and what it must offer.
  - title: Orientation
    url: /patterns/orientation
    summary: An empty screen is where orientation matters most and is skipped most.
---

## Anatomy

There is no single empty state. There are four, and showing the wrong one is
worse than showing none, because it asserts something untrue.

```
FIRST USE                        FILTERED TO NOTHING
┌───────────────────────────┐    ┌───────────────────────────┐
│  No invoices yet          │    │  No invoices are overdue  │
│  Invoices bill a client   │    │  and owned by Dana.       │
│  for completed jobs.      │    │  318 invoices exist.      │
│      [ Create invoice ]   │    │      [ Clear filters ]    │
└───────────────────────────┘    └───────────────────────────┘

ALL DONE                         ERROR
┌───────────────────────────┐    ┌───────────────────────────┐
│  Queue clear ✓            │    │  Couldn't load invoices.  │
│  Nothing is waiting on    │    │  The billing service did  │
│  you right now.           │    │  not respond.             │
│      [ Back to dashboard ]│    │      [ Try again ]        │
└───────────────────────────┘    └───────────────────────────┘
```

## Why it works

An empty screen is the only screen with **no content to compete with the
message**, which makes it the most reliably read text in the product. First-use
empty states are, in practice, the best onboarding surface anyone has: they
appear exactly when the person is trying to understand the feature, and they
cost nothing to build.

The other three kinds are about preventing a wrong conclusion. Emptiness is
ambiguous by nature — the same blank area means "you have none", "your filter is
narrow", "you are finished" and "we are broken". Naming which one it is removes
the ambiguity, and that is the whole job.

## The dangerous confusion

**An error that looks like emptiness is the worst outcome in this pattern.**
A failed request rendering as "No invoices" tells a paying customer their data
is gone. They will not report a loading bug; they will report data loss, or
churn.

The same applies to a filtered list showing the first-use state — "No invoices
yet. Create your first one" — when the person has three hundred invoices and a
narrow filter.

## Getting it wrong

- **"No results."** True, useless, and it is the default in almost every table
  component.
- **The wrong kind.** First-use copy on a filtered list; a create button on a
  finished queue.
- **Blank.** Indistinguishable from a rendering failure.
- **An illustration and nothing else.** A friendly drawing is not an
  explanation.
- **A first-use state with no action**, which explains the feature and then
  leaves the person with no way to start using it.

## Exemplars

**Slack's empty channel** tells you what the channel is for and gives you the
one action that makes it useful, which is why nobody has ever had to be taught
what to do in a new channel.

**Gmail's "You're all caught up"** is the finished-queue state done as success,
and it is a big part of why emptying an inbox feels like an accomplishment
rather than an absence.

**Stripe's filtered empty state** names the filters back to you and offers to
clear them — the small thing that stops people concluding the data is missing.

The extractable rule: **empty is a question, and the screen has to answer it.**
Which of the four kinds this is, is the answer.