2026-09-26 · 7 min · By Alcott Dube
How to design empty states that teach the next step
I design empty states around one useful action, with enough context to explain the blank screen and help someone make their first meaningful contribution.
I design empty states to explain why nothing is there, identify the next useful action, and show what that action will produce. Teaching happens when someone can complete a small, real task from the empty screen, without reading a separate introduction.
Identify why the screen is empty before designing it
I start with the cause, not the illustration. A new account, a search with no matches, a cleared task list and a failed request can all leave the same rectangle blank. They need different responses. Treating them as one component with interchangeable headlines is where empty state design usually goes wrong.
For each empty surface, I write down what the person was trying to do, why the content is absent, and which actions they can actually take. A new project owner might need to create a task. A collaborator might need an invitation. Someone without viewing permission needs an explanation, not a creation button that fails.
Nielsen Norman Group's guidance on empty states treats these screens as opportunities to explain the system and support progress. I turn that into a simple design constraint: every message must describe the current condition accurately. If data hasn't loaded, I don't call the collection empty. If work is complete, I don't imply something is missing.
Choose one first action that produces something useful
I choose the smallest action that produces a result worth keeping. In a project tool, that might be adding a task with only a title. It probably isn't completing a profile, inviting five colleagues or configuring notification rules. Those steps may matter later, but they don't explain why the project screen exists.
Shopify Polaris's empty-state guidance centres on useful context and a clear next action. I apply that by giving one action visual priority. For an empty product catalogue, I'd make “Add a product” primary and keep “Import products” secondary when both routes are supported. Two equally prominent buttons ask a new user to resolve a decision before understanding it.
The destination matters as much as the button. If “Create a project” opens a form with twelve required fields, the empty state hasn't simplified onboarding. It has advertised a short task and delivered a long one. I'd challenge those requirements, preserve sensible defaults and make optional configuration available after the first saved result, rather than hiding the cost.
Write empty state copy that explains the next step
My default copy structure is a heading that names the condition, a short explanation of the outcome, and a button that names the action. For a saved-report area, that could be “No saved reports”, followed by “Save a report to reuse its filters next time.” The action is “Create a report”, not “Get started”.
I keep instructions tied to the actual flow. If reports can only be saved from search results, “Create a report” is misleading. I'd use “Run a search” and explain that saving comes next. Good copy cannot repair a false promise between screens. I check the destination and the return state before polishing any of the words.
I remove apologies unless something has genuinely failed. I also remove cheerful judgements about how easy a task will be. A useful detail earns its space: “Only you can see this draft” might remove a real hesitation. “Your brilliant ideas belong here” tells someone nothing about the product or the consequences of clicking.
Use examples to teach what belongs on the screen
An empty screen removes the clues that populated screens normally provide. A list of expenses teaches its own structure through dates, merchants and amounts. Without those rows, a first-time user may not know what counts as an entry. I add a compact example when that uncertainty could prevent the first action.
This follows Nielsen Norman Group's recognition-over-recall principle: make relevant information available rather than requiring people to remember it. For an automation builder, I'd show a sample relationship such as “When a form arrives, create a task”. That explains the underlying model more efficiently than a paragraph listing every supported trigger and action.
Examples need an honest boundary. I label sample content and keep it out of real totals, exports and notifications. If a sample can be edited into a real item, I make that transition explicit. Otherwise, people may spend time deleting demonstration records or mistake invented activity for work a colleague has already done. I skip decoration that competes with this explanation.
Design different empty states for search, completion and errors
A first-use message should disappear once it no longer describes the situation. Someone who deletes their last saved report doesn't need another introduction to reporting. I usually switch to a neutral message and retain the creation action. Historical use can inform that choice, but I wouldn't build elaborate personalisation just to change a sentence.
For search, I show that no results matched the current query or filters, and keep those controls available. “Clear filters” is useful only if filters are contributing to the restriction. I preserve the search text so it can be edited. I don't replace the whole results area with generic onboarding or suggest creating records by default.
Completion deserves a different response again. An empty approval queue can simply say there is nothing waiting for review. A failed request needs recovery, such as retrying, without claiming that no approvals exist. I specify loading, empty, populated, error and permission states together so the implementation doesn't quietly turn every unsuccessful response into a zero count.
Build accessible empty states without adding friction
I use ordinary page structure: a meaningful heading, readable text and a correctly labelled control. Navigation uses a link; an action such as opening a dialog uses a button. The illustration carries no essential instruction. If it only repeats the message visually, I mark it as decorative rather than making screen-reader users listen to an unnecessary description.
When a search changes the results to zero, I keep keyboard focus predictable and expose the updated status to assistive technology. I don't move focus to the empty-state heading after every filter change. If deleting the last item removes the focused control, I specify a sensible focus destination instead of leaving that behaviour to chance.
I test the layout with long translations, enlarged text and a narrow viewport. The action should remain associated with its explanation, not drift below a giant image. I also check loading transitions with a slow connection. Flashing “No projects yet” before existing projects appear is an avoidable contradiction, even if it lasts less than a second.
Measure empty state success beyond button clicks
I measure progress from exposure to a meaningful result. For the task example, that means recording when the empty state appears, when creation starts, when a task is saved and when the project displays it. I compare unique users who saw the state with those who completed the task, using a stated time window.
Button clicks alone can reward vague copy or conceal a difficult form. I also look at abandonment after the click, validation failures and time to the first saved item. I separate first-use screens from filtered results and completed queues. Combining them would mix situations where creation is desirable with situations where doing nothing is perfectly correct.
Before running an experiment, I'd test the proposed state with five people unfamiliar with the flow as a small qualitative check, not a conversion estimate. I'd ask them to explain what the screen means and complete the next task without prompting. If they choose the right action but stall in the form, I'd fix the form before testing another headline.
Questions people ask
What is an empty state in interface design?
An empty state is what a screen or component displays when there is no content to show. I distinguish between first use, no matching results and completed work because each needs a different explanation.
What should an empty state include?
I include an accurate explanation and, where useful, one clear next action. Supporting copy or an example should resolve a specific uncertainty. An illustration is optional, not a requirement.
Should every empty state have a button?
No. I add a button only when there is a useful action the person can take. A completed review queue may need only confirmation, while a permissions restriction may need instructions for requesting access.
Can empty states replace onboarding tours?
I use empty states instead of tours when a small task can teach the screen's purpose in context. They don't replace explanations of complex dependencies, permissions or irreversible actions that need attention before work begins.