A reporting page once assured me there was “nothing here yet” while I was investigating missing customer transactions. I was investigating why a customer’s transactions had disappeared.
The illustration featured a small rocket.
Empty states are often treated as opportunities for personality. Sometimes they are. More often they are moments of uncertainty. The user needs to know whether nothing exists, nothing matches, nothing is available to them, or something has failed. Those conditions may look equally blank to the interface while meaning entirely different things to the person staring at it.
An empty state should tell the truth before it tries to be delightful.
Empty is not one condition
I usually separate empty states into at least five categories: first use, completed work, no matches, restricted access and failure.
First use means no data has been created. Completed work means the user successfully cleared a queue. No matches means data may exist outside the current query. Restricted access means the system knows about records the user cannot see. Failure means the product could not retrieve or display what should be there.
Each state needs different language and actions. “Create your first quote” is suitable for first use. “You’re all caught up” works for a completed queue. “No quotes match these filters” should preserve and expose the filters. “We couldn’t load quotes” needs retry and support context.
Using one generic message for all five is technically reusable and experientially reckless.
Start with the user’s expectation
An empty screen is interpreted against what the user expected to find. A new account expects guidance. A returning user expects continuity. An operations manager expects records because yesterday there were 300 of them.
Design reviews should therefore ask: what did the person do immediately before reaching this state, and what do they believe should exist? That determines tone and recovery.
The visibility of system status heuristic matters here. Users need to understand what the system believes is happening. Blankness is not status. It is the absence of an explanation.
First use should teach a useful path
A first-use empty state can introduce the product’s core object and help somebody create it. Keep the explanation focused on value and the action concrete. “Create a request to start comparing charter options” is better than “Welcome to the future of logistics!” unless the future is unusually good at filling out forms.
Offer supporting examples or templates where they reduce uncertainty. Avoid forcing new users into a tour of every feature. The aim is the first meaningful outcome, not a guided museum visit.
If setup depends on another team or integration, say so. “Your administrator needs to connect the finance system before invoices can appear” gives the user a route forward. A disabled Create button and a cheerful illustration does not.
No matches should preserve the investigation
When filters or search produce no results, show the query and active constraints. Let users remove individual filters, broaden dates or clear all without losing their original terms. Suggest likely corrections only when they are grounded in the available data.
Do not automatically clear filters and show unrelated records. That converts an empty state into a confidence problem: the user cannot tell whether the query changed or the data did.
In complex marketplace work such as Aerios, requests can be distinguished by customer, route, status and date. A good empty state needs to reflect those dimensions. “No results” is technically accurate but operationally lazy.
Success can also be empty
An empty queue can be a positive outcome. If a user has processed every approval or resolved every exception, the product should acknowledge completion without immediately inventing more work.
This state can show when new items usually arrive, provide a link to completed work or surface a secondary task. Keep the celebration proportionate. Nobody needs animated fireworks because they approved three supplier records before lunch.
Successful emptiness is also valuable measurement. It can indicate that workload is under control, automation is effective or demand is unusually low. The interface should not treat all low volume as a problem merely because a dashboard prefers having something to render.
Restricted access requires care
Permissions can make a populated system appear empty. Revealing that hidden records exist may itself be sensitive, so the design needs to balance clarity and security.
Users can still be told about the rule: “Only account owners can view billing records” or “You do not have access to this workspace.” Explain how to request access where appropriate. Avoid implying that the user has made a filtering mistake.
This is particularly important in shared operational products. Colleagues compare screens. If one person sees data and another sees a generic blank state, they assume the product is broken. A clear permission message preserves trust without exposing the records.
Failure should not dress as emptiness
The most damaging empty state is a failed load presented as no data. It tells the user that reality is empty when the product is merely unable to observe it.
Differentiate network failure, service failure and genuine absence. Preserve stale data when it is safe, label when it was last updated and provide retry. If the failure affects a consequential task, offer a support route with diagnostic context.
The GOV.UK guidance on quality assurance recommends testing usability as well as technical behaviour. Failure-state testing belongs in both categories. A technically handled error can still leave a user making decisions from a false blank screen.
Match the tone to the stakes
Friendly language is not automatically humane. In high-stakes contexts, excessive cheerfulness can feel dismissive. “Oops! No invoices!” is not improved by adding a smiling folder.
Use calm, direct language. Explain what is absent, why if known, and what the user can do. Humour works best when it targets the shared absurdity of work, not the user’s problem. The product should feel like a capable colleague, not a children’s television presenter who has misplaced the payroll.
Measure recovery, not illustration appreciation
Evaluate empty states by whether users understand and recover. Can new users create the first meaningful object? Can searchers adjust a query? Can restricted users identify who can help? Can failures be retried without losing context?
Track exits, repeated searches, support contacts and successful next actions. Observe users because an empty state may look obvious to the team that wrote it and mysterious to everyone who missed the workshop.
Give blankness meaning
An empty state is part of the product’s explanation of reality. It should distinguish absence from filtering, restriction, completion and failure. It should respect what the user expected and offer the next appropriate move.
Begin with truth. Add guidance. Use personality carefully. If there is room after that, by all means include the rocket. Just make sure the data has not fallen out of it.
