UX Empty States: Helpful No-Data, Loading, and Error Screens
An empty screen is still part of the product experience. It might mean the person has not created anything yet, a search returned no matches, a filter removed every result, access is missing, or a request failed. Showing the same blank panel for all of these situations leaves people to guess what happened.
Useful UX empty states name the situation accurately, preserve the user's context, and offer a next step only when one is appropriate.
Distinguish the state before writing the message
Start by identifying the cause:
- First use: The user has not created or saved anything yet.
- No results: A search or filter completed successfully but found no matches.
- No access: The resource exists, but the person cannot view it.
- No connection or unavailable data: The product cannot currently retrieve the resource.
- Loading: A request is still in progress; the final result is not known.
- Error: The request failed and needs recovery or support.
These states should not look or sound interchangeable. In particular, never show “No data yet” while a request is still loading. That can prompt duplicate creation or cause users to assume their saved data disappeared.
Write the message around what the person can do
A strong empty state answers three questions in order: what is happening, why it is happening when that is known, and what the person can do next.
For a first-use state, say what will appear and give a direct action such as “Create your first project.” For no results, summarize the current search or filter and offer a way to revise it. For missing access, explain who can grant it or how to request access. Avoid an action that promises something the user cannot complete.
For errors, describe the failed operation without blaming the person. If retrying is safe, provide a retry. If the action may have succeeded despite a timeout, check the current state before inviting a duplicate submission. Include a reference ID or support route when it helps diagnose the problem.
Keep loading, empty, and error feedback separate
Use a loading indicator when a task is actually pending. For a known short wait, a simple progress cue may be enough; for longer tasks, communicate what is being loaded and preserve the surrounding layout. Do not show a fake percentage unless it reflects measurable progress.
When asynchronous updates complete, announce the important result to assistive technology without unexpectedly moving focus. A concise status message is often more appropriate than an assertive alert for routine updates. Reserve urgent announcements for failures that need immediate attention.
On forms, preserve entered values when validation or a network request fails. Explain which fields need correction, associate messages with their controls, and move focus only when doing so helps the user recover. The accessible form design guide covers those form-specific details.
Make empty states part of the component contract
For each data-driven component, document its loading, populated, empty, filtered-empty, permission, and error states. Confirm which state owns the retry action, whether a filter can be cleared, and whether the empty message changes for first-time use versus an established workspace.
Use design-system components for consistent spacing and semantic structure, but keep the message specific to the feature. A generic illustration can add warmth, but it should not replace a clear heading and meaningful instructions. Ensure controls remain keyboard accessible, have visible focus, and work at narrow viewport widths.
Review these states in product testing, not only in the happy-path demo. Create fixtures with zero records, long error messages, slow responses, and permission changes. The UX writing guide and user onboarding guide offer related patterns for clear, useful next steps.