Empty states

Empty states arise in situations where there is no data to display in a section of a digital product. Users often encounter empty states when interacting with a product or page for the first time, as well as in cases where data isn't available or has been removed.

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.

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

When crafting text for an empty state, it's essential to consider the specific context. Each function deserves its own distinctive approach.

General aspects of empty states copy to keep in mind:

  • Clarity is a must; inform about what happened and how to resolve it
  • No technical language; no APIs, servers, backends, tokens and so on
  • Keep it short and sweet
  • A positive empty state can be humorous or playful. But always consider the context; if the situation might be frustrating, there’s no place for jokes.
  • If the empty state is shown often, skip the jokes as well - a repeated joke stops being funny after some time.

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

No data empty states can be an opportunity to teach the user about how the app works, while user action and error empty states may present a chance to put a positive spin on the user's potential frustration.

Basic empty state by usage

No data empty states

These are the most common first-use 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.

Tone of voice:

  • Conversational; remember to sound human
  • Positive, but not overly enthusiastic; use exclamation marks sparingly
  • Helpful; include facts about what data will populate the page and, if relevant, explain what next steps the user can take to do so



No data empty state

We generally use exclamation marks only when encouraging the user to take the first step to populate the page for the first time.


No data empty state

In situations where there are 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 a supplementary text.

In other cases where the user can take a simple action to populate the page with data, you may decide to include a header and a button with a call-to-action without a supplementary text.


No data empty state

User action empty states

User action empty states are displayed after a user has taken an action, for example:

  • A message indicating that no search results were found
  • A message informing the user that there are no issues to address

Tone of voice:

User action empty states may be frustrating for users. This is an opportunity to display copy that shows empathy with the user's experience. Use a friendly and supportive tone of voice in these instances.

Always explain to the user why the message is being displayed and offer guidance to help the user take the next productive step. For instance, if no search results have been found, suggest adjusting the keywords or filters.


User action empty state

Error empty states

Empty states may also come up when data is there but can't be accessed by the user. In these situations, it's useful to support the user with more specific information that can both explain the situation and help them smoothly solve the issue.

Here are some error situations that may be addressed with the basic empty state:


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 is able to 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 user's action is not supported by the app. For example, the file size is too large to be uploaded.

Explain what the user can do to overcome the problem. For example, suggest reducing the file to a certain size before reuploading.



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.


Error empty state

Starter content

Another way of approaching an empty space is to populate it with pre-created content and sample data, so as to help a new user become familiar with a feature.

This type of starter content offers users the practical chance to learn about the feature, as well as to review and delete content without any issue.

Starter content should be entirely personalized according to the individual feature. For example, if demonstrating starter Publishing content, you can create a fictional social media post showing how features can be incorporated including a sample image and accompanying text.


Starter content

Planning starter content needs to involve the full product team, in order to establish the most helpful processes and configurations from the user's perspective.

Teasing pages

The teasing page is used to promote whole categories or applications to the user within the app, with the goal of convincing the user to try them.

They are most helpful when a primary feature is first introduced in the app, by providing more detail and highlighting any benefits about the feature. Including an image may help further trigger interest and usage.

We differentiate two types of teasing pages depending on their purpose:

  1. Promotion teasing page
  2. First-use teasing page

In both cases, 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 detail about the feature may encourage usage
  • Keep in mind that easing 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

Promotion teasing page

When a feature is not fully included in the account solution but users are able to request it, we use the promotion teasing page. This type of teasing page can be used to market the main application or category to the user by highlighting its main benefits.

General tips for promotion teasing pages:

For the main header, pick the single most important benefit of the feature stay focused on that.

Make sure that all headers, sub-headers and buttons include calls-to-action that demonstrate how the user can practically benefit from the feature

Add at least three bullet-points to highlight the main features, focusing on the diverse benefits. Use language that will trigger interest and encourage the user to try it, including action verbs, positive language and/or statistics about the unique feature.

Employ technical terminology when relevant, but always tie it back to the practical benefit for the user. For example, if the feature uses AI for chatbot automation, focus on the benefit of more efficient customer agent workflows.


Promotion teasing page

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, we use the first-use teasing page. The first-use teasing page appears only once. In case users add and later remove all data, we show the no data empty state.

First-use pages have a similar look and feel to the promotions teasing page, but the text focuses less on highlighting the benefits and more on explaining how the user can get started with the feature.

For example, instead of using calls-to-action in every header, you can base the sub-headers on the names of the feature categories and use the bullet-points to define each one.


First-use teasing page