Empty States
Last updated:
Practical patterns for no-results and empty views that guide users forward instead of dead ends.
01 — Foundation
Empty states guide recovery
Absence of data is not the same as a broken interface — explain it clearly.
Empty states appear when there are no results, no messages, no items, or no data yet. Handled well, they reduce confusion and point users forward. Handled badly, they feel like broken software.
02 — Explain
What to communicate
Tell users what is missing, why, and what they can do next.
Too vague
'No data'Clearer
'No invoices found for this date range. Try adjusting filters or create a new invoice.'Include
- context — what is empty and in what scope
- guidance — filters to change, content to create, or permissions to request
- next actions — primary button or link when there is a sensible path forward
- reassurance when appropriate — “You have no messages yet” vs a dead end
03 — Avoid
What to avoid
Users came for clarity — not mascot philosophy.
- vague “No data” with no recovery path
- decorative illustrations replacing useful guidance
- humour during critical workflows where users need certainty
- relying only on icons or colour to convey meaning
04 — Accessibility
Accessibility and related patterns
Empty, loading, and error are different states — keep them distinct.
Do not confuse “still loading”, “no results”, and “request failed”. Messages should remain readable at zoom and work for screen readers.
See Loading States for in-progress feedback and Error States when something failed rather than returned empty results.
05 — Review
Before you approve
A short checklist for empty states in code review.
- explains what is missing and why
- offers a clear next step when one exists
- distinct from loading and error states
- readable, accessible, and appropriate to context
An empty state should help users recover — not merely announce disappointment.