How to Design Empty States That Guide Users

Why empty states matter more than they look like they do

An empty state — an inbox with no messages, a dashboard with no data yet, a search with no results — often shows up at exactly the moment a user is deciding whether the product is worth continuing to use. A blank screen with no guidance reads as broken or abandoned, even when it's just... empty. Treating this as a real design problem, not a default fallback, pays off disproportionately.

The three types of empty state, and why they need different treatment

• First-use empty state: the user hasn't done anything yet — there's genuinely nothing there because nothing has happened. This needs to guide toward the first action clearly ("Create your first project") with a specific, prominent call to action.
• Cleared-out empty state: the user had content and it's now gone — an emptied inbox, a completed task list. This should confirm the state positively ("You're all caught up") rather than looking identical to the first-use state, which would be confusing.
• No-results empty state: a search or filter returned nothing. This needs to explain why (the specific query or filter applied) and offer a way to adjust or clear it — a dead end here is one of the most common sources of frustration.

What every empty state needs

• A clear explanation of why it's empty — not just visual absence, but a sentence stating the actual state.
• A specific next step, not a generic one. "Create your first project" beats "Get started."
• Visual weight appropriate to the moment — a first-use empty state, especially in an important area of the product, deserves more visual presence (an illustration, a prominent button) than a routine "no results" state, which should stay lightweight and get out of the way quickly.

Common mistakes

• Treating every empty state as identical — showing the same generic "Nothing here" message whether it's a first-use screen or a cleared-out success state sends the wrong emotional signal in at least one of the two cases.
• No next step at all — a message explaining the state without any action leaves the user exactly where they started.
• Overloading first-use states with too many options — a first-use empty state trying to explain five features at once usually undersells all of them; pick the single most important next action.
• Ignoring error-caused emptiness — if the empty state is actually the result of a failed request, not a genuinely empty dataset, the copy needs to say so and offer a retry, not present it as if there's simply no data.

Writing the microcopy

Empty-state copy is a good test of your product's voice — it's often the first substantial writing a new user reads. Keep it specific to the actual context (name the thing that's empty, not a generic placeholder) and keep the tone consistent with the rest of the product; see how to write microcopy that reduces support tickets for the broader discipline.

Designing before you have real data

Because empty states are easy to overlook in a design process focused on data-rich screens, deliberately design and review them alongside the populated version of every screen — not as an afterthought once the "real" design is done. A screen isn't finished until its empty state is designed with the same care as its full state.

More from our insights: The Product Design Process, End to End.

Reference: the authoritative guidance lives at Nielsen Norman Group.

Common questions