Empty States: The First Blank Screen Also Needs Design
An empty state is the screen shown when there is no data. Learn the types (first use, no results, no data yet), what to say, and which action to offer.
What is it, and why design it?
Carbon describes empty states as situations that occur when there is no data to display, often during first-time use or when content has been deleted or is unavailable (Carbon: Empty states pattern). In other words, it is a normal state of the product, not an error.
A common problem is designing the screen with data and leaving the blank state for the end. The result is a table with no rows, headers that explain nothing, and no button. For someone arriving for the first time, that screen is the first thing they see of the product. That is why it helps to treat the first blank screen as part of onboarding: it is the moment the person learns what the product does and what to do to start, without reading a manual.
A well-designed blank state also keeps people from thinking something broke. If there is no data, it says so; if a search found nothing, it says so and offers a way to change the criteria.
What types of blank state exist?
Carbon groups basic empty states into three categories that are worth distinguishing in the design:
| Type | When it appears | What it needs |
|---|---|---|
| No data (first use) | The account is new and has no content yet | Explain what will appear and how to create it |
| User action | A search with no results, or a finished task | Confirm, and offer to change the filter or go back |
| Error management | Permissions, a system failure, or pending configuration | A way out, without dead ends |
Carbon also mentions alternatives for first use: in-line documentation, onboarding, and starter content. Do not confuse the first-use state with the no-results state. The first invites people to start; the second suggests adjusting the search.
What should it communicate?
NN/g offers three practical guidelines (NN/g: Designing Empty States in Complex Applications):
- Communicate system status. A blank panel leaves users unsure whether it is still loading, has failed, or has nothing. A message such as “There are no records to display for the selected date range” removes that doubt.
- Provide learning cues. Explain what the area will show and how to fill it. The article says this approach is generally more successful than forced tutorials at first use.
- Provide direct pathways. A “Create” button or a link to documentation takes the user straight to the task that fills the space.
The same article says that a totally empty state causes confusion about whether the system is working and ultimately decreases user confidence.
How should you write the message?
Carbon suggests writing the title as a positive statement. Its example: “Start by adding data assets,” rather than “You don’t have any data assets.” It also asks you to keep words to a minimum, avoid product-specific terms the person may not know yet, and not cover several options in one state: if there are several possible actions, pick the most important one.
This connects directly to the microcopy in your interface: in an empty state, every word competes with the space that should guide the person. If the message is an error, also review how to write error messages.
When should you use an illustration?
Carbon treats it as optional and recommends that it relate to the situation. If space is limited, use text only. A pretty drawing that explains nothing just takes up room. And if the blank screen belongs to a search, you may need search UX more than an empty state, because the problem is not missing content but missing a path to find it.
Example
Illustrative example: a project management app shows a blank project list with the word “Empty.” In the redesign, the title becomes “Create your first project to see your tasks here,” with a primary “New project” button and a secondary link to a short guide. If the user filters by a client who has no projects, the message changes to “No projects match this client,” with a “Clear filter” button. These are two different blanks with two different actions.
Carbon adds a layout detail: the empty state replaces the element that would ordinarily show. For an empty table, it replaces the whole table, including its column headers and footer, so screen readers do not read out an empty table before the message.
Common mistakes
- Showing an empty table with headers and no explanation.
- Using the same screen for “first use” and “no results.”
- Putting three primary buttons in the same state.
- Making the user feel they broke something when there is simply no data yet.
- Leaving an error screen without a way out: a dead end is worse than a blank.
- Adding an illustration that has nothing to do with the task.
What you can do tomorrow
- Walk through your product with a new account and note every screen that appears blank.
- For each one, write the title as a positive statement and choose one primary action.
- Separate the first-use state from the no-results state in your design, even if they share a component for now.