---
title: "Empty state design: turning a blank screen into the first step"
description: "The four types of empty state, what a first-use empty state on a merchant dashboard should contain, and when sample data beats real data."
topic: "Activation and time to value"
date: 2026-10-13
updated: 2026-10-13
author: "Geetansh Saini"
url: https://www.geeetansh.com/guides/empty-state-design
tags: ["empty states", "dashboard design", "onboarding"]
---
# Empty state design: turning a blank screen into the first step

**In short:** An empty state is what a screen shows when there is nothing to show yet, and it is the first screen most merchants see in a new app. There are four kinds, first use, no results, cleared, and error, and they need different content. A first-use empty state on a merchant dashboard should say what will appear there, show one true thing about the merchant's store right now, and offer the single action that fills the screen. Use real store data wherever your scopes allow and keep sample data for stores that have nothing to show.

## What is an empty state and why does it matter?

Every list, table, chart, and dashboard in your app has a moment when it holds nothing. For a new merchant, that moment is the whole product. They installed, approved the scopes, and landed on a dashboard of zeros. What that screen says decides whether they do the next thing or close the tab.

Nielsen Norman Group's [guidelines for empty states](https://www.nngroup.com/articles/empty-state-interface-design/) give the empty state three jobs: communicate system status, provide learning cues, and provide direct pathways to the tasks that will fill it. The article's warning is the part I quote to engineers: "Totally empty states cause confusion about how and whether the system is working."

Shopify's [App Home empty state composition](https://shopify.dev/docs/api/app-home/patterns/compositions/empty-state) says the same thing in merchant terms. An empty state "tells merchants why a page, list, or table has nothing to display," and its best practices open with "Say why it's empty, then what to do" and "Offer one clear primary action."

I came to this from the support side. I read the tickets a screen of zeros creates before I designed the screens. Usually the app is working. The screen just does not say so.

## What are the four types of empty state?

They look alike and they are not. Each one answers a different question from the merchant.

| Type | When it appears | The merchant's question | What it must contain |
|---|---|---|---|
| First use | The store has never had this data | What is this, and how do I start? | What will appear, one true fact about their store, one action |
| No results | A search or filter matched nothing | Is my data gone, or is my filter wrong? | The filter that produced it, and a way to clear it |
| Cleared | The merchant worked through everything | Am I done? | Confirmation, and what will refill the list |
| Error | The data failed to load | Is it me, the app, or Shopify? | What failed, whether it will retry, what to do if not |

The second and fourth types are where I see the most damage from a single generic component. A "No affiliates yet" message shown because a date filter excludes everyone tells the merchant their program is empty when it is not. NN/g calls this out directly: "Inaccurate system-status messages for empty states are particularly harmful." The same goes for the flash of "No orders yet" that appears while orders are still loading. If the data has not arrived, show a loading state, never an empty one.

The cleared state is the one teams forget, and it is a good one. An affiliate payouts queue with nothing in it after the merchant has paid everyone is a success. Say so.

## What should a first-use empty state on a merchant dashboard contain?

This is the one that decides activation, so it gets the most care. I build it from five parts, in this order on the screen.

1. **What will appear here, in the merchant's words.** Not "No data". "Orders referred by your affiliates will show here, with the commission owed on each."
2. **One true thing about their store right now.** This is the part most apps skip, and it is the part that works. You have order, product, and customer access the moment OAuth completes. "Your store had 1,230 orders in the last 30 days" tells the merchant the app is connected and has understood their business. It is also the system status NN/g asks for, delivered as a fact rather than a spinner.
3. **The one action that fills the screen.** One button, and it does the thing, not a link to settings where the thing can be configured.
4. **What happens after the action.** "Once your signup page is live, affiliates who join will appear here within a minute." This sets the expectation for the wait, which matters when the outcome depends on other people.
5. **A secondary route, if there is a real one.** Import existing affiliates from a CSV. Connect a TikTok Shop account. Not "Learn more".

Three examples from the kinds of dashboards I have worked on:

**Affiliate dashboard, referred orders table.** "Orders referred by your affiliates will show here. Your store had 1,230 orders last month from 980 customers, and 212 of them have bought from you twice. Invite your repeat customers to become affiliates." Button: Create your program. Below: "Your first referred order usually appears within a few days of an affiliate sharing their link."

**Creator outreach dashboard for TikTok Shop, replies inbox.** "Creator replies will land here. 14 of your products are listed with an open affiliate plan on TikTok Shop. Send your first batch of messages to creators who have sold similar products." Button: Pick a product. Below: "Most creators reply within two days if they reply at all, so check back then."

**Attributed orders dashboard for an upsell app.** "Orders that contained one of your offers will show here. Your offer on the cart page went live two minutes ago. The next order that includes it will appear within a minute." No button, because the action is done. This is the one case where an empty state with no call to action is correct: the merchant has done their part and the screen is honestly waiting.

Notice the illustration is not on the list. Shopify's composition allows an optional graphic, and I use one when it shows what the filled screen will look like. A smiling box with a magnifying glass tells the merchant nothing about their store.

## Should you use sample data or real data?

Real data wherever you can get it, labelled sample data where you cannot, and never the two mixed on one screen.

| Situation | Use | Why |
|---|---|---|
| Live store with orders and customers, app not yet configured | Real data | The merchant wants to know what the app will do with their store, not with someone else's |
| Brand new store with no orders | Sample data, labelled | There is nothing true to show, and a dashboard of zeros reads as broken |
| Development or demo store | Sample data, labelled | Same reason |
| Configured, waiting on third parties (affiliates, creators) | Real data, including the zeros, plus the pipeline | The zeros are true, and the pipeline shows the program is alive |
| Preview of a report or chart the merchant has not generated | Sample data, labelled, with a "generate with my data" action | The sample shows the shape, the action gets the real thing |

Two rules keep sample data from backfiring. First, label it on the data itself, not in a tooltip. A chart with "Sample data" written across it is fine. A chart that looks real and has a small note under it will be screenshotted and sent to a business partner as real. Second, make the sample data disappear the moment any real data exists. A single real affiliate sitting in a list of fake ones is a trust problem.

The reason I push real data so hard is that it is the shortest path to the first result. The guide on [Shopify app onboarding](/guides/shopify-app-onboarding) covers the first screen in detail, and it rests on this: the merchant's own order count on the first screen does more than any tour.

## What about the state after the first action, when the screen is still mostly empty?

The first-use empty state goes away the moment one row exists, and most apps stop designing there. But a merchant with one affiliate and no orders, or three creators messaged and no replies, is in a state that is nearly empty and entirely undesigned. This is where merchants decide the product does not work, usually around day three of a trial.

Design it as a pipeline. Show every step between the merchant's action and the outcome, with the count at each step. Three affiliates joined, two have shared their link, 41 clicks, no orders yet. That screen tells the merchant the program is alive, shows them where it is slow, and gives them something to act on. The guide on [time to value](/guides/time-to-value-saas) treats this as the gap between first value and full value, and it is the same screen.

If there is a checklist on the dashboard, this is also where it should point to the next highest-value step, not the next setup step. The guide on [onboarding checklist design](/guides/onboarding-checklist-design) covers that ordering.

## The mistakes I see most often

- A single generic empty component used for all four types, so the error state says "Nothing here yet" and the merchant thinks the app has lost their data.
- A call to action that opens settings rather than doing the thing. "Configure your program" versus "Create your program".
- KPI tiles showing $0 and 0% above a first-use empty state. A zero is a claim about performance. On a store that has not started, it is a false one. Hide the tiles or replace them with the store facts you do have.
- An empty state that appears for a second while data loads. Show nothing, or a skeleton, until the request returns.
- Empty states written by engineers at the end of a ticket, because nobody specified them. If the design file does not have the empty state for every list and table, the engineer will write "No data found", and that is what the merchant will see first.

## Where to start

1. List every screen in your app that can be empty, and mark which of the four types each one can show. Most will have two or three.
2. Open the app on a fresh store and screenshot every empty state you hit in the first ten minutes. Read them as a merchant would.
3. Rewrite the first-use state on the home dashboard using the five parts above, with one true fact from the store's own data.
4. Find every place a loading state shows an empty message first, and fix it.
5. Design the nearly-empty state for your main dashboard: one row, no outcome yet, as a pipeline with counts.

## Frequently asked questions

### What should an empty state say?

What will appear there, why it is empty right now, and the one action that will fill it. For a first-use state on a merchant dashboard, add one true fact from the store's own data so the merchant knows the app is connected and has understood their store.

### Should empty states have illustrations?

Only when the illustration shows what the filled screen will look like. A generic drawing adds height and no information. Shopify's own empty state composition treats the graphic as optional, and the heading, the explanation, and the primary action are the parts that do the work.

### What is the difference between an empty state and a dashboard showing zeros?

A zero is a measurement. On a store that has not started using the feature, it is a false measurement that reads as failure. An empty state explains that nothing has happened yet and what will make something happen. Hide the zeros until there is something to count.

### How do you design an empty state when the outcome depends on other people?

Show the pipeline between the merchant's action and the outcome, with a count at each step, and set the expectation for the wait in plain words. "Affiliates who join will appear here within a minute" and "most creators reply within two days" both turn a blank wait into a known one.