Empty state UI design: guide the next step when content is missing

1. Diagnose why the space is empty

Treat an empty state as a report about the product, not as a decoration opportunity. Ask what happened immediately before the screen appeared, what the system knows, and whether the person can change the situation. NN/g describes empty states as opportunities to communicate status, support learning, and provide pathways into key tasks. Those opportunities depend on correctly identifying the state first.

In particular, don’t display “No items” while a request is still running. Keep a loading indicator or skeleton visible until the result is known. If the request fails, explain the failure and recovery option. If it succeeds with zero items, say that no matching content exists. This distinction prevents people from mistaking a temporary delay or system problem for a real result.

2. Write copy that matches the cause

Use a heading to name the state and supporting text to explain what it means or how to proceed. Keep the heading scannable. Add a sentence only when it answers a real question. Apple’s writing guidance recommends clear next steps on blank screens, action-oriented labels, and direct error messages that explain how to fix the problem. Avoid cleverness that obscures meaning, vague headings such as “Nothing here,” or copy that blames the person.

For example, a hypothetical saved-items screen on first use might say “Your saved guides appear here” followed by “Save a guide to return to it later,” with a “Browse guides” button. A completed checklist could say “You’re all caught up” and offer “View completed tasks.” These examples describe different realities: one teaches how to populate a feature; the other confirms a successful outcome.

For a successful search with no matches, a hypothetical message could read “No projects match ‘orchid’” and suggest “Try a broader term or clear filters.” Preserve the query and make filter changes reversible where possible. For a network failure, write “Projects couldn’t load” with “Try again.” Avoid claiming there are no projects when the system has not been able to check.

• Name the relevant object or criteria so the message makes sense out of context.
• Use a verb on the button, such as “Create project,” “Clear filters,” or “Try again.”
• Keep instructions next to the affected content and use text as well as color or imagery.
• Avoid “Oops,” blame, and technical codes unless people need them to resolve the issue.

3. Make the next step useful, not automatic

Give an action when someone can reasonably change the situation or continue their task. First use often benefits from a create or add action; no results may benefit from clearing a constraint; an error may offer retry. A cleared inbox or finished workout may need no action at all. Don’t force a button into every state just to make the panel look interactive.

Keep recovery proportionate. A failed refresh usually calls for an inline explanation and retry, not a blocking alert. Apple recommends matching feedback to the importance of the information and reserving alerts for critical, actionable situations. For search, preserve the person’s work and offer sensible adjustments rather than silently changing the query. Material Design also suggests starter content, brief educational content, or clearly labeled best matches as alternatives when they genuinely help.

Use illustration only if it adds context, warmth, or recognition. It should not compete with the message or make people think a decorative image is interactive. A simple icon may be enough for a compact filter result; a first-use workspace could benefit from a small example of the kind of content it will hold. If starter content is included, make it easy to identify and remove.

• Choose one primary action that directly addresses the cause.
• Add a secondary help path only when it answers a likely follow-up question.
• Use a quiet completion message when the empty result is good news.
• Ensure an action remains understandable to keyboard and screen-reader users.

4. Review the whole state, not just the illustration

Inspect the state in the actual container: a full-screen first-use view, a small sidebar, and a filtered table have different space and hierarchy needs. Keep the message near the area it describes. Ensure it remains readable when text enlarges or wraps, and make the primary action easy to find without requiring color recognition. Test transitions too: loading to empty, loading to error, retry to success, and a filter change back to results.

A practical library review starts with a trigger and an expected recovery. For each pattern, record the state, heading, optional explanation, primary action, secondary route, and what happens after selection. Compare screenshots for useful structure and visual hierarchy, then check the product behavior in context; a static image cannot tell you whether an error is recoverable or whether a result is truly empty. Browse the ScreenKits UI library for visual references and explore all categories to find adjacent patterns.

• Can a person tell whether the content is absent, still loading, or unavailable because of an error?
• Does the message reflect the current query, filters, account, or completed task?
• Does the action preserve useful input and lead to a visible outcome?
• Does the state work at small sizes, with longer localized copy, and with assistive technology?
• Can someone recover from an error or find a way to adjust an unsuccessful search?