An empty state appears when there is no data to display and describes what the user can do next. This can happen for a variety of reasons, such as when the user has not yet added any content, when the user has filtered the results so that there are no matches, or when there is a temporary error.
If an empty state is not designed well, it can confuse and frustrate users. On the other hand, a well-designed empty state can help users to understand why they are seeing the empty state and what they can do to fix the problem.
When to use empty states
Empty states occur for a variety of reasons and require different treatments.
Initial empty state: This empty state displays when an application is first opened by the user and has no content to display. This can be common when a user starts using your application.
User action empty states: These empty states are used to provide feedback to the user based on an action they have taken. For example, a no results empty state may be displayed when the user performs a search but no results are found. The goal of these empty states is to help the user understand what happened and what they can do next.
Error management empty states: These empty states are used to communicate errors to the user and provide instructions on how to resolve them. The goal of these empty states is to help the user fix the problem and get back to using the product.
These guidelines demonstrate best practices for using the neetoUI NoData component to develop empty states.
Anatomy of NoData component
Image
Title
Description
-
Actions
Image
Illustrations or icons can help to make empty states more visually appealing and engaging.
Image should:
Be non-interactive that relates to the situation (optional).
Title
This is a short, clear headline that explains why the user is seeing the empty state.
Titles should:
Be clear and concise. The title should be easy to read and understand.
Write in sentence case, capitalize the first word and proper nouns only.
Avoid articles (the, a, an) to keep content short and actionable.
Avoid using punctuation.
Description
Descriptions should add useful and relevant additional information.
Actions
Provide clear calls to action. Tell the user what they can do next, such as adding new data, searching for data, or refreshing the page.
Actions should:
Be clear and predictable: users should be able to anticipate what will happen when they click a button.
-
Scannable: avoid unnecessary words and articles such as “the,” “an,” or “a”.
Don't - The title and description are very general, and they do not provide any specific information about the type of data that the user is looking for. The CTA is empty, so it does not provide any guidance for the user on what to do next. This can be confusing for users who do not know what to do.
Do - The title clearly tells the user that there are no custom attributes to show, and the description provides a link to documentation on how to use custom attributes. This is helpful for users who are specifically looking for custom attributes. The CTA encourages the user to take action by adding new custom attributes. This is helpful for users who want to start using custom attributes.
First time user experiences
For first-time user experiences, use illustrations that can provide a visual cue and make the empty state more engaging and visually appealing. The title and description should educate the user in a simple and non-technical way.
Error states
Error states are screens that users see when something goes wrong. They can occur for a variety of reasons, such as a network error, a server error, or a user error.
