Usage
An empty state refers to when the UI has no data or information to display to the user. They are a simple way to keep a user informed, supported, and on a productive path. They provide opportunities to communicate what the user would see if they had data, while providing guidance when things aren’t working as expected.
A well-designed empty state can improve the user experience and reduce confusion by setting clear expectations for what the user should do next. Here are a few characteristics that make a well-designed empty state:
- Clearly tell the user what information is missing, why it's missing, and what they can do next. Use an empathetic tone to guide and reassure the user.
- se iconography to help to convey the message and create a more engaging experience. Use icons that are relevant to the context of the interface.
- If applicable, give users a direct pathway to move out of the empty state. Never lead users to dead ends.
- Include calls-to-action that encourage users to take action, such as adding their first item. Limit the number of possible actions, so that it's easier for users to make a decision on their next step.
- If applicable, include links to help documentation or other resources that can assist the user in populating the view.
This pattern explores the following types, when empty states are shown in different use cases:
Types of empty states
Empty states differ depending on the use case.
| Type | Use cases | User goals | When to use |
|---|---|---|---|
| First use |
|
| When the user has to take action to populate a screen or component with data |
| User action |
|
| When you need to provide feedback to the user based on an interaction |
| System errors |
|
| When something has gone wrong or needs troubleshooting, and requires specific details to support the user |
Do
- Use basic empty states for less complex situations or secondary featuresLet users know what to expect when data is available in the space
- Use clear, concise, and precise language so that users can quickly make informed decisions
- If next steps or corrective actions are possible, provide direct links or primary action buttons
- If users can take multiple actions, create a clear hierarchy to indicate which option is the primary action or guide users into taking action
- For empty states caused by errors, work with your dev team to find out what information can be made available to the user and use appropriate language (Link "appropriate language" to the Error handling page)
Don’t
- If multiple actions are possible, don't give them the same priority
- Avoid product-specific terms and jargon that users might not have encountered yet
- Don't include content about other areas of the app
- Don't use comical, whimsical, or flippant language
- Don't lead users to a dead end
- Don't use codes or technical system language for errors
Types
First use
When users open an area of an app for the first time, they might not have data yet.
- Display an empty screen that explains what the area of the app will show when it's populated with data
- Guide users into taking steps to populate the space
- If applicable, encourage users to personalize their view with information that they find useful
Place first-use empty states in the location where the data is presented. Make sure that they are prominently located, so that users can easily find and understand them.
User action
Sometimes, users take an action that doesn't return any results. For example:
- When the user's search or filter criteria don't have any matches
- When users clear data themselves
No search or filter results
When a user searches for a product or item and there are no results to display.
This can result from an incorrect search due to misspellings or through the application of filters, or from the result simply not existing in the catalog. In addition to telling the user that their search has no results, recommend they adjust their search or filters and check their spelling.
There may be situations where next steps are not possible or supplementary text is not required, so use your judgment about what is useful to include.
User cleared
A success confirmation for completion of a process or set of tasks.
It may not need to alert users to do anything more, simply let users know that they’ve completed their tasks with a success message.
System errors
When an error prevents the system from returning any data.
Error management empty states are displayed when there has been an error that prevents the content from loading or displaying correctly. These are designed to provide feedback to the user when an error occurs.
Provide guidance about why there is no data, and either what the user can do to address the lack of data, or the circumstances under which the data would appear. This can include error messages or prompts that guide the user through the error and provide possible solutions or next steps.
The goal of an error empty state is to help the user understand what went wrong and how to resolve the issue. For more detailed information about writing error messages, see the error handling pattern.
Use cases:
- Permissions issue
- System issue
- Action not supported
Permissions issue
Errors generated when the user does not have access to a resource or permission to view the data.
In this use case, it’s important to suggest next steps or guide the user in the process to request access.
System issue
Problems with a related system are preventing the data from being supplied.
Explain steps the user can take to learn what has happened or to go back.
Action not supported
For errors generated by a user's action, an inline notification may be used to compliment the empty state. This provides feedback to the user associating that the empty state was caused by, and resolved by, the user's action.
For example, the user attempts to upload an unsupported file type. Explain what file types are supported.
Anatomy
- Image area (optional): Non interactive. Helps users understand their situation, such as a network error, refresh, and location.
- Title area (optional): A short and concise explanation to ensure that users can quickly understand their situation. Where possible, write this as a positive statement.
- Description area: Briefly describe the next expected behavior of the user. If the situation can be briefly described in one paragraph, omit the title and provide only the description.
- Primary action (optional): A button or link that prompts actions users can perform in an empty state.
- Secondary action (optional): If there is a secondary action, such as referencing documentation for further reading, include it as a link below the copy.
Alignment
All the elements of the anatomy are center-aligned by default.
Center the content
Don’t align the elements to the left
Placement
Empty states always appear in the empty space, in the context of the data that’s missing. They can occur anywhere your app can display data, including but not limited to tabs content, data tables, cards, full pages, and side sheets.
The goal of the empty state is to guide the user and help them understand what they can do to populate the interface. So, it's important to place it in a location that is visible, intuitive, and contextually appropriate, based on the page layout and context.
Common placements for empty states are:
- In the center of the interface
Center the empty state horizontally within the UI to ensure the empty state is the focal point of the UI. The exact positioning of the empty state can depend on the specific UI design and layout. If there are other elements in the content area, the empty state may need to be adjusted slightly to ensure it is still centered within the available space. - In the center of the content area*
Sometimes, it makes sense to place the empty state within the content area itself. For example, if the interface is displaying a list of cards to configure, the empty state can be a message that appears inside each card.
*Exception
When only the description text is showing, it can be placed in the top left of the content area.
