Common empty state use cases include:

• “Day 0” use cases when a user first starts using an application
• When the user completes an action that returns no results
• When an error prevents the system from returning any data
  • 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.

It is our responsibility as designers to provide our users with clear, concise guidance on why the data isn’t present and how to move forward in their journey.

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:

1. Clear messaging: The empty state should have simple and clear messaging that tells the user what information is missing, why it is missing, and what they can do next to access the information. Follow the voice and tone guidance within the design system to remain clear and empathetic to the user.
2. Visual cues: The empty state should use iconography to help convey the message and create a more engaging user experience. The icon should be relevant to the context of the interface and help the user understand why it's empty.
3. Guidance: The empty state should provide guidance and a direct pathway out of the empty state when applicable. Avoid leading the user to a dead end.
4. Calls-to-action: The empty state should include calls-to-action that encourage the user to take action, such as creating their first resource or adding their first item.
5. Help or documentation links: The empty state may include links to help or documentation resources that can assist the user in populating the view with data or finding relevant information.

Although there are many diverse use cases for empty states within our solutions, we use a single component structure to ensure they are consistently applied across the complete user experience. Below describes the structure of an empty state component:

The placement of an empty state in a UI depends on the context and the type of content the interface is displaying.

However, some common placements for empty states are:

1. In the center of the interface
2. In the top left of the interface
3. Within the content area

Ultimately, 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.

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. For example, 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.

With left-aligned UIs, positioning an empty state on the top left could help draw the user's attention to the fact that there is no content available in that section. This is the most common placement within our cloud services.

Sometimes, it makes sense to place the empty state within the content area itself. For example, if the interface is displaying a list of items, the empty state can be a message that appears when there are no items in the list.

No data empty states are displayed when an application has no data to show for a particular view or section. The messaging and visual cues should convey that there is no data to display, while also providing guidance or calls-to-action that can help the user add data or find the information they need.

The best position for this type of empty state is typically the location where the data is presented, but always ensure they are in a prominent and clear location where users can easily find and understand them.

Action empty states provide feedback to the user that an action has been successfully completed or that no data has been returned as a result of that user action. These states can be used in various situations, such as:

1. After completing a task: When a user completes a task such as sending a message, submitting a form, or deleting an item, the user interface can display an action empty state to indicate that the task has been completed successfully and there are no further actions required at that moment.
2. After clearing notifications: When a user clears all notifications from their notification panel, an action empty state can be used to indicate that all notifications have been cleared and there are no further notifications to view or take action on.
3. When no results returned from a search: This can provide the user with clear feedback that the search has been completed and there are no matching results available, while also offering suggestions for alternative actions that they can take.

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. 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 management empty state is to help the user understand what went wrong and how to resolve the issue. Some considerations for writing error management empty states:

1. Consistent visual cues: these empty states typically use the “alert” status icon and “status warning” color. Only deviate from this standard if it is necessary for your context.
2. Appropriate tone: receiving errors can be frustrating to the user. Be sure to remain empathetic to the seriousness of the error, don’t pass blame to the user, and be clear about how they can resolve the issue.
3. Direct messaging: be clear about what impact the error may have on a user's work in a readable format. Only provide the information that is necessary to help the user fix the issue, and avoid unnecessary technical jargon.