guide 4 min read
Specify Empty, Loading, and Error States Together
Empty, loading, and error states should explain what is happening and support the next useful action.
THE SHORT ANSWER
What you need to know
Empty, loading, and error states should explain what is happening and support the next useful action. Distinguish a first-use empty state from a filtered result and distinguish a system failure from a permission restriction. Preserve context while loading or recovering. Specify these states alongside the successful view so implementation does not fill important gaps with generic messages.
Key takeaways
- Distinguish causes of emptiness.
- Keep loading near its context.
- Preserve work during recovery.
- Review connected state transitions.
Name the reason behind an empty view
An empty list can mean no records exist, a filter excludes them, the person lacks access, or data has not loaded. Those causes require different explanations and actions. Describe the underlying state before writing the message. A first-use invitation to create a record is inappropriate when records exist but the current filter hides them.
Imagine a hypothetical equipment catalog. A new workspace has no equipment entries; a search for an unavailable category has no matches; a restricted user cannot see certain entries. The interface should distinguish these situations without revealing information that the user is not allowed to access. Offer creation, filter adjustment, or an access route only when that action is available and relevant.
Preserve orientation during loading
Determine whether existing content can remain visible while new information loads. Replacing the entire page with a spinner may remove useful context, especially during sorting or pagination. Show loading close to the affected region and avoid presenting stale information as if it were freshly confirmed. Decide which controls remain usable while a request is underway.
In the equipment example, changing a filter can keep the previous results visible with a clear updating state until the new results arrive. If the old results might lead to a consequential wrong action, disable that action or explain the pending state. Stable layout helps, but a skeleton should match the actual structure closely enough to avoid a distracting jump after loading.
Match recovery to the cause of failure
An error message should describe the failed action and the practical next step. A connectivity problem may support retry; an invalid filter may support editing; missing permission may require an access request. Avoid sending every failure to a generic support link. Keep useful input and selected context so recovery does not force the person to restart the task.
Consider an equipment transfer that fails after the user selects a destination. Retain the selection and explain whether the transfer was saved, rejected, or remains uncertain. If the result is uncertain, check authoritative status before encouraging another submission. The distinction between “failed to display confirmation” and “failed to transfer” matters because a blind retry could produce duplicate or conflicting operations.
Review transitions, not isolated illustrations
Create a state map that shows how successful, empty, loading, and failed views connect. Walk through initial entry, filter changes, retries, and returning after an interruption. Check text, focus, announcements, and action availability across transitions. A polished empty-state illustration does little if the surrounding behavior contradicts its message.
Use representative slow and failed requests in the rendered product. Confirm that loading does not last indefinitely without an explanation and that recovery leads to a fresh, accurate state. Document when background retries occur and when the person must initiate them. For a reusable component, keep state responsibilities clear: the component may display a message, while the owning workflow determines its cause and action.
- Identify why content is absent.
- Keep useful context during updates.
- Explain whether an action was saved.
- Test state transitions and retries.
Make feedback states consistent across screens by assigning clear roles to text, surfaces, and status cues rather than choosing a new visual value for each state.Create Design Tokens with Clear Product Roles
Common questions
Should every empty state have a button?
Only when a relevant next action is available. A clear explanation may be sufficient. Adding an unrelated call to action can distract from the reason the view is empty.
When should a skeleton be used?
Use it when a stable content structure is expected and it helps orientation. For short or unpredictable updates, a localized status message may communicate more accurately.
Can errors disappear automatically?
They can resolve when the underlying condition changes, but consequential outcomes should remain clear. Do not remove a failure message before the person can understand whether their action completed.
References & further reading
These primary references support the background. The practical frameworks and illustrative examples are written for this guide.
Prepared with AI assistance. Examples are illustrative; no client results are implied. Read our editorial approach.