Empty State Flow

An empty state flow maps how users arrive at each empty state and how they get out of it. Emptiness is not one state — it is five different states with five different causes, and each cause demands a different route to usefulness.

Division of labor: Onboarding, First-Run & Empty States holds the pattern evidence — what a good empty screen contains, the NN/g findings, activation mechanics. This file maps the FLOWS into and out of each empty state: which path brought the user here, and which arrows lead somewhere useful. An empty state designed without its arrows is a poster, not a screen.

When to use one

Any list, feed, inbox, dashboard, search, or canvas — anything that displays a collection can display an empty collection.
Onboarding design: for new users the empty state IS the product (cross-ref Onboarding Flows); the first-use empty screen is a fork between activation and abandonment.
Search and filtering design: no-results is a guaranteed, frequent state, not an edge case (Search & Filtering).

What it answers

Which empties can occur on this screen, and can the UI tell them apart? (It must — the data layer knows why the set is empty.)
What did the user do — or not yet do — to arrive here?
What is the single most useful next action from each empty, and is it one tap away?

The five empties and their routes

First-use (nothing created yet) → route to ACTIVATION: explain what will live here, one primary CTA to create the first item, optionally sample content or a template to edit. The exit arrow points at the product's first-value moment.
User-cleared (inbox zero, all tasks done) → route to CONTINUATION: confirm/celebrate the accomplishment, then suggest the next thing (review archive, plan tomorrow, invite someone). Never show first-use copy to a power user who just cleared their queue — "Get started with your first task" after finishing forty is insulting and disorienting.
No-results (search found nothing) → route to RECOVERY: echo the query, offer spelling/broader-term fixes, show near-matches or popular items; keep the search box filled and focused for one-edit retry.
No-filter-matches (items exist; filters exclude all) → route to RELAXATION: show which active filters caused it, one-tap "clear filters" or per-filter removal, and say how many results each removal restores if you can. This is distinct from no-results — the data exists, the user's own settings hid it, and the fix is theirs to undo.
Error-caused (load failed, so the container is blank) → this is an ERROR wearing an empty costume: honest cause + retry, per Error Flow. Never show "Nothing here yet!" over a failed request — the user may conclude their data is gone.

Example — New user, projects app

Sign-up complete ──▶ Projects screen: EMPTY (first-use)
                       │  "Projects keep your team's work in one
                       │   place" + [Create First Project]
                       │   + (Browse templates)
                       ├──▶ Create First Project ──▶ Name it ──▶
                       │      Project Created ──▶ project canvas
                       │      (first-use empty of ITS own — seed it
                       │       with a starter task, not more blank)
                       ├──▶ Template ──▶ pre-filled project (learn
                       │      by editing)
                       └──▶ Leaves without acting ──▶ re-entry route:
                              next session shows same CTA + email
                              deep-link into the incomplete step
                              (activation mechanics: see
                              Onboarding, First-Run & Empty States)

Search within app ──▶ "budjet" ──▶ No results for "budjet"
    ├──▶ Did you mean "budget"? ──▶ results
    ├──▶ Clear search ──▶ full list
    └──▶ still nothing (genuinely none) ──▶ offer "Create 'budjet'
          project" — turn the dead end into creation

Failure branches to note: the user who bounces without creating gets a designed re-entry, not a shrug; the created project's own screen avoids stacking a second blank canvas on the first; the search loop exits into creation when recovery finds nothing.

Common mistakes

One empty design reused for all five causes (the classic: error and first-use rendered identically).
Empty states with no arrow out — an illustration and a sad caption, no CTA (decoration where activation should be).
Filters silently emptying a list with no indication that filters are the cause.
Celebrating "inbox zero" the first time the user opens an inbox they've never used.
Designing the empty last, after the populated layouts, so it inherits chrome (sort controls, bulk actions) that mock the void.

Checklist

Every collection screen lists which of the five empties can occur, and each has a distinct design.
Each empty state has at least one outgoing arrow to a useful action; first-use routes to the activation event.
Error-caused empties are visually and verbally errors, with retry (Error Flow).
No-filter-matches names the filters and offers one-tap clearing.
No-results keeps the query editable and offers recovery or creation.
User-cleared empties acknowledge the accomplishment; first-use copy never shows to established users.
The abandonment branch is designed: what happens when a user leaves the first-use empty without acting?
Empty appears as a named state in the component's State Flow diagram, distinguished from loading.

Sources

Nielsen Norman Group — Kaplan, K. (2021). "Designing Empty States in Complex Applications: 3 Guidelines" (nngroup.com/articles/empty-state-interface-design/).
Hurff, S. (2016). Designing Products People Love. O'Reilly, ch. 6 — the empty/blank state as one of the UI Stack's five states.
Pattern evidence, activation metrics, and first-run practice: Onboarding, First-Run & Empty States and its sources (NN/g mobile-onboarding research; Apple HIG; Material Design empty-states guidance).