Empty states: the most under-designed screens in your product

Open your product as a brand new user and count how many screens are empty. The dashboard with no data. The inbox with nothing in it. The project list before there is a project. That is the first impression, and in most products it was designed last, or not at all.

It is an easy thing to fix and an expensive thing to ignore, because a new user who hits a blank screen with no idea what to do does not go and find out. They leave, and they show up in your numbers as a sign-up that never activated.

Why they get missed

Designers work with populated screens because populated screens are what the product looks like when it is working. Engineers test with seeded data because empty tables make testing slow. Product managers review the happy path. By the time anyone opens the app with a fresh account, the launch date is next week and the empty states get whatever text is left over.

The result is a product that looks finished to everyone who built it and unfinished to everyone who buys it.

The four kinds

• First use. The user has never added anything. This is the important one, because it is the whole product for the first five minutes.
• User cleared. They had things and removed them all. Inbox zero, an emptied cart, a completed task list. Usually a good moment, and worth treating as one.
• No results. A search or filter returned nothing. The user did something reasonable and the product has to say so without blaming them.
• Blocked. No permission, no connection, no plan that includes this feature. Not strictly empty, but it renders in the same place and gets designed with the same neglect.

Most products design one of these, usually the first, and let the other three fall through to a generic message. Each needs its own answer, because the user arrived in a different state of mind.

What a good empty state does

Three jobs, in this order.

• Explain what goes here. Not what the feature is called, what it is for. "Your invoices will appear here once you send one" beats "No invoices".
• Show what it looks like when it is full. A faint preview, an illustration of the populated state, or real sample data. People commit to things they can picture.
• Give the one action that gets them out of the empty state. One button, not three. If there are three ways to add data, pick the one most people should use first and make the others secondary.

That is the entire specification. Most empty states we audit manage the first job badly and skip the other two.

Sample data

The strongest move for a first-use empty state is not to have one. Seed the account with realistic sample data, labelled clearly as sample, and let the user explore a working product before they have entered anything. A dashboard with example numbers teaches more in ten seconds than any tour, and the user can delete it the moment they add their own.

It matters most on products with a free trial, where the user has a fixed window to reach value and every minute spent staring at an empty screen counts against you. We covered that in our piece on free trials, demos and freemium, and it is the single design change most likely to move trial conversion.

Two rules. Make it obvious the data is fake, or you will get support tickets asking why there is a customer called Acme in the CRM. And make it one click to clear, so it never becomes an obstacle.

The mistakes we see most

• An illustration and nothing else. A cartoon of an empty box is decoration. It does none of the three jobs.
• The feature name as the explanation. "No workflows yet" tells a new user nothing if they do not know what a workflow is in your product.
• Three calls to action of equal weight. The user has just arrived and you are asking them to choose between importing, connecting an integration and creating manually. Pick one.
• Blaming the user for no results. "No matches found" is fine. "Your search returned no results" is fine. "You have not entered a valid search" is not.
• One generic empty component reused for all four kinds, so the cleared inbox and the permission error say the same thing.
• Empty states that only exist on desktop. The mobile version was never checked, and it is where most first sessions happen.

The one-day fix

• Create a fresh account and screenshot every empty screen you meet in the first ten minutes. That is your list.
• For each one, write down which of the four kinds it is. Most will be first use.
• Rewrite the copy to explain what goes here, in the user's words, not your feature names.
• Add one primary action per screen and demote the rest.
• For the two or three screens that matter most to activation, add sample data or a preview of the full state.
• Check every one of them on a phone.

That is a day for a designer and a day for an engineer, on most products. It is also the highest return per hour of almost anything on the design backlog, because it touches every single new user and almost nobody has done it properly.