Designing the empty state

In short

Kate Kaplan of NN/g defines the empty state as a container, screen or panel for which there is no content yet or whose content can’t be shown. Examples are a favourites list, an alerts panel, a newly created dashboard and a search with no results.

According to Kaplan, a totally empty area confuses users and lowers trust in the system. In audits, the empty state is for me the most often forgotten screen. The design file always shows the filled state; the empty one is left to development’s default text.

Yet every new user sees the product empty for the first time. That is why I draw the empty state at least as carefully as the filled one.

Four types of empty states

The screen looks the same in all four types: a list without content. But each time the user reaches that moment by a different path. The message should follow from that.

• First use

  When: The user has never filled the area.

  What it should say: What will appear here and how it gets filled.

  One action: The first action that fills the area: “Add your first task”.

• Cleared by the user

  When: The user has done, read or deleted everything.

  What it should say: That the work is done. Here the emptiness is a success.

  One action: The next sensible step: “Add a task for tomorrow”.

• No results

  When: Search or filters return nothing.

  What it should say: What was searched for and why nothing came back.

  One action: Widen the search: search with the corrected word or remove the filter.

• Error

  When: There is content, but it couldn’t be loaded.

  What it should say: What happened and that no data is lost.

  One action: The action that solves the problem: usually “Try again”.

For each type I recommend a single primary action. If a second path is needed, such as “Learn more”, make it a plainer link. The more options, the longer the decision takes. I describe this on the Hick–Hyman law page.

Live example: bad and good states side by side

In the example below you see the four empty states of the same task app. In the bad state, the emptiness is dismissed with a cold sentence, a number like “0 results” or an error code. In the good state, each screen explains its situation.

Four types, two states

First use

Bad Current state

Tasks

No records found.

Good Recommended state

Tasks

No tasks yet

Your tasks will appear here. Add the first one and tick it off when it’s done.

Add your first task

• Says what goes here
• A single action

Cleared by the user

Bad Current state

Tasks

No records found.

Good Recommended state

Tasks

All of today’s tasks are done

You finished all 12 tasks. Add a task for tomorrow or call it a day.

Add a task for tomorrow

• Names the success
• Can’t be confused with first use
• Gives the next step

No results

Bad Current state

Tasks

Search: invocie

0 results

Good Recommended state

Tasks

Search: invocie

No results for “invocie”

Check the spelling or search with a shorter word. Did you mean: invoice?

Search for “invoice”

• Clear and large
• Repeats the search term
• Shows a way out

Error

Bad Current state

Tasks

Error 500: request failed

Good Recommended state

Tasks

Tasks couldn’t be loaded

The connection dropped, but your tasks haven’t been deleted. Check your internet connection and try again.

Try again

• Says no data was deleted
• Offers another try

Choose a type. On the left is the bad state I often see, on the right the one I recommend. Press the button in the good state: the empty state disappears and the list gets an entry. I wrote the screens for this page. Without JavaScript, all four types are listed one below the other.

For the first two types, the bad state is the same: “No records found.” Someone new and someone who has finished see the same sentence. In the good state, the new person learns what to do and the finished one learns that they are done.

First use: making the empty screen the first step

Kaplan recommends using empty states as learning cues. These cues only appear when the user reaches the area in question. According to Kaplan, help in context is often immediately applicable and therefore sticks better than tours forced on users at first launch.

Kaplan’s third recommendation is a direct path to the work that fills the area. “Submit a request in the workspace to see details” isn’t enough, because it doesn’t say how. Put a button or link there that leads to that step instead.

One example in the article offers two paths in a complex product: connect an external data source, or load demo data and explore the product safely. In my view, demo data shows the user the filled screen before they commit.

In the onboarding pattern I compare the empty state with a tour and a tip. The short answer: the empty state doesn’t interrupt the work; it waits in place until the user adds something.

The list cleared by the user

This type is the most often overlooked. The user has worked through their inbox or task list. If the day-one screen then appears, “Nothing here yet, add your first task”, the product treats them as new.

Here, in my view, the message should be a short acknowledgement: say that the work is done and how much of it. The action should be the next sensible step. That can be a new task or a look at the archive.

For a list that became empty through deletion, I add one more thing: undo. If the user deleted the last entry by mistake, the empty screen should show them a way back.

No results: don’t leave a dead end

Kathryn Whitenton of NN/g wrote three guidelines for search pages with no results in 2014. First: make it unmistakable that there are no results. Because the eye is looking for results, a small, pale notice may not be read at all.

The second guideline is to give a way forward. Whitenton gives the example of repeating the search term in an editable field and suggesting similar searches. Spelling correction and the tip to search with different or fewer words are among her suggestions too.

The last guideline is about humour: avoid jokes that can come across as mockery. Someone who didn’t find what they were looking for may not take it well.

In filtered lists, in my view, the same logic applies: say which filter emptied the list and offer to remove it with one click.

Errors: don’t confuse emptiness with status information

Kaplan’s first guideline is to use the empty state to communicate system status. According to her, a totally empty area leaves users unsure whether the system works at all. Users then reload the query several times to be sure before moving on, and lose time.

For me, this is Nielsen’s first usability heuristic applied to the empty screen.

Kaplan also describes a worse pattern: showing “No records” while the content is still loading, and then showing the results. That damages trust. In the worst case, users in a hurry, which is most of them, never see the actual content.

Show a progress indicator while loading, and the “No records” message only once the process has finished.

In the error case, the empty state is really an error message. Nielsen’s ninth heuristic asks for this message to be written in plain language and without an error code. How to write the text is described in detail in the error messages pattern.

My note

In an audit, I try to empty every list. I create a new account, clear a list completely, set filters to a nonsensical combination and cut the connection. That way I see all four types on the screen.

The most common mistake: all four types hang off a single component. Development writes once “If the list is empty, show this text”, and nobody asks why it is empty. In the design file I draw the four empty states separately for each list.

In dashboards I also see empty charts: axes yes, line no. In the dashboard pattern I suggest an empty state for that too. If the chart is empty, write why in place of the chart.

A note on accessibility

WCAG 2.2 success criterion 4.1.3 Status Messages is level AA. It requires that status messages that appear without a change of focus are announced to assistive technologies. The W3C’s examples include messages such as “No results returned”.

If the results list empties during a live search, someone using a screen reader should hear it too. I write the message in an area with role="status" for this. In the example above, that is also how the list filling up after the click is read out.

The button in the empty state is an ordinary button: reachable by keyboard, with a visible focus ring. All the criteria are covered in the WCAG guide.

Checklist

Before launch, I check a product’s empty states against this list. If you want me to look at your product’s empty screens: the UX audit covers this.

• No list or panel stays completely empty.
• First use and a list cleared by the user show different messages.
• The message says what goes here.
• Each empty state has a single primary action.
• A search with no results repeats the search term and offers a way out.
• If a filter emptied the list, it says which one.
• While loading, it doesn’t say “No records”; there is a progress indicator.
• In the error case there is no code, but there is a way to try again.
• The empty state’s message is announced to the screen reader.