Reference entry content
Concept facts
An empty state is a product, interface, or service state where expected content, data, records, cases, results, tasks, or next items are absent.
- Also known as
- Blank state, zero state, no-data state, empty result state.
- Used in
- Product design, service design, dashboard design, case-management systems, onboarding, data-entry workflows, search, and task initiation.
- Interpret with
- Status message, content clarity, user onboarding, task flow, failure state, recovery path, and user control.
Plain-language explanation
An empty state appears when there is nothing to show yet, nothing matching a condition, or no available next item.
For example, a case dashboard may show no assigned cases. A benefits portal may show no submitted applications. A document screen may show no uploaded files.
A good empty state explains what the absence means and what the user can do next.
Why it matters
An empty state can be confusing if users do not know whether the service is working, whether they made a mistake, whether data is missing, or whether no action is needed.
Poor empty states can cause unnecessary support contact, wrong repeat submissions, user anxiety, or staff confusion.
In high-friction services, an empty state may affect task initiation, case handling, document readiness, or service trust.
Use contexts
Empty states are used when:
- users have not started a task
- no records, cases, applications, documents, or results exist
- a search or filter returns no results
- staff queues are empty
- data has not loaded or has not been created
- users need guidance on what to do first
- services need to distinguish “nothing exists” from “something failed”
Application guidance
Explain what the empty state means. Do not leave users with a blank screen or vague “No data” label.
Provide next action where appropriate. This may be creating a case, uploading a document, changing a filter, or waiting for review.
Distinguish empty state from failure state. “No cases assigned” is different from “cases failed to load.”
Use the empty state to support learning, not promotion. It should help the user understand the service.
Avoid misleading reassurance. If data may appear later, explain when or how.
Make empty states accessible and readable across devices and assistive technologies.
Practical example
A civic complaint dashboard for municipal staff shows an empty table after login. Staff cannot tell whether there are no complaints, filters are applied, or the system failed to load assigned cases.
An empty-state redesign says “No complaints assigned to your department today,” shows the active filter, and provides a link to view all open complaints.
The UX consequence is reduced staff confusion, fewer unnecessary support requests, clearer workflow, and better operational confidence.
Interpretive boundaries
An empty state is not the same as a status message, although it may include status text.
An empty state is not a failure state unless something expected failed to appear because of an error.
Empty states should not be treated only as visual illustration opportunities. Their main value is clarity and task support.
Applied at Userhub
Userhub evaluates empty states where absence of content, cases, data, or next actions affects user understanding and task progress.
In UX Lab work, empty states may be reviewed in dashboards, service portals, case-management systems, onboarding flows, and data-entry journeys.
See Userhub UX Lab for applied UX research and evaluation context.
Sources and references
Kaplan, K. (2021, September 19). Designing Empty States in Complex Applications: 3 Guidelines. Nielsen Norman Group. https://www.nngroup.com/articles/empty-state-interface-design/
World Wide Web Consortium. (2024). Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
Government Digital Service. (n.d.). Writing for GOV.UK. GOV.UK. https://www.gov.uk/guidance/content-design/writing-for-gov-uk
Cite this entry
APAUserhub. (2026). Empty State. UX Reference. https://userhub.com.bd/reference/empty-state/