Empty states are worth designing on purpose, not leaving to a placeholder

Empty states, the screen a user sees before they've added any data, saved anything, or built up any history in a product, are among the most commonly seen screens for a brand new user, and among the least designed. Left as a generic placeholder, they quietly communicate that the product is broken or unfinished at the exact moment a new user is deciding whether to trust it at all.

A bare "No items found" message with no further guidance reads as a dead end rather than a starting point. New users interpret an unexplained blank screen as evidence something's wrong, not as an invitation to take the next action, even when the screen is behaving exactly as intended for someone who hasn't used the product yet.

We design empty states with a clear explanation of what will appear there once populated, and a direct call to action for the specific step that fills it. A project management tool's empty task list, for example, should explain what a task is in this product's context and offer a single obvious button to create the first one, not just state flatly that none exist yet.

A true first-use empty state, before a user has done anything, calls for an encouraging, instructional tone. An empty state from a filtered search that found nothing needs a different message entirely, confirming the filter worked as expected and offering a way to broaden it, rather than implying the whole product is empty when it isn't.

Adding a simple illustration or icon to an empty state, rather than leaving it as plain text, measurably improves how new users perceive the moment, turning what could read as an error into something that feels like a deliberate, designed part of the product experience rather than an oversight nobody got around to fixing.

Redesigning a project management tool's empty task list from a bare "no tasks" message to an illustrated state with a clear explanation and a prominent "create your first task" button increased first-session task creation by a meaningful margin, based on before-and-after usage data over a comparable period.

An empty state resulting from an actual error, a failed data load, needs to clearly communicate that something went wrong and offer a retry action, distinct from a genuine "nothing here yet" empty state. Conflating the two, showing the same generic message for both situations, confuses users about whether they need to act or simply wait.

Designing the empty state early, rather than as an afterthought once the populated version is finished, forces useful early thinking about exactly what a first-time user needs to understand before any real data exists, which sometimes reveals gaps in the onboarding flow leading up to that screen.

Across projects we've converged on a consistent three-part pattern for empty states: a brief explanation of what belongs here, why it's currently empty, and one clear primary action to change that. Consistency in this pattern across a product's various empty states makes the whole experience feel more considered.

A B2B admin interface's empty states can afford to be more informational and less playful than a consumer app's, since the audience and context are different, someone setting up a business tool generally wants efficient guidance over personality. We calibrate tone to the product's actual audience rather than applying one house style everywhere.

We audit every empty state across a product as a single pass, specifically checking for consistent tone and pattern, since empty states built by different people at different times tend to drift into inconsistent styles unless someone deliberately reviews them together as a complete set.

Existing users who've been through onboarding once tend to understand what an empty state means from context, which can mask real confusion a first-time user would experience seeing the exact same screen. We specifically recruit genuinely new-to-the-product participants for empty state usability testing, since testing with people already familiar with the product systematically understates how confusing a generic empty state actually is to someone encountering it cold.

We also think about empty states as an opportunity for subtle brand personality, within reason, since this is a moment where a product can feel more human without adding real friction to a user's task. A well-chosen bit of encouraging, on-brand copy in an empty state costs nothing extra to implement once the underlying content and action guidance are already planned, and it's one of the easiest, lowest-risk places in a product to let a brand's actual voice come through in a way that feels natural rather than forced into a screen where it doesn't belong.

A dashboard made up of several distinct widgets, a recent activity feed, a summary chart, a task list, can end up with several empty states firing simultaneously for a genuinely new user, which risks the whole screen reading as broken or unfinished if each one is designed in isolation without considering how they look together as a group.

We review a dashboard's full set of empty states together as a single, coordinated experience rather than designing each widget's empty state independently, since a screen with four or five separate "nothing here yet" messages stacked on top of each other reads very differently, and considerably worse, than a screen with one clear, prioritized explanation of what to do first to start populating the whole dashboard at once.