How to design an empty state

Decide which screens need an empty state at all

Not every screen has an empty state, and pretending otherwise adds work for nothing. A screen that has never held data and a screen whose data was filtered down to nothing are two different situations, and only the first one is usually worth a designed empty state. The second wants a no-results message with a way to change the filter.

Ask what the user would actually see if they arrived on this screen today. If the honest answer is a blank area, the screen needs an empty state. If the answer is a list of recent items, a default, or a sample, then the empty state is unnecessary and the screen only needs a normal layout.

A useful rule is that an empty state earns its place when the feature is new to the user and this screen is the main way to use it. Those are the screens people land on first, and the ones that make a new app feel broken.

• A screen that has never held data is a candidate
• A filtered list with no results is a different case
• If the screen would show recent items or a default, it does not need one

Note: An empty state is a designed screen, not a placeholder. If the screen would show something useful by default, designing an empty state for it adds a second layout for no benefit.

Say what the screen will hold once it has data

The empty state has one job, and it is to make the future visible. Tell the user what will be in this space: the kind of thing, roughly how much, and what it will look like. A screen that will hold saved articles should say that saved articles appear here, not that there is nothing here yet.

This is also where you fix the vocabulary. Whatever word the empty state uses for the content is the word the rest of the product should use, and using it here is how a user learns the word before they see any data at all.

• Name the kind of thing that will appear
• Give a sense of quantity, such as three or more items
• Use the same word the rest of the product uses

Give the empty state one action

One action, and it should be the action that creates the thing you just described. If the screen will hold saved articles, the button creates the first article. If it will hold projects, the button starts a project. Anything else is a second task, and a second task is what turns a helpful empty state into a menu.

Resist adding a Learn more link, a tour, a sign-up prompt or a contact support link beside it. Those are separate decisions and each one dilutes the button. If the feature genuinely needs an explanation, that explanation belongs in the sentence above the button, not in a second call to action next to it.

• The one button is the action that creates the content
• No second link competing with the button
• The button label names the thing, such as Save an article

Note: The same one-action rule holds in the rest of the product. The onboarding flow guide applies it to the first screens a new user sees.

Build the block from a heading, a sentence and a button

Three parts, and nothing else is required. A Heading that says what this space is for, a Text line that explains it in one sentence, and a Button that starts the first item. Empty state is one of the seven insertable components in App Builder, and you can also assemble the same three parts yourself from a Heading, a Text and a Button.

Put the three parts in a vertical auto-layout container with its gap and padding set, so the spacing between them is a number rather than a series of nudges. An Image is optional, and it only earns its place when it shows the shape of what will appear, such as a sample card.

• Empty state is one of the seven insertable components
• Heading, Text and Button, in a vertical auto-layout container
• An Image only when it shows the shape of the content

1. Insert the block. Insert the Empty state component from the library, or place a Heading, a Text and a Button by hand.
2. Set the container. Give the container a vertical direction with a gap and padding, both between 0 and 96.
3. Add the divider. Use a Divider to separate the block from the page chrome above and below it.

Place the empty state next to the loaded screen

Design both states of the screen, not just the empty one. A loaded version next to the empty version shows you the mismatch: the empty block is too tall, the button will land in the wrong place once content appears, or the message talks about a different thing than the list does.

The block should sit where the first item will sit, and it should not push the page chrome around. A common mistake is centering the empty state in a tall area, so that when three rows of content appear the layout jumps upward. Spotting that with both frames side by side is easier than after the screen is finished.

If the screen is mostly empty space, build the loaded version first and fit the empty state around it. The loaded version tells you how much room the content really takes, and the empty block then fills what is left rather than guessing at a height.

• Build the loaded version too, even if it is rough
• The empty block sits where the first item will sit
• Page chrome does not move between the two states

Note: Two frames of the same screen is a normal use of App Builder, and the layers panel and the layer tree make it easy to keep the two versions in step. The design system guide covers keeping repeated elements consistent.

Check the empty state reads as intentional

Zoom out and look at the screen. An empty state that reads as intentional says what belongs there and offers a way to start. One that reads as broken says nothing, shows a picture, and leaves the user to work out what to do. The difference usually comes from the sentence and the button rather than from artwork.

Read the three parts in order and ask whether they make sense with no other context. If the heading is a word rather than a phrase, the sentence has to carry all the meaning, and it usually cannot. A heading such as Nothing here yet tells the user about the state of the data, not about what the feature is for. The wider tour of the app is in the complete Canvasola guide.

Finally, read it as someone who has never seen the product. If the sentence only makes sense to you, rewrite it in the words a user would use. The data table guide covers the related case where an empty table needs a different message from an empty list.

• The heading names what belongs in the space, not the state of the data
• The sentence works without any other context
• The button label names the action in the user's words

Note: How App Builder sits inside the wider product is covered in the product tour.

A checklist you can reuse

• The screen genuinely needs an empty state, rather than a default list or a filter message
• The block names the kind of content that will appear there
• There is exactly one action, and it creates the first piece of content
• The heading, a Text line and a Button sit in a vertical auto-layout container
• The gap and padding are set as numbers rather than placed by hand
• A loaded version of the same screen exists and both have been compared
• The three parts read correctly on their own, without surrounding context

Common mistakes to avoid

• Filling the space with an illustration. A picture of a folder does not tell a user what belongs in the space. The sentence and the button do that work, and the image is optional.
• Adding a second call to action. A Learn more link beside the button gives the user two choices on a screen that needs one. Put the explanation in the sentence instead.
• Using a heading that describes the data. Nothing here yet describes the state of the data, not the feature. A heading such as Saved articles tells the user what the space is for.
• Centering the block in a tall empty area. When content arrives the layout jumps upward and the page chrome moves. Position the block where the first item will sit.
• Designing only the empty version. Without a loaded version you cannot see that the block is the wrong height or that the sentence disagrees with the list. Build both.

Frequently asked questions

Does every screen in an app need an empty state?

No. A screen that would show a default list, recent items or a sample does not need one, and a list filtered down to nothing is a different case from a screen that has never held data. The candidates are the main screens of features that are new to the user.

How long should the explanation be?

One sentence. The heading already says what the space is for, so the text only has to add what the user cannot work out on their own, such as why the content is worth adding. Anything longer is a help article pretending to be an empty state.

Can I use an image in the empty state?

Yes, and it is optional. An image helps when it shows the shape of what will appear, such as a sample of a card. A decorative illustration adds nothing that the heading and the sentence have not already said, so many good empty states have no image at all.

Does the Empty state component come with the right layout?

It gives you the heading, the sentence and the action as a block, and you can adjust the copy and the styling. If you want full control, place a Heading, a Text and a Button yourself in a vertical auto-layout container with its gap and padding set.

This guide is part of the app builder guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.