A founder sees an empty workspace and thinks, "Nothing has been created yet." A new user may see the same screen and think, "Did I miss something? Is setup incomplete? Did the import fail? Do I have permission?"

That gap matters because blank states appear at fragile moments: after signup, a task, a filter, a new workspace, or a wait for a job. The user is looking for proof that the product understood them and can help.

When the answer is a bare "No items found," the product leaves the user to diagnose the situation alone.

This is not the same problem as SaaS onboarding. Onboarding covers the path into a product. Empty-state design is about the recurring moments after that path, when the interface has no records, no result, no access, or no completed work to show. A mature product will have many of those moments. They deserve as much care as the happy path.

1. Name the kind of blank state before writing it

Not every empty screen means the same thing. Treating them all as "empty" produces vague copy and equally vague recovery paths.

A first workspace has no activity because the user has not started. A search has no result because the query or filters did not match. A dashboard may look empty because data is still arriving. A team member may see nothing because their role limits access.

Those are different states with different next actions.

Before designing the screen, write one internal sentence: "This screen is blank because..." If the team cannot finish that sentence precisely, the user will not be able to either.

For each state, identify four things:

  • What exactly is absent: records, a result, access, completed processing, a selection, or data from a source?
  • Why is it absent in this moment?
  • What can this user do next, if anything?
  • What should they expect after they act or wait?

This prevents one generic component being reused everywhere, even when it makes a wrong promise. "Create your first project" is useful in a new workspace. It is misleading on a filtered list where projects exist but the current filter hides them.

2. Give a first workspace one obvious start

A first workspace is a test of whether the product can explain its own model.

The user needs to understand what belongs here and which action creates the first useful thing. They should not need to decode internal nouns or hunt through menus to infer the intended path.

One primary action is usually better than a gallery of equal options. If there are several legitimate starts, recommend one and explain the alternatives plainly. A data product might offer "Connect a source" first and "Explore a sample workspace" as a lower-risk alternative.

The button alone is not enough. Tell the user what it will produce. "Add source" is weaker than "Connect a source to see your first report." The second version explains both the action and the payoff.

This is where the first-use checklist and empty-state work touch. The first screen must protect momentum, but a good empty state keeps doing that after the initial tour is gone.

3. Make no-results views explain the search, filter, or scope

"No results" is often technically true and practically useless.

When a user searches, filters, or changes a date range, they need help understanding whether the product found nothing, looked in the wrong place, or is showing a narrower slice than expected. The state should echo the condition, not merely announce absence.

For example, a list can say that no records match the selected owner and date range, then offer to clear filters. A search state can repeat the query and suggest checking spelling or trying a broader term. A monitoring view can state that no alerts occurred in the selected window rather than making a quiet system look unconfigured.

Avoid making the user reverse-engineer invisible conditions. Show active filters, preserve the search input, and make reset or adjustment easy. Do not replace useful context with a decorative illustration.

This becomes especially important in products where users make decisions from filtered data. As the data-product trust checklist argues, a number or result needs enough context to be believable. A blank result needs context too.

4. Distinguish waiting from failure and completion

A waiting state is not an empty state with a spinner added.

The user needs to know what the product is doing, whether their action was received, and what happens if the work does not finish. The same is true when an import, report, sync, or generation produces no visible result yet.

Good waiting communication is specific without inventing certainty. It can say that a source is being checked or that results will appear once processing completes. It should not promise an exact time unless the product can support it.

If the process can fail, make the failure state distinct. A user should not have to decide whether a silent screen means "still working" or "gave up." Provide retry, refresh, contact, or status options that match the real recovery path.

This matters for AI, imports, automations, and integrations because the product is asking for patience before showing evidence. The integrations checklist covers the connection itself; this screen covers the moment after connection when the user is waiting to see whether it worked.

5. Explain limited access without making people feel locked out

An empty view can be a permissions state in disguise.

The user may have joined the right workspace but lack access to a project, report, folder, or setting. Showing a blank table implies there is nothing there and can create duplicate work or support requests.

When access is limited, explain the boundary without exposing information the user should not see. The screen can say they do not have access, name the controlling role if useful, and offer a route to request access.

The wording should be calm and factual. Avoid language that sounds accusatory, and avoid hiding the problem behind an empty-state illustration. A limited view is a product rule, not a personal failure.

This should be checked alongside the SaaS permissions checklist. Roles and invites can be technically correct while the resulting restricted view still leaves users unable to understand why they cannot continue.

6. Use examples to teach, not to fake activity

Examples can make an empty product easier to understand. They can also make it harder to trust.

A sample project, demo report, or illustrative record is helpful when it clearly teaches what the product will look like with real work. It is risky when it looks live, hides the work needed to create the real thing, or makes the account appear populated when it is not.

Label examples honestly. Explain whether they are editable, removable, or separate from the user's workspace. Make the transition to real data obvious: what the user needs to provide and what will change.

Examples should lower the cost of understanding, not disguise setup. A sample dashboard that does not explain its inputs merely moves confusion to the next screen.

7. Build recovery into every blank result

Some empty states are the end of a failed attempt. The user submitted a form, ran a report, connected a source, changed a setting, or looked for a record. Nothing appeared.

The recovery path should match the likely cause. If a request needs more input, point to it. If a filter is too narrow, offer to clear it. If a connection needs attention, show status and retry. If the product cannot complete the task, preserve the user's work and say what happened.

Avoid the dead end where the only action is to reload and hope. Reloading can destroy context, repeat work, or make a recoverable problem look random.

Test recovery from the user's point of view. Try an invalid filter, an expired connection, an account with no matching records, a job interrupted halfway through, and a role with limited access. Then ask whether every blank or weak-result screen explains the next best action.

The broader launch QA checklist is useful here: test the path people actually take after the ideal result does not appear, not only the clean demonstration route.

8. Review empty states as a system before launch

The problem is rarely one bad sentence. It is usually inconsistency.

One page tells the user to create a project. Another says there are no projects. A third shows a blank panel. An import waits silently. A restricted view looks identical to an empty one. The product now communicates conflicting versions of what "nothing" means.

Run a deliberate empty-state pass before launch. Start with a cold workspace. Visit every major area before creating anything. Search for something that does not exist. Apply filters until a list is empty. Wait for an asynchronous action. Open the product with a limited role. Disconnect a source where that is safe. Complete one workflow and inspect the state after the result is removed or archived.

For each screen, record the state, its explanation, the next action, and the recovery path. The goal is not to add copy everywhere. It is to remove ambiguity where the product has less visible evidence to offer.

  • Does every empty screen identify the condition clearly enough for a new user?
  • Does it show one appropriate next action or explain why no action is needed?
  • Are waiting, failure, access limits, filters, and first-use states visually and verbally distinct?
  • Do examples make their status clear and lead naturally into real work?
  • Can users recover without losing work or guessing what the product did?
  • Do the terms and actions match across the product?