Designing Empty States That Guide Instead of Dead-End

UI/UX

Empty states are the screens a user hits when there is nothing to show yet: an inbox with no messages, a dashboard before any data has landed, a search that returned nothing, a project list on the very first login. Most teams treat these moments as afterthoughts, so they ship a blank rectangle, a lonely spinner that never resolves, or a sad little sentence apologising for the emptiness. That is a mistake, and an expensive one. In the studio we have come to see empty states as some of the highest leverage pixels in a product, because they are so often a user’s first honest encounter with a feature. This post is about how to design empty states that guide a person forward instead of leaving them stranded at a dead end, covering the main kinds you will meet, why they matter more than their size suggests, the anatomy of a good one, the tone and microcopy that carry them, the special case of no search results, error empty states, the mistakes we see most often, and a worked example you can copy the thinking from.

Why Empty States Punch Above Their Weight

The reason empty states matter so much is timing. A person almost always meets an empty state at the exact moment they know the least about your product. They have just signed up, or just opened a feature they have never used, or just tapped into a section that has not filled with their own content yet. There is no muscle memory to fall back on and no examples on screen to copy. Whatever you put there is doing the job of a first impression, a tutorial, and a signpost all at once. Get it right and the person feels oriented and capable. Get it wrong and they feel lost, and a lost person on their first visit is a person who quietly leaves.

There is a second reason, and it is about proportion. The populated version of a screen usually gets all the design attention, because it looks impressive in a portfolio and it is what everyone imagines the product looking like once it is thriving. But every single user starts at zero. The first time anyone opens your app, everything is empty. So the empty state is not the edge case, it is the universal case, the one screen that one hundred percent of your users are guaranteed to see. Designing it as an afterthought means designing the most common first experience as an afterthought.

The third reason is that empty states are a rare chance to teach without nagging. A good one sets expectations for what a feature does, shows the shape of the value the person is about to get, and points at the one action that unlocks it. It can carry a lot of the onboarding load that would otherwise need a modal tour or a coach mark, both of which people tend to dismiss on reflex. If you want to lighten the mental effort a product asks of people, the empty state is prime real estate, and it connects directly to the broader work of reducing cognitive load across a journey.

The Main Kinds Of Empty State

It helps to stop thinking of empty states as one thing, because they are not. There are at least four distinct kinds, and each one calls for a different message and a different action. The first is the first use or no data yet state. Nothing exists because the person has not created anything, so the job is pure onboarding: explain what this space is for and give them the one action that creates their first item. This is the most important kind to get right, because it is where a feature earns its keep or gets abandoned.

The second is the no search results or no filter matches state. Here the emptiness is not permanent and it is not the person’s fault in the usual sense. Data exists, it just did not match what they asked for. The job shifts from teaching to recovery: help them widen or correct the query so they can find what they were after. The third kind is the user cleared or all done state, which is what remains after someone has processed everything: an inbox with zero unread, a task list with nothing left, a notifications tray they have emptied. This one is genuinely positive, and it deserves a tone that acknowledges the accomplishment rather than treating the blank screen as a problem.

The fourth kind is the error empty state, where the screen is empty because something failed: a request timed out, a connection dropped, permissions were missing, a server hiccuped. This is the only kind where an apology is warranted, and even here the apology should be brief and the recovery action prominent. Lumping all four of these into one generic blank layout is the single most common structural mistake we see. A person who cleared their inbox and a person whose request just errored need very different words, and giving them the same words tells both of them that nobody thought about their situation.

The Anatomy Of A Good Empty State

Strip a strong empty state down and you find three parts, no more. The first is a clear visual: an illustration, an icon, or a simple graphic that signals the nature of the space and gives the eye somewhere to land. It does not need to be elaborate. Its job is to soften a blank canvas and hint at what belongs here, the way an empty picture frame on a wall still tells you a picture is meant to go there. A well chosen visual also reassures people that the screen is finished loading and is meant to look this way, which quietly answers the question a spinner leaves hanging.

The second part is one short line explaining what goes here. Not a paragraph, not a mission statement, one line that names the space and sets the expectation. Something like “Your projects will show up here” or “No invoices yet”. The person should be able to read it in a glance and understand both what the screen is and why it is currently empty. The third part is a single obvious next action, usually a button, that moves them from empty to not empty. Create the first project. Import your contacts. Send your first message. This is the part teams most often drop, and dropping it turns an empty state into a dead end.

Notice that this is a hierarchy, not a checklist to cram. The visual supports the line, the line supports the action, and the action is the point. If you find yourself wanting to add a second heading, a bullet list of tips, a video, and three buttons, you have lost the thread. The strength of a good empty state comes from restraint. It gives the eye one place to look and one thing to do, which is exactly the kind of clear affordance and immediate response we talk about in affordances and feedback. One clear path beats five hedged ones every time.

Tone And Microcopy That Carry The Screen

Because an empty state is mostly whitespace and a few words, the words matter more than they would anywhere else. There is nowhere for weak copy to hide. The first rule we hold to is to write to the person, not about the system. “You have not added any clients yet” is about the person and their next move. “No records found in the database” is about your plumbing, and nobody outside the building cares about your plumbing. Speak in the second person, name the thing in plain language, and keep the sentence short enough to read without slowing down.

The second rule is to match the tone to the kind of empty state. A first use screen can be warm and inviting, because you are welcoming someone in. An all done screen can be light and even a touch celebratory, because they earned it. An error screen should be calm, plain, and free of forced cheer, because a person who just hit a failure does not want a mascot winking at them. The mistake is to pick one voice, usually a jaunty one, and apply it to every situation regardless of how the person is feeling when they arrive. Read the room, then write the line.

The third rule is that the action label should describe the action, not the generic verb. “Add your first product” tells the person exactly what will happen. “Get started” or “Click here” makes them guess. Specific labels reduce hesitation because they let people predict the outcome before they commit, and a predictable button is a button people press. This is the same discipline that makes forms convert, and it is worth borrowing the habits from micro-copy tweaks that improve form completion when you write empty state buttons: concrete verbs, the person’s own vocabulary, and no filler.

The No Search Results Case, Specifically

No search results deserves its own treatment because it is the empty state people hit most often after they are already invested, and it is the one most commonly botched. The cardinal sin here is to wipe the query and dump the person back to a blank search box, forcing them to retype from memory and guess at what went wrong. Keep the query visible and editable. The person should be able to see exactly what they searched for and tweak it in place, changing one word or fixing one typo without starting over. Preserving the query respects the effort they already put in and turns a dead end into a small correction.

Beyond keeping the query, a good no results state suggests a way forward. If the search was too narrow, say so and offer to broaden it: drop a filter, remove a date range, search across more categories. If a filter combination produced nothing, show which filters are active and make each one easy to clear individually, so the person can loosen the constraints one at a time rather than resetting everything. When you can, offer alternatives: did you mean a close spelling, here are popular items in this category, here is what other people search for. Each of these turns a blank result into a next step.

It also pays to distinguish between “no results for this query” and “no data exists at all”, because they need different messages. If a person searches an empty catalogue, telling them to refine their search is nonsense, since nothing would match no matter what they type. In that situation the honest move is to say the catalogue is empty and point at whatever populates it. Getting this distinction right is partly a heuristics question, the sort of match between system and reality that runs through Nielsen’s ten usability heuristics, and partly just paying attention to which of the two situations the person is actually in before you write the message.

Error Empty States Without The Grovelling

Error empty states are where a blank screen meets a bad moment, so they carry the highest risk of losing someone. The person came to do something, and instead they got nothing plus a whiff that the product is broken. The goal is to steady them. Say plainly what happened in language they can act on: the connection dropped, the data could not load, you do not have access to this. Avoid raw error codes and stack traces as the headline, though a small technical detail tucked underneath can help the person who wants to report the problem or search for it.

The most important element in an error empty state is a recovery action, and it should be the most prominent thing on the screen. Usually that is a retry button, because a great many errors are transient and a single tap fixes them. If retry is not the answer, give the real next step: sign in again, request access, check your connection, contact support with this reference. What you must not do is present a failure with no way out, because a person staring at an error and no button has nowhere to go but away. Always leave a door open, even if the door is just trying again.

Tone here is a discipline of subtraction. Resist the urge to over apologise, because a long, hand wringing apology makes the failure feel bigger than it is and draws attention to your product’s fragility rather than the person’s path forward. One calm sentence of acknowledgement is plenty, then move straight to the recovery action. People forgive the occasional error quickly when the recovery is smooth. They remember the products that made a small failure feel like a wall.

The Mistakes We See Most Often

The first and worst mistake is the truly blank screen: a section that renders nothing at all when there is no content, so the person cannot tell whether the feature is broken, still loading, or simply empty. Ambiguity is the enemy here. A blank screen forces the person to form a theory about what went wrong, and the theories people form about your product are rarely generous. Even a single line of text that says “Nothing here yet” beats a void, because it confirms the screen is working as intended and the emptiness is expected.

The second mistake is the dead end: an empty state that describes the emptiness but offers no way to change it. “You have no invoices” is a fact, but on its own it is a shrug. Where does the person go from here? If the only path to creating an invoice lives in some other corner of the app, you have made them hunt for it at the exact moment they were ready to act. Every empty state that can lead to a next step should contain that next step, right there, as a button. The third mistake is over apologising, which we covered above but which shows up outside error states too, in first use screens that treat their own newness as something to be sorry about. Emptiness on first use is normal. Do not apologise for it, guide through it.

The fourth mistake is cramming three competing calls to action into one screen, usually because three different stakeholders each wanted their feature promoted. Import contacts, watch a demo, read the docs, upgrade your plan, all fighting for the same attention. The result is that the person does none of them, because a screen with five equal priorities has no priority at all. Pick the single action that most people should take next and make it the clear primary. If secondary paths truly matter, demote them visually to quiet links so the hierarchy stays obvious. This restraint is the same principle that underpins good form design for conversion: one clear primary path, everything else subordinate, nothing competing for the same click.

A Worked Example, Start To Finish

Picture a small business invoicing tool, and the screen a new user lands on the first time they open the Invoices tab. There is no data, because they have never made an invoice. The lazy version renders an empty table with column headers and nothing beneath them, or worse, a bare grey panel with the word “No data” in the corner. The person sees an interface built for a situation they are not in yet, feels the friction of not knowing where to begin, and either pokes around hoping to stumble onto the right button or gives up and closes the tab.

Now the guided version. In the centre of the space sits a simple illustration of a document, enough to signal that invoices live here and to reassure that the screen finished loading. Below it, one line: “You have not created any invoices yet.” Below that, one short supporting sentence that hints at the value: “Send a professional invoice in under a minute and track when it gets paid.” Then a single primary button: “Create your first invoice.” No demo video fighting for attention, no upgrade banner, no three column feature grid. Just the one action that turns this empty screen into a working invoice list. If there is a genuinely useful secondary path, say importing invoices from another tool, it sits underneath as a quiet text link, clearly subordinate to the main button.

Now carry the same feature through its other empty states, because they are not the same screen. Once the person has a hundred invoices and searches for “Acme” and finds nothing, the no results state keeps “Acme” in the box, shows it was searched, notes that no invoices match, and offers to clear the search or check the spelling, rather than dumping them back to an empty field. When they filter to “overdue” and everything has been paid, the all done state says something like “Nothing overdue. Every invoice is paid up.” with a lighter tone, because that is genuinely good news worth acknowledging. And if the list fails to load because the connection dropped, the error state says “We could not load your invoices” in one calm line, puts a prominent “Try again” button front and centre, and tucks a small reference underneath for support. Same feature, four empty states, four different jobs, each one a signpost instead of a wall.

A Short Checklist Before You Ship

Before an empty state goes live, walk it against a few plain questions and you will catch most of the trouble. First, is it obviously not broken? A person glancing at it should understand the screen is working and the emptiness is expected, not that something failed silently. Second, does it say in one short line what this space is for and why it is currently empty, in language about the person rather than about your system? Third, is there a single obvious next action, and is it labelled with the specific thing it does rather than a generic “get started”? If you cannot point to that one action, you probably have a dead end.

Then check the specifics per kind. For no search results, is the query still visible and editable, and have you offered a way to widen, correct, or clear it, and have you distinguished “no match” from “no data at all”? For error states, is the recovery action the most prominent element, and have you resisted the urge to grovel? For all done states, does the tone acknowledge the accomplishment instead of framing zero as a problem? And across every kind, have you avoided the four classic traps: the truly blank screen, the actionless dead end, the over apology, and the pile up of competing calls to action.

Last, sanity check the tone against the moment. Read the line out loud and ask whether it fits how the person feels when they arrive, welcomed on first use, calm on an error, lightly congratulated when they have cleared the decks. Empty states are small, but they are seen by everyone, at the moments they know the least and decide the fastest. Treat them as the signposts they are, and the blank screens in your product stop being places people get stuck and start being the places that move them forward.