The first thing a new user sees inside almost any product is an empty state. The dashboard has no widgets yet, the inbox has no mail, the project list has no projects, the analytics chart has no data. The empty state is the product's introduction to a new account, and it is also the quiet failure case on every page that an established user visits when something they expected to see is not there.
Most empty states apologize. They show a sad illustration, say "Nothing here yet," and offer a single call to action. That works in a demo. It does not work the third time a returning user sees it. This piece walks through what an empty state is actually for, what the patterns that hold up across products have in common, and the small decisions that separate an empty state that earns trust from one that wastes a user's time.
Photo by MESSALA CIULLA on Pexels
What an empty state is actually for
An empty state is not a "no data" message. That framing reduces a real piece of product UI to a placeholder, and the placeholder framing is why so many empty states are sad illustrations with three sentences of generic copy.
A good empty state does three jobs. It tells the user what this screen is for. It tells the user what they need to do to put real content here. And it acknowledges, when relevant, why the screen is empty in this specific moment, so the user can decide whether to act, wait, or look elsewhere.
The first job, the "what this screen is for" job, is the most often skipped. New users land on an empty inbox and the product assumes they already know that this is the place mail will appear. A new account on a calendar app sees a blank week and assumes calendars work the way they have on every other tool, which is sometimes true. The empty state is the cheapest place to explain the screen's job, because there is no real content competing for attention. Skipping the explanation makes the rest of the onboarding journey work harder than it has to.
The second job, the "what to do next" job, is the one most products try to do. A button labeled "Create your first project" or "Connect a data source" is the canonical pattern. It usually works for the first one or two clicks, then loses meaning as the user comes back to the same empty page expecting different behavior.
The third job, the contextual explanation, is the rarest and the most valuable. An empty inbox at the top of the morning is normal. An empty inbox at 11 AM on a workday is suspicious. The difference between "your inbox is empty" and "your inbox is empty because your IMAP connection has not synced in 45 minutes" is the difference between a calm user and a confused user looking for the support chat widget.
The three audiences for the same screen
The reason empty states are hard is that the same screen has at least three audiences, each with different expectations.
The new user has never seen this page before. They need orientation, an example of what real content looks like, and a clear next step. The information density should be high enough to teach but not so high that it feels like a tutorial overlay.
The returning user with a real-world reason for the empty state, such as a fresh sprint with no tasks, knows what this screen is and knows why it is empty. They want minimal copy, a way to add content if they choose, and a fast exit if they were just checking.
The returning user with an unexpected empty state, such as a dashboard that should have widgets but is showing the placeholder instead, is suspicious. They want to know what is wrong. Was their content deleted? Did a filter get applied accidentally? Is the data source disconnected? An empty state that ignores this third audience pushes them to support before debugging anything themselves.
A single empty state that serves all three is what most products try to build, and it is often the wrong target. A better pattern is to detect the audience from session signals (account age, last activity, filter state, data source status) and show a slightly different empty state to each.
What the good empty states have in common
After watching the same kinds of empty states ship over and over across products, the ones that hold up have five consistent traits.
They name the screen. "This is your team's task board" or "Your customer activity feed" sits at the top of the empty state. The user does not have to remember which navigation item they clicked to know what they are looking at.
They show a single, accurate next action. Not three buttons. Not a feature tour. One thing the user can do right now to make this screen useful. A "Create your first project" button is fine. A "Create project, import from Trello, watch tutorial, talk to sales" combo is not.
They tell the truth about why the screen is empty. If the user has filters applied and the result set is empty, the empty state says so and offers a clear filter-reset action. If a data source is disconnected, the empty state says so and links to the connection settings. The placeholder framing without the context is dishonest, and users notice.
Photo by Walls.io on Pexels
They are not the same empty state on every screen of the product. A products app and an analytics dashboard and a settings tab have different reasons to be empty, and the copy and call to action need to reflect that. A generic "Nothing here yet" template applied uniformly across a product is a sign that nobody owned the empty-state work and it was decided at the framework level.
They are quiet. The animated illustrations, the cheerful copy, the exclamation points are all signs that someone tried to make the empty state feel friendly. Returning users find the cheerfulness exhausting. The honest version of an empty state is short, factual, and respectful of the user's time. The pattern was documented well in the Nielsen Norman Group's research on empty states, which has held up since the early 2010s.
Three patterns that come up most often
In practice, the empty states that need the most care fall into three buckets.
The first-run empty state. This is the new user landing on a feature for the first time. The screen has never had data on it. The right answer is usually a high-information empty state that names the screen, shows a sample of what real content will look like, and offers one clear action. Some products use a "seed with sample data" button here, which works for some categories (project tools, CRMs) and not others (analytics, financial dashboards) where fake data would be misleading.
The temporary empty state. This is the returning user on a screen that is empty for a legitimate reason: the sprint is over, the inbox got cleared, the filter is set strictly. The right answer here is low-information. Show that the screen is empty, optionally show what would put content back, and get out of the way. The longer guide on the Apple Human Interface Guidelines for empty views covers a similar discipline for native iOS and macOS apps, and the same principle applies on the web.
The most expensive empty states are the ones that lie. A dashboard showing "no data" while a backend integration is broken trains a user to stop trusting the dashboard. - Dennis Traina, founder of 137Foundry
The error-as-empty-state. This is the screen that looks empty because something is broken, but the product is not telling the user that. The data source is disconnected, the API call timed out, the filter is set in a way that excludes everything. The right answer is to detect the situation and tell the user. Showing a generic "no data yet" message when the actual reason is a broken integration is the cheapest way to lose trust in a product that you can engineer.
The role of empty states in onboarding
Empty states do a disproportionate share of the onboarding work in a modern product. The reason is that most users skip the tutorial overlay, dismiss the welcome modal, and ignore the help tooltip. The empty state is the only piece of onboarding UI that the user cannot dismiss, because it is the actual content of the screen until they put something there.
That makes the first-run empty state the highest-leverage onboarding surface in most products. It is also the place where the design and engineering effort tends to be lowest, because it ships once and rarely gets revisited. Teams that take this seriously assign a dedicated review to first-run empty states across every primary screen of the product, and they revisit it whenever the feature itself changes meaningfully.
The Material Design system's guidance on empty states in the Material 3 spec covers the visual conventions clearly. The conventions are less interesting than the discipline of taking each empty state seriously as a piece of product UI, not as a placeholder. The web platform documentation on accessible status messaging in the MDN Web Docs reference covers the related accessibility work that good empty states do for screen reader users.
Common failure modes
Three failure modes show up over and over.
The first is the empty state that has not been touched since the feature shipped. The product has matured, the feature has new capabilities, but the empty state still says "Welcome to feature X! Click here to create your first widget." The mention of "first" is the giveaway: returning users see that copy and feel slightly insulted. The fix is to write copy that reads as well on visit one as on visit fifty.
The second is the empty state that is too generic. A "No items found" message attached to every empty list in the product loses the chance to teach the user anything about the list they are looking at. Each list has a different purpose. Each empty state should reflect that purpose.
The third is the empty state that is too noisy. Five paragraphs of marketing copy, three calls to action, an animated GIF, and a help center link. The user came to do work. The empty state is in the way of either doing the work or knowing why the work is not available. Cut everything that is not one of the three jobs from the start of this piece.
Photo by Alexey Demidov on Pexels
How to audit your existing empty states
The fastest way to find empty-state work worth doing in an existing product is to do a screen-by-screen audit. The audit is short.
Pull up every primary screen of the product. For each, set the user state to "new account, no content" and look at the empty state. Note whether it names the screen, shows a clear next action, and is honest about why the screen is empty.
Then set the user state to "established account, filters applied, no result." Look at the empty state. Is it the same screen as the new-user version? In most products, the answer is yes, and that is the bug. The filter-result-empty case is different from the new-user case and should look different.
Then check the error case. Disconnect a data source, force a timeout, simulate an integration failure. Look at the screen. Does it show the empty state or does it show an actual error? The empty state is the wrong answer here. The right answer is a clear error message that explains the situation and offers a recovery path. Teams skip this audit because it requires switching session state in ways that take engineering setup. The audit is the part of the work where the most user-trust improvement comes from the least design effort.
For teams that want a structured way to ship these improvements alongside their product engineering, 137Foundry's web development service does this kind of empty-state and recovery-path audit as part of the broader UI work on a product.
The short version
Empty states are not placeholders. They are real product UI that does three jobs: name the screen, offer a next action, and explain context when relevant. The good ones differ by audience and by reason for emptiness. The bad ones apply a single sad-illustration template across every screen and assume the user will figure out the rest.
Audit the empty states in your product the way you audit any other screen. Most teams find ten quick wins in the first hour. Most of those wins are not visible to anyone who already knows the product, but they are extremely visible to the new user landing on the screen for the first time and the returning user who hit an unexpected empty state and is wondering whether to call support.
For more on UI patterns that hold up across product complexity, see the related work in 137Foundry's about page or browse the practical write-ups on 137Foundry.
