An empty state is the screen a user sees when there is nothing to show yet. Good empty state design tells them what belongs there, why it is empty, and gives them one clear action to fill it. For a new trial user, that screen is often the first thing they see after signup, which makes it part of your first-run experience, not a leftover.
This guide covers the types of empty states a SaaS product needs, the parts of a well-built one, examples from shipped products, and the mistakes that quietly cost activation.
TL;DR
- An empty state is a designed response to a container with no content. It should explain the situation and point to the next step.
- Cover at least four situations: first use, user-cleared or completed work, no search results, and errors. Each needs different words and a different action.
- Use a short headline, one line of explanation, and a primary button whose label says exactly what the user gets.
- In a first-run flow, put the action inside the empty state and show what the screen looks like when filled.
- Never ship a totally blank screen, and never let a no-records message appear while data is still loading.
Table of Contents
- What an empty state is, and why it matters
- The types of empty states to design for
- The anatomy of a good empty state
- Using empty states in the first-run experience
- Empty state examples worth studying
- Mistakes that cost activation
- Our perspective
- A review checklist for your own product
- Want us to look at your trial?
- FAQ
- Sources
What an empty state is, and why it matters
An empty state appears when a view has no data to display, and it describes what the user can do next. Atlassian's design guidance notes that it can fill a whole page or sit inside a panel, table or other container. Carbon Design System adds that it can occur anywhere an app displays data: dashboards, data tables, tiles, full pages and side panels.
The Nielsen Norman Group treats empty states as designed responses for content-less containers. In their framing, they do three jobs: communicate system status, support learnability, and give users direct paths to key tasks. That is a useful way to see them. An empty state is not blank space waiting for data. It is a screen with a job.
For a SaaS trial, the stakes are concrete. A new user lands on an empty dashboard, an empty project list or an empty inbox. If that screen says nothing, they have to guess what to do. If it says the right thing, they take the first step toward a result. We cover the wider picture in our guide to onboarding flow examples that get users to a first result.
The types of empty states to design for
Most teams design one empty state, the first-use screen, and forget the rest. Carbon's guidance says to account for first use or no data yet, user-cleared or completed work, no results from search or filters, and error states such as permissions, configuration, system or loading problems. These have different causes, so they need different explanations, tone and actions. Moodle's product-writing guidance draws the same split between first use, user-emptied and no-results states.
| Type | Why it is empty | What the user needs | Tone |
|---|---|---|---|
| First use | Nothing created yet | What will appear here and how to start | Encouraging, specific |
| User-cleared or completed | The user finished or deleted everything | Confirmation, and a way forward if one exists | Short, positive |
| No results | A search or filter matched nothing | Why, and how to recover | Neutral, helpful |
| Error | Permissions, setup or system problem | What went wrong and who can fix it | Calm, direct |
First use
This is the state that matters most in a trial. The user has done nothing wrong; they just have not started. Tell them what will live here and give them the shortest path to creating it.
Cleared or completed
Carbon recommends that for user-action states you give feedback about the action, and for completion you tell users they finished the process successfully. A cleared task list does not need an illustration parade. One kind line is enough.
No results
Here the interface should explain why nothing matched and offer recovery, such as adjusting search terms, clearing filters or browsing all content. A bare "No results found" leaves the user stuck.
Errors
Permission and configuration states look like empty states but are not about missing data. Say what is blocked and who can unblock it. Do not use the first-use voice here.
The anatomy of a good empty state
The pattern is consistent across mature design systems. Atlassian's component includes an optional illustration, a concise header, an optional description and optional buttons for next steps or dismissal. PatternFly lists icon, heading, body, a primary button and optional secondary buttons as the main elements, and recommends a short message plus next steps. Carbon's older pattern documentation adds that starter content can save users time learning and configuring complex setups.
Put together, a reliable build looks like this:
- Headline. Say what this area is or what is missing, in a few words.
- Body. One or two sentences on what will appear and how to populate it.
- Primary action. One button for the task that fills the screen.
- Secondary action. Optional: a learning link, a template library, or a way to import existing data.
- Illustration. Optional, and never the only carrier of the message.
If you are choosing how to lay out the heading, explanation, visual and actions, AI customer experience work is worth a look when your empty states are generated or personalized by an assistant rather than written by hand.
Write the copy in a fixed order
Write the headline, then the body, then the button label. A button is a promise, so Moodle advises that CTA labels state exactly what the user will get by clicking them. "Create your first report" beats "Get started". Moodle also recommends clear, concise, friendly language.

A quick test: cover everything but the headline and body. Can a stranger answer what this screen is, why it is empty, and what to do now? If not, rewrite.
Using empty states in the first-run experience
A first-run experience is everything between signup and the first moment the product works for the user. Empty states are its most natural surface, because the user is already looking at the place where their result will appear.
The NN/g guidance is to use empty states to give contextual help when a task begins, with brief, explicit instructions or a direct link to the steps needed. Two tactics follow from that.
Put the action in the screen
Do not send the user to a tour, then a help center, then back. Smashing Magazine argues that a screen that is empty by default and needs steps to populate is well suited to onboarding. Its advice is to show what the screen will look like filled, or tell users with clear instructions, and to drive an action rather than only explain a benefit.
Show what good looks like
Users rarely know what a finished project looks like in your tool. A preview, a sample record or a template removes the imagining. Starter content is especially useful where setup is long, which is the pattern we see in trials where people leave before the first result. Our product onboarding checklist lays out how to sequence that path from signup to first result.
If your empty states teach features, make sure the teaching ends in doing. Work on why onboarding fails usually comes back to the same cause: users were told about the product but never asked to use it at the moment they were looking at the relevant screen.
Match the help to the user
Not everyone wants the same thing on an empty screen. Some want a template, others want an explanation first. If you can tell which kind of user you have from signup answers, adapt the primary action. If you cannot, offer a template as the primary button and a learning link as the secondary.
Empty state examples worth studying
Examples are useful when you look at the decision behind them, not the artwork.
Slack. In LogRocket's review, Slack's onboarding used playful illustrations, embedded guides, lightweight prompts such as "say hi to yourself," and templates highlighting common use cases. The lesson: the first action is tiny and safe, so the user can take it immediately.
Facebook Messenger. UXPin describes its first-use screen as having a prominent, plain-language CTA with an illustration meant to encourage engagement. The lesson: one obvious button, in everyday words.
Salesforce. A designer's case study of an empty-state audit reports more than 400 empty states, including multiple versions of "No Access." The proposed response was a shared library of common patterns, with a common anatomy of illustration, message and CTA. The lesson: at scale, empty states need a system, or the same situation gets five different explanations.
The same case study says the CTA should communicate the user's next best action. That is the question to ask of every example you collect: what does this screen want me to do next, and is that the right thing?
For more teardown-style learning, see our product teardown examples and the B2B SaaS onboarding case studies.

Mistakes that cost activation
The totally blank screen
NN/g advises against a totally blank state because users cannot tell whether the interface is loading, broken or simply empty. Even one line of text is better than nothing.
"No records" while data is still loading
Showing an empty message before content arrives tells the user something false. Show a progress indicator while a process runs. When processing finishes with nothing to show, use a brief status message instead.
Instructions with no path
A sentence that names an action but does not link to where to do it makes the user hunt. If the copy says "add a teammate," the button should add a teammate.
Illustration doing the talking
Moodle warns that illustrations should add value but must not carry the message alone, and that essential imagery needs alternative text. Delight comes second to comprehension.
Filters on a page with nothing to filter
PatternFly advises against placing toolbars or filters in a full-page empty state when there are no items to search or filter. Controls with nothing to act on add noise.
One message for every situation
A first-use state that says "Nothing here yet" is fine. The same words on a permissions block or a failed search are not. Match the copy to the type.
Our perspective
When we go through a trial as a buyer, with a stopwatch and a screenshot of every step, the empty state is often where the clock tells the story. The user has signed up, they are staring at a blank dashboard, and nothing on screen says what the first win is.
We treat that screen as the start of the path to paid, not as a design asset. The question we ask is simple: does this empty state move someone toward the first result, or does it ask them to figure it out? Setup that comes before value, and upgrade prompts that land before a win, usually begin here.
Our approach is to tie each change to documented user behavior. That means mapping where people drop off between signup and payment, then deciding which empty states to fix first, and what the primary action in each should be. We would rather fix three empty states that sit on the path to the first result than polish thirty that do not.
If your sign-ups are healthy but your trials do not convert, look at your empty states before you look at your pricing page.
Edijs
A review checklist for your own product
Use this list in a design review. Each line maps to guidance above.
- Inventory every place the product can show no data, not only the first-use screen.
- Label each as first use, cleared, no results or error.
- Check that no state is totally blank, and that loading never shows as empty.
- Confirm each state answers three questions: what is this, why is it empty, what do I do now.
- Confirm there is one primary action with a label that names the outcome.
- Check the screens that sit on the path to the first result before the rest.
- Confirm essential imagery has alternative text and the text carries the message.
- Remove filters and toolbars from full-page empty states.
Then watch real users meet these screens. Our guide to in-app usability testing shows how to do that without a large research budget. If an AI assistant guides users from the empty screen, see how to build an AI onboarding assistant that supports the first result rather than interrupting it.
Want us to look at your trial?
If your empty states sit on a path where trial users leave before the first result, we can find where. Our Trial to paid service goes through your trial as a buyer, maps the drop-off between signup and payment, and shows what to fix first and why.

You can start with a free trial teardown, or see the work behind it, including how we rebuilt the setup flow at Supliful.
FAQ
What is an empty state in UX?
It is a screen or container that appears when there is no data to display, such as a new account, a cleared list or a search with no matches. A good one explains the situation and offers a next step, as described by Atlassian's design system.
What should an empty state include?
A concise headline, a short explanation of what will appear and how to fill it, and a primary button for the related task. An illustration and a secondary action are optional. PatternFly lists icon, heading, body and buttons as the main elements.
How do empty states help a first-run experience?
They put help and action where the user is already looking. NN/g recommends giving contextual help when a task begins, with brief instructions or a direct link to the steps. That shortens the path to the first result.
What are the types of empty states?
First use, user-cleared or completed, no results from search or filters, and error states. Carbon says each needs its own explanation, tone and action because the causes differ.
Sources
- Empty state usage, Atlassian Design
- Empty states, Carbon Design System
- Empty states pattern, Carbon Design System v10
- Designing Empty States in Complex Applications, Nielsen Norman Group
- Empty states, Moodle Developer Resources
- Empty state design guidelines, PatternFly
- The Role Of Empty States In User Onboarding, Smashing Magazine
- Empty states in UX done right, LogRocket
- Designing the Overlooked Empty States, UXPin
- Salesforce Empty States, Yijing Zhang
- Why onboarding fails
- AI customer experience
