Design the empty state first

Every view in your product has five states. The ideal one, full of content. Empty. Loading. Partial, with one item instead of twelve. And error.

You have designed one. Nielsen Norman Group put the reason in a parenthesis, describing a populated panel: “(This state of the panel is probably how this element was mocked up and tested.)”

That is exactly it. The state you designed is the state your seed data produced. Every real user meets at least two of the other four, and the first one they meet, on the first day, before they have done anything, is empty.

What an undesigned empty state does

Not nothing. Something actively bad, which is the part people underestimate.

NN/g again: “Totally empty states cause confusion about how and whether the system is working. When users encounter an empty panel or screen in an interface after attempting to filter, query or display specific content, they’re” left unable to tell the difference between no results, a broken filter, and a broken product.

And the worst version is not the blank div. It is the confidently wrong message: “Inaccurate system-status messages for empty states are particularly harmful.” A screen that says no records when the request actually failed teaches users to distrust every empty screen you will ever ship.

The anatomy

Three parts, and NN/g, GitHub’s Primer and 37signals arrive at the same three independently. NN/g’s own section headings are the clearest statement of them:

“Use Empty States to Communicate System Status” “Use Empty States to Provide Learning Cues” “Use Empty States to Provide Direct Pathways for Key Tasks”

Say what is happening. Say what could fill this. Give one button that does it.

BEFORE                          AFTER

┌────────────────────────┐      ┌────────────────────────┐
│                        │      │  No invoices in the    │  status:
│                        │      │  last 30 days.         │  which is it
│                        │      │                        │
│                        │      │  Invoices appear here  │  learning cue:
│                        │      │  once a customer is    │  what fills it
│                        │      │  billed.               │
└────────────────────────┘      │                        │
                                │  [ Create invoice ]    │  pathway:
a blank panel                   └────────────────────────┘  one button

or, worse:                      real examples of each part:
┌────────────────────────┐        "There are no records to display
│  No Records            │         for the selected date range"
│  Send a request to     │        "Star your favorites to list
│  view details in the   │         them here"
│  workspace             │
└────────────────────────┘      the bad one on the left is real, and
                                its pathway is not a pathway. it is
says nothing about what          an instruction to go somewhere else
would fill it, and its           and do something unspecified
"pathway" is a sentence

Loading, while we are here

The other state you skipped has published thresholds. Nielsen’s response-time limits: 0.1 seconds is “about the limit for having the user feel that the system is reacting instantaneously”, 1.0 second is the limit for keeping a user’s flow of thought uninterrupted, and 10 seconds is the limit on holding attention at all.

His rule for which indicator to use: “percent-done progress indicators should be used for operations taking more than about 10 seconds.” Between 2 and 10, a determinate indicator is still preferable where you can produce one honestly.

One caution on the fashionable answer. The evidence for skeleton screens specifically is thin, and the fact bank flags it: the published studies are small enough that their own author says you should not conclude from them. Use them because they hold layout stably, not because they are proven to feel faster.

The move

Design the five states of a view together, and put the empty one in front of a person before you build the full one.

I should correct the title, since the person who wrote the five-states framework disagrees with it. Scott Hurff’s own instruction is to start with the ideal state and let the others fall into place, which is sensible: you cannot design the absence of something you have not specified yet.

The word first actually comes from a different argument, 37signals’ point in Getting Real that the empty state is the first impression, and first impressions deserve priority. That is the claim worth keeping. Design them together, and treat empty as the one you owe the most attention, not the one you draw earliest.

What it costs

Five states is five times the design work per view, and that is not rhetorical. The honest scope is that error and partial states can often share a treatment across a whole product, so the real cost is one shared pattern plus one bespoke empty state per view.

And there are no outcome numbers here. I could not find any measured evidence that designing empty states improves activation, retention or anything else. The case is that a blank panel is ambiguous and an ambiguous panel is a support ticket, which is reasoning rather than data.

Try this week

Take the view a new user sees on their first day and open it with a genuinely empty account. Not your dev database with its seed rows. Empty.

Most people find something they have never looked at.

Then write the three lines: what is happening, what would fill this, and the one thing they could do about it. That is fifteen minutes and one component, and it is the first thing every new customer will ever see of your product.