Overview
Empty states present a basic but unique opportunity to support and enhance the user experience by providing useful information and direction. For example, empty states can be used to inform the user about what data would be displayed if it were available, as well as to guide the user about what steps to take next. Empty states can be particularly helpful when unexpected errors come up.
Users are generally familiar with the basic empty state that communicates what data is missing from a page. But there are also other functions for empty states that deserve their own distinctive approach.
The empty states pattern covers the following functions:
- Basic empty state for when there is no data, user action confirmations, and error empty states
- Starter content for first-use states to provide pre-created samples
- Teasing pages for first-use empty states, including in-line documentation and in-app promotion
Basic empty state
The basic empty state is the most common type in the Emplifi platform. We differentiate several types of basic empty states.
Basic empty state by usage
- No data empty states
- User action empty states
- Error empty states
Basic empty state by attention level
- High attention
- Low attention
Empty state by usage
No data empty states
No data empty states are the most common basic empty states used to explain what data is missing from the page and to communicate which steps the user can take to populate the page with data when using it for the first time.

User action empty states
User action empty states are displayed after a user has taken an action.
Examples:
- A message indicating that no search results were found
- A message informing the user that there are no issues to address


A message showing there are no search results
Always explain why the message is being displayed and offer guidance to help the user take the next productive step. For instance, suggest adjusting the keywords or filters if no search results have been found.
A message informing the user that there are no issues to address
In situations with no issues to address and no next steps to take, try to think about what other information could be useful for the user.
You may decide that a supplementary text isn't necessary. For example, if the user has set up queues and no complaint has been received, it’s not a case of queues not being set up but that there is nothing that requires the user’s attention. In this case, there's no need to add supplementary text.
Error empty states
Empty states may also occur when data is present but can't be accessed by the user. In these situations, it's useful to provide the user with more specific information to explain the situation and help them solve the issue smoothly.
Here are some error situations that may be addressed with the basic empty state:
Error |
Explain the situation |
Provide the solution |
---|---|---|
No permission
|
The user doesn't have permission to access the data |
Suggest how the user can request access and show who can provide it |
System problem
|
A problem with the feature's system is stopping the data from being accessed. |
Guide the user about what steps they can take to learn more about the given problem. |
Configuration issues
|
A change of configuration may be needed to be able to access the data |
Explain the first step the user can take to achieve the required configuration |
Action not possible
|
The app does not support the user's actions. For example, the file size is too large to upload. |
Explain what the user can do to overcome the problem. For example, suggest reducing the file to a certain size before re-uploading. |

An error empty state for a system problem
Always support the user by explaining why there is no data, as well as what the user can do to overcome the inaccessible or missing data or explain what conditions are needed for the data to become accessible.
Empty state by attention
High-attention
Use high-attention empty states in cases where the design needs to grab the user's attention, such as if the whole platform is down or an essential part of the feature has no data. The high-attention empty state should be designed with enough space around it so that it is instantly visible to the user.
High-attention empty states involve a Complex illustration with a headline and explanation. Except in some cases, there should also be at least one action to help users with the next step.

Low-attention
Use low-attention empty states in cases where there is already one high-attention empty state in space or if the size of the area without data is too small for a high-attention empty state design.
Low-attention empty states involve a Simple illustration supported by a headline and, in some cases, an explanation.

Best practices
- A page should contain only one high-attention empty state, and it should represent the main data area for that page.
- The number of low-attention empty states per page is unlimited
- If all data areas on the page are empty, we recommend using just one empty state for the whole page. The exception is the dashboard, where we want to show an empty state for each widget.
Starter content
Another way to approach a space is to populate it with pre-created content and sample data to help a new user become familiar with a feature.
This starter content offers users a practical chance to learn about the feature and review and delete content without any issues. We recommend personalizing starter content to create the best user experience possible.
When someone feels like she can explore an interface and not suffer dire consequences, she’s likely to learn more—and feel more positive about it—than someone who doesn’t explore. Good software allows people to try something unfamiliar, back out, and try something else, all without stress.
-Jenifer Tidwell, Designing Interfaces, (O’Reilly Media, 2011), 9.

Example of starter content in Content Collections
Aspects to consider for starter content
- Planning starter content needs to involve the full product team to establish the most helpful processes and configurations from the user's perspective.
- When allowing the user to delete starter content, make sure you have a backup basic empty state to display in case the content is removed.
Teasing pages
The teasing page is used to promote whole categories or applications within the app, with the goal of convincing the user to try them. It is most helpful when a primary feature is first introduced in the app by providing more detail and highlighting any benefits of the feature. Including an image may help further trigger interest and usage.
We differentiate two types of teasing pages depending on their purpose:
The teasing page should provide a detailed overview of the inaccessible page so the user understands more about the feature and at least one call-to-action to encourage the user to get started.
Considerations for teasing pages
- If testing results show that users don't understand the feature or concept, providing informative details about the feature may encourage usage.
- Teasing pages may require a higher level of maintenance than a basic empty state if using product images, as images will need to be kept up-to-date over time.
- Keep the content limited to one feature. Don't talk about other areas of the app. If there are multiple actions a user could take, pick the most important one and stay focused on that.
Promotion teasing page
When a feature is not fully included in the account solution but users can request it, use the promotion teasing page. This type of teasing page can market the main application or category to the user by highlighting its main benefits.

The main call-to-action is presented within the request button. A secondary link button can support it to learn more information about the feature, for instance, to the relevant knowledge base page.
First-use page
Use the first-use page when the whole feature is a part of the account solution, but the user has not yet created or added any content. The first-use page appears only once. In case users add and later remove all data, we show no data in an empty state.

The main call-to-action is presented within the primary button. A secondary link button can support it to learn more information about the feature, for instance, to the relevant knowledge base page.
References
- Jakob Nielsen, Error Message Guidelines (Nielsen Norman Group, 2001)
- Jakob Nielsen and Page Labuheimer, Top 10 Application-Design Mistakes (Nielsen Norman Group, 2019)
- Kathryn Whitenton, 3 Guidelines for Search Engine “No Results” Pages (Nielsen Norman Group, 2014)