What is an empty state?

What a screen displays when it holds no content: a new account's dashboard, a list with no records, a search with no results. It is the first screen most new users see and the one most often left to a placeholder, which is why it carries more weight than its size suggests.

What should an empty state contain?

What goes here, why it is worth having, and the shortest route to getting one. A heading, a sentence and a primary action. Where the fastest route is importing rather than creating, that should be the primary action, because the empty state's job is to stop being empty.

Are all empty states the same?

No, and conflating them is the common mistake. A first-run empty state teaches; a filtered-to-empty state offers to clear the filter; a cleared state congratulates and gets out of the way; an error state explains a failure. Showing the first to somebody who filtered a full list is confusing.

Should an empty state have an illustration?

Only if it earns its space. A large illustration pushing the explanation and the action below the fold is decoration costing comprehension. In dense professional tools a line of text and a button usually outperforms anything larger.

How do you design an empty state for something the user cannot create?

Say what will make it appear and who can make it happen. A member looking at an empty admin list needs to know an administrator populates it, not a disabled Create button. This is the case that is nearly always missed.

Empty State

What a screen shows when it has nothing to show — the first screen of every new account and the least designed one.

UI Components

An empty state is what a screen shows when it has nothing to show. It is the first screen of every new account, the most common result of an over-narrow filter, and in most products the least designed element on the page.

The mismatch is the point. Teams design against seeded data, so the emptiest version of a screen — the one every single new customer meets first — is the one nobody looked at.

The four kinds, which are not interchangeable

Kind	Situation	What it owes the user
First run	New account, nothing created yet	What goes here, why, and the fastest way to get one
Filtered to empty	Content exists, the query excludes it	That a filter is active, and a way to clear it
Cleared	Everything done or dismissed	Acknowledgement, then get out of the way
No permission	Content exists, this person cannot see it	Who can grant access, and how to ask

Conflating the first two is the most frequent error. Somebody with nine thousand records who filtered too narrowly should not be told how to create their first one. See data table.

The fourth is nearly always missing. A member looking at an empty admin list gets either a blank panel or a disabled Create button, and neither explains that an administrator populates it.

What a first-run empty state should do

Name what goes here. In the user's words, not the object's database name.

Say why it is worth having. One sentence. Not a feature description — an outcome.

Offer the shortest route. Often this is not "Create". Importing, connecting a source, or starting from a template gets somebody to a populated screen faster, and the empty state's only job is to stop being empty. See activation.

Offer a sample. Where setup depends on something the person does not have yet — credentials, data, a colleague's approval — a sample workspace lets them see the product working today rather than next week.

Stay proportionate. A heading, a sentence, one primary action and perhaps a secondary. A full-page illustration that pushes the action below the fold has spent the screen on decoration.

Why it matters more than its size suggests

Most of the people who will abandon a product do so in the first session, before any feature deep in the product is reached. The empty state is the screen where that decision is largely made, because it is the first thing a new account shows and it either explains the product or does not.

That places it alongside onboarding rather than among decorative details. A wizard that completes successfully and deposits somebody in front of a blank dashboard has not onboarded them; it has finished a form.

In practice

A product has a five-step setup wizard with a high completion rate and poor week-two retention, and the team concludes the product is at fault.

Watching five new accounts shows something else. Everyone finishes the wizard. Everyone then lands on a dashboard that says "No data yet" with no further instruction. The people who go on to succeed are the ones who happened to find the import option in a menu; the rest look at the message, decide to come back to it later, and do not.

The fix is one screen. The same dashboard, empty, now says what a report will show, offers an import as the primary action and a sample workspace as the secondary. Nothing about the wizard changed and nothing about the product changed.

What had been measured as a product problem was a screen nobody had designed, because nobody on the team had seen it since the first week of development.

Where teams get it wrong

One empty state for every situation. A filter result told to create its first record.
Missing the permission case. A disabled button where an explanation belongs.
"No data" and nothing else. A status message where an instruction is needed.
An illustration that outweighs the action. Decoration above the fold, the route below it.
Designing against seeded data. The team never sees the screen every customer sees first.

Learn more

UI/UX design for B2B SaaS →Dashboard design: patterns and examples →