An empty screen is not necessarily a broken screen. A new account may have no saved projects yet. A search may return no matches. A filter may hide every item. A network request may still be loading, or it may have failed. Those situations can look similar if an interface only renders an empty rectangle, but they require different explanations and different next steps.
Empty states are part of the normal product journey. They are often the first thing a new user sees, and they are a common destination after someone changes a filter or removes an item. A useful empty state explains the current condition without blaming the person and offers a realistic way forward.
Do not treat every empty result as the same state
At least five situations deserve different messages:
- First use: the user has not created or saved anything yet.
- No search matches: the data exists, but the current query found nothing.
- No filtered results: a filter or combination of filters removed every visible item.
- Loading: the application does not know the result yet.
- Failure or offline state: the application could not obtain the data.
Calling all five states “Nothing here” removes information the user needs. A loading screen should not suggest that a collection is empty. A network failure should not be presented as a successful search with no results. A first-use state can invite someone to create an item, while a filter-empty state should offer a way to broaden the current view.
Explain the condition in ordinary language
Start with a short sentence that names what happened. “No projects yet” is clearer than “Empty”. “No results for ‘map tiles’” is more useful than “Nothing found”. “We could not load your saved items” communicates a failure instead of making the user guess whether the items were deleted.
When a search or filter is involved, preserve the user’s input and describe the relevant constraint. Do not clear the search field just because there are no results. A person should be able to edit the query without reconstructing it from memory. If several filters are active, show them in a visible, removable form so the user can identify which one is too restrictive.
Offer one useful next action
A first-use state might offer “Create your first project”. A search state might offer “Clear search” or “Try a broader term”. A filtered list might offer “Remove filters”. An offline state might offer “Retry” while preserving any local work. The action should solve the condition that the message describes.
More buttons do not automatically make an empty state more helpful. A screen with five unrelated calls to action creates another decision problem. Choose the action most likely to help, and keep secondary navigation available in the normal interface. If there is no safe automatic next step, explain what the person can do elsewhere instead of inventing a button that cannot work.
Do not manufacture urgency or pretend data exists
Empty states are sometimes filled with fake examples to make a product look busy. Sample data can be useful in a clearly labelled demo or tutorial, but it should never be confused with a person’s real saved information. If a product offers sample content, give the user a clear way to remove it and explain that it is illustrative.
Avoid manipulative copy such as “You are missing out” when the person simply has not created an item. Do not use a large warning icon for an ordinary first-use state. The tone should match the consequence: calm for an empty collection, specific for a failed request, and direct when a real action is required.
Make the state accessible
Use real text rather than embedding the message inside an illustration. Give the heading a meaningful structure, keep the action keyboard accessible, and make focus visible. If the empty state appears after a search, ensure the result count or status is announced appropriately without forcing a screen reader to hear a long paragraph after every keystroke.
Colour and illustration can reinforce meaning, but they should not carry it alone. A muted icon may be decorative; if it conveys a status, provide a text equivalent. Do not move keyboard focus unexpectedly when results disappear. If a user activates “Clear filters”, the interface should return focus to a sensible place, such as the results heading or the filter controls.
Keep empty, loading, and error states separate in code
It is tempting to write a component that displays the empty message whenever an array has length zero. That logic can be wrong while a request is pending, before a request has succeeded, or after an error. Model the state explicitly:
switch (state.kind) {
case "loading":
return "Loading projects…";
case "error":
return "Projects could not be loaded. Try again.";
case "empty":
return "No projects yet. Create your first project.";
case "ready":
return renderProjects(state.items);
}The example is intentionally small. A real application may also distinguish first use from an empty search, and it should keep the original error available for diagnostics without exposing sensitive implementation details to the user. The important point is that the UI should reflect what the application actually knows.
A review checklist
- Can a new user tell why the collection is empty?
- Can someone tell the difference between no results, loading, and failure?
- Does the message preserve the search or filter that produced the state?
- Is there one clear action that genuinely helps?
- Are sample items clearly labelled and removable?
- Can keyboard and screen-reader users understand the state and reach the next action?
- Does the message avoid blame, false urgency, and promises the product cannot keep?
These ideas connect to our guide on form errors that explain the problem. In both cases, the interface should identify the condition, explain what it means, and offer a recovery path instead of relying on a red border or an unexplained icon.
Useful guidance
The GOV.UK Design System’s error message guidance is a useful reference for writing specific, actionable feedback. WCAG’s Error Suggestion explanation describes when an interface should help people identify how to correct an input error. Empty states are not identical to form errors, but the shared lesson is that messages should help people understand and recover.
A good empty state is not decoration for an unfinished screen. It is a small piece of product guidance at exactly the moment someone needs it. When the message describes the real condition and offers a useful next step, an empty screen becomes part of the interface rather than a dead end.
What do you want to say about this?