Empty states: Make new users pick, not invent

Open your product’s reports page before anyone has made a report. It probably says “No data yet.”

Think about what that screen is asking for. It wants the user to picture the report they want. To picture it, they have to already know what your product can build, and that is the one thing a new user does not have. So they look at the blank space, decide they will come back to it, and don’t.

Now put a finished report on that screen instead, with a button that says “make one like this.” The job just changed. They are no longer inventing something, they are picking something. Picking is easy, and closing that gap is most of what activation means. It is also one of the oldest findings in usability research: people recognize far better than they recall.¹

Your product has an empty state everywhere a user’s own content will eventually sit: the empty report, the team page before anyone is invited, the activity feed on day one, the integrations list, a search that found nothing. One of them got designed, and it is the screen a brand-new user sees, because somebody worried about it before launch. The others cost you more. Someone hits them on day three, after putting in real work, and a blank screen at that point reads like a verdict on it.

What is empty state design?

Empty state design is what a product shows in the space where a user’s own content will eventually go. Design teams treat it as a visual problem. It is a decision problem. A user in front of a blank screen has three silent questions: what goes here, why would I want it, and what do I do right now. Answer none of them and you get an illustration above the words “Nothing here yet.”

Four ways to fill the space

In-product tutorials carry a condition the other approaches do not. Tutorial content placed inside a real document has to be deletable in one action, without a dialog. Someone who already knows what they are doing needs it gone, and a tutorial that resists removal converts from help into an obstacle at exactly the moment the user became competent.

Notion’s template gallery listed more than 30,000 templates, filed under categories that name jobs rather than features: 23,900 under personal productivity, 5,137 under study planner, 2,971 under student planner.² Notion did not make most of them. Creators built them, put their own names and faces on the cards, and Notion sorted them by the thing a person is trying to get done.

Notion treats that gallery as part of the product, not a help page. A good template is the documentation: it teaches one thing by doing it on a real problem, which beats a tour. The same collection also does a second job, because it is the surface strangers arrive on from search.

The sample-data trap

Sample data, meaning a working example the user can open and poke at, does the most for a user who cannot picture the product yet. It also fails in two ways the others do not.

The user’s first real action becomes deletion. Fill a new workspace with demo content and the first thing the user does is clear it out to make room for their own. That is a bad first action and an avoidable one: samples work better sitting beside the space the user is meant to fill than inside it, as a thing to open and examine rather than a mess to tidy.

A populated screen can hide the fact that nothing happened. A dashboard full of demo numbers looks like a working product, so the user feels informed while having achieved nothing, and your activation metric may agree with them. If someone can spend ten minutes in your product and leave with nothing of their own saved, the samples did the opposite of their job.

Empty state rules, from IBM and GitHub

IBM and GitHub each publish a public rulebook for how their own products should look and behave. IBM’s is Carbon, GitHub’s is Primer, and both write down what an empty screen has to contain.³ They were written independently, by companies that run their own products on them, so where the two agree is about as close to a settled rule as this subject gets. Where they disagree is worth knowing about too.

The gaps in that table are as useful as the matches. Both cap you at one action, so a screen offering three is a screen nobody agreed to. Neither says the picture is the point. And on the title, Carbon has a rule and GitHub does not, which tells you it is a judgment call, not a settled standard.

Point at the real button instead of drawing a new one

Carbon lists a third option for the main action. Rather than putting a button in the empty state, direct the user to the control they will use every time afterwards: “This has the benefit of teaching the user where elements are and how they will perform tasks in the future.” A button in an empty state disappears once the space fills. The toolbar does not.

The empty screen that is good news

Carbon and Primer both sort empty states by why the space is empty, and the reason changes what you are allowed to ask for. Carbon names three causes: no data yet, a user action such as a search returning nothing, and an error. Primer names the same three in its own words: the feature has not been used, the feature is “temporarily empty because of the nature of the feature,” or something went wrong.

The third state is the one product teams get wrong, because everything above assumes an empty screen is a problem to solve. Sometimes it is a result. Carbon’s example is alerts: “if your user has configured alerts and nothing has been triggered, it’s not a case of alerts not being set up but that there is nothing that requires the user’s attention. In this case, supplementary text is not necessary.”

An inbox at zero, a monitoring dashboard with nothing firing, a queue with nothing waiting: those users have succeeded. Prompting them to act reads as a product that cannot tell the difference between a new account and a clean one.

What should an empty SaaS dashboard show?

A dashboard is empty for three different reasons and each one wants a different screen. Nothing is connected yet, which wants one action: connect a source. Something is connected but has not produced data yet, which wants a line saying when to come back, because the user has done their part and the product has not. A filter or a date range is excluding everything, which wants the filter named and one click to clear it.

The rule specific to dashboards, and it is the opposite of the advice above: never fill the charts with fake numbers. Everywhere else, sample data helps. A dashboard is the one surface where a plausible chart is indistinguishable from a real one, so the demo version teaches the user nothing and hides the fact that nothing has happened yet.

And a dashboard sitting at zero because everything is healthy is not an empty state to fix. That is the good-news case above, and prompting on it is worse than leaving it alone.

What to fix first

Screenshot every empty screen in the product, then sort the list by how deep into it each screen sits. It will be longer than you expect, and the neglected ones cluster at the bottom. The people who reach those are still trying, which is more than you can say for anyone who left on the first screen.

For each one, write the first action as a specific sentence and check it against the win you named. Not “add data” but “create your first project” or “import your contacts from a CSV”, one action per screen, with a reason attached.

Fix the deepest screen first. Most analytics will not give you an exit rate per empty state, because the empty and full versions usually share a URL, so depth is the ordering you actually have. The first-run screen has usually had somebody’s attention already; the ones behind it never have. Give people something to duplicate while you are there, since even three good templates beat a blank canvas and double as the fastest product education you will ever ship. And check that each prompt knows when to leave: anything still asking for an action the user has already taken is telling them the product is not paying attention.

Some users will not act however good the screen is, and the blank space is rarely the reason. The action itself is irreversible outside your product. A real charge, a real message to a real phone, a real deploy. That is a different blocker with a different fix, which is a place to experiment where nothing counts.

Updated August 2026