You are currently on Anvil1, which is now in maintenance mode. Visit Anvil2 to get the latest version of the design system.
patterns / null

Empty States

Empty States

Empty states are messages that appear whenever a page or element has no content to display to the user. An empty state is an opportunity to engage and delight users. The empty state should tell users what it’s for and why they’re seeing it. Effective empty states also tell users what they can do next.

Overview

Empty states can be employed to:

  • Make users aware that a feature is not configured for use.
  • Communicate that there is no data to display.
  • Act as a placeholder for regions in the app left blank intentionally.
  • Convey an error state, like a server response error, i.e., 404 or 500.
  • Display empty search results.
  • Help users onboard and encourage them to interact with the application
  • Prevent users from having to “back up” and go in a different direction

Headlines

Empty states headlines should be proactive and helpful. Focus on the task ahead that will help them fill the empty state, rather than calling out what’s missing from the screen. Calling out what’s missing can work in description text, but it’s always better to give information about the filled state of the screen.

Compared to Banners

Empty states differ from banners in that they are not intended to promote or advertise new features or functionality.

Compared to Introduction Screens

Empty states differ from introduction screens in the headline wording. They should give the user an instruction. Additionally, introduction screens will often be the first screen after launching a wizard, whereas an empty state would not likely be used in that scenario.

Types of Empty States

First Time Setup

During the initial onboarding process, the user will encounter a lot of empty states. We should try to make these empty states fun and encouraging with an approachable tone and helpful content so the user feels supported and confident through the set up process. Since these empty states will only be seen once or twice, they can be celebratory and decorative without being overkill.

Educate the User

Sometimes the purpose of the empty state is to teach the user how to fill it by explaining what to do next or using a CTA to link them to a walk-through. Once the user learns how to fill the screen, there’s a good chance it may not be empty again. If it is likely to be empty again, an additional Recurring Empty State may be needed.

  • Keep explanations concise. Any longer than 200 characters and/or 4 lines of text should be made into a help article or walk-through.
  • If linking to a help article or walk-through, be sure to prime the user on what each will entail.
  • Illustrations are encouraged. See Illustrations for more information on how to employ them.
  • Keep the tone friendly and encouraging.
Illustration + Headline + Explanation
Illustration + Headline + Explanation + CTA

Quick Setup

Sometimes the purpose of the empty state is to bring the user through a setup flow as quickly as possible. Once the user completes the setup flow, there’s a good chance the empty state will never show up again. If it is likely to be empty again, an additional Recurring Empty State may be needed.

  • Use a clear headline and CTA to initiate the setup flow.
  • Make sure to inform the user about what info/documents they need on hand to complete the setup.
  • Illustrations are encouraged.
  • Keep the tone friendly and encouraging.
Illustration + Headline + Explanation + CTA
Illustration + Headline + Description + Extra Info + CTA

Recurring Empty States

After setup has been completed, some screens/sections display empty states as a natural state of the screen/section or as an error message. Since these empty states can happen frequently, their main goal is to communicate information, and don’t need to be celebratory or decorative. Recurring empty states may or may not have a CTA, depending on whether the empty state is within the user’s control.

Communicate Functional Feedback

The purpose of some recurring empty states is to show functional feedback about the information on that screen. The functional feedback is usually neutral, but it can be positive or negative in some situations.

Neutral Functional Feedback

The most common type of recurring empty state feedback. If whether or not a user populates a screen/section is up to preference and/or doesn’t inhibit any workflows, neutral functional feedback is appropriate. In some instances, a positive empty state that occurs frequently may be displayed as “neutral” in order to tone it down visually.

Recommendations:

  • Keep feedback concise and direct.
  • If a CTA is applicable, use an in-line link.
  • Use grayscale / subdued text.
  • A grayscale icon may be used to increase understanding but is not required.
  • Do not use illustrations.
Description only
Icon + Description + In-line CTA
Negative Functional Feedback

Functional feedback is negative when workflows are inhibited by the empty state. The user may not be able to immediately move forward until the empty state is resolved, or the empty state could have potential negative impact on future workflows or processes. In these instances, the user should always have an explanation on what to do next, or an in-line CTA to help them resolve the empty state as quickly as possible.

  • Keep feedback concise and direct.
  • Must provide instructions or use a CTA that helps the user resolve the empty state.
  • Use grayscale / subdued text.
  • Must use a red icon that denotes warning or caution.
  • Do not use illustrations.
Icon + Description with Instructions
Icon + Description + In-line CTA
Positive Functional Feedback

If the empty state is the desired state for the screen/section, the functional feedback should be positive. Since the feedback is positive, it could be a celebratory moment and an illustration may be appropriate. On the other hand, some positive empty states that occurs frequently may be displayed as “neutral” in order to tone them down visually.

  • Keep feedback concise with an encouraging tone.
  • If a CTA is applicable, use an in-line link.
  • Use grayscale / subdued text.
  • A full color icon may be used to increase understanding but is not required.
  • An illustration may be used.
  • Can follow the appearance recommendations for Neutral Functional Feedback.
Icon + Description
Illustration + Description + In-line CTA

Empty States Outside of User's Control

Some empty states are caused by something outside of the user’s control. Something may be processing by ServiceTitan or a third-party vendor, or next steps may be dependent on a customer or another employee.

  • Be transparent about what the empty state is, who is responsible for resolving it, and when that resolution may occur.
  • Keep tone friendly and encouraging.
  • Follow appearance recommendations accordingly for a first time setup or a recurring empty state (positive or neutral feedback).
  • A full color or grayscale icon may be used to increase understanding but is not required.
  • An illustration may be used.
Illustration + Headline + Description with Explanation
Icon + Description with Explanation

Error Empty States

Error empty states may occur due to a server issue (like a 404 or 500 error), or the user’s internet access could be interrupted by a poor connection.

  • Be transparent about what the empty state is, who is responsible for resolving it, and when that resolution may occur.
  • Must provide instructions or use a CTA that helps the user resolve the empty state.
  • Follow appearance recommendations accordingly for a first time setup or a recurring empty state (positive or neutral feedback).
  • A full color or grayscale icon may be used to increase understanding but is not required.
  • An illustration may be used.
Illustration + Headline + Description with Explanation + CTAs
Icon + Description with Explanation

Additional Content

Starter Content

To help users new to an app or section, screens which would otherwise be empty can be populated with starter content. Starter content allows users to begin using an app right away, making it easier for them to learn about what an app has to offer.

  • Starter content is best for features that store content (such as Pricebook), or create templated content (such as Marketing Pro).
  • Use content that has broad appeal and demonstrates primary features.
  • Give users the ability to delete and replace starter content.
  • If possible, provide content that's personalized.

Educational Content

If the purpose of the screen isn't easily conveyed through an image and tagline, consider showing educational content instead. Educational content helps users understand what a feature will be able to do once it has content.

  • Make it possible to dismiss or skip this content.
  • Keep it brief.
  • Keep content contextual to the screen. This should not be a place to onboard the user to the entire app.

Best Match

On a search screen, if nothing exactly matches a user's query, content that contains the best match can be displayed by returning results for a query spelled slightly differently. By showing these results, the user may find what they're looking for.

Handling Empty States for Tables

Below are some best practice examples of handling empty states for tables.

First Time

A table with a first time empty state should not appear like a table. The table container can be replaced with a card containing the empty state. Any filters, tabs, and table headers should be hidden. Since the goal of a first time empty state is to show the user how to fill it, we should minimize cognitive load and direct their attention to one place.

A first time empty state for a table may also simply float on the page background instead of being contained in a card.

As a Card
Floating

Recurring

A table with a recurring empty state should show the table container, column header row with header names, and any filters. The row dividers should be removed and the content of the table should include only the empty state.