The Empty State Discipline

What you actually need to know

• Every empty state is an onboarding moment. If it does not tell the user what to do next, it is a missed activation opportunity.
• The call to action in an empty state should be the most specific, direct action possible. Not "get started" but "create your first project."
• First-run empty states and user-cleared empty states need different copy. The experienced user who cleared their list does not need the explanation the new user needs.
• Illustrations in empty states are optional. Clear copy with a clear call to action is not optional.
• Audit every empty state in the product quarterly. They change less frequently than features but can become stale and misleading.

The core argument

Empty states are the invisible feature. Every product sprint has a list of things to build: new functionality, design improvements, bug fixes. Empty states sit at the intersection of design and product and are usually cut when the sprint gets tight. The feature ships with a generic "No items found" message in a component that the team will return to and improve "later."

Later almost never comes. The empty state lives in production with the generic message for months or years. Every new user who encounters it sees the moment the team stopped caring about their experience.

The products that take empty states seriously get a measurable return. The activation metric for features with well-designed empty states is meaningfully higher than for features with generic ones. The reason is straightforward: the user who understands what to do next does it. The user who sees "Nothing here yet" opens a new tab and looks for something they know how to use.

This is not a design luxury. It is an engineering and product discipline that directly affects whether new users activate. The implementation takes hours, not days. The return is visible in the onboarding funnel.

The anatomy of a good empty state

A well-designed empty state answers three questions: what is this space for, why is it empty right now, and what should I do.

Context. A brief explanation of what belongs in this section of the product. "Your projects will appear here" is better than "Nothing here yet." "Invoices you send will appear here" is better than "No invoices." The context tells the user they are in the right place.

Explanation. Why is it empty? For a first-run state, the explanation is simple: "You haven't created anything yet." For a filtered state, the explanation is about the filter: "No projects match 'active status.'" For an error state, the explanation is about what went wrong. Each context needs its own explanation.

Call to action. The specific next step. "Create your first project" with a button that opens the project creation flow. "Add a team member" with a link to the settings page. The CTA must be directly available from the empty state, not a description of where to find the action.

The optional addition for first-run states: a brief value statement that reinforces why creating the first item is worth doing. Not a marketing pitch. A specific description of what changes when the space is filled. "Once you invite your team, you can assign tasks and track progress together."

The different empty states in a typical SaaS product

A product with ten features has at least ten empty states, and most of those features have multiple types. Auditing them comprehensively reveals the scope of the work.

Dashboard empty state. The first thing a new user sees after signing up. This is the most important empty state in the product. It should immediately tell the user what the product does for them (not what it is) and give them the single most important first action to take.

List and table empty states. Every list and table in the product has an empty state. Projects list, tasks list, invoices table, activity log. Each needs specific copy that explains what belongs in that list and how to add the first item.

Search and filter empty states. These are different from first-run states. The user has performed an action (searched or filtered) that returned no results. The empty state should explain that no results match the current query and provide a way to modify the query or clear the filter.

Report and analytics empty states. Reports that depend on activity data cannot show anything until there is activity. The empty state for a report should explain what data will populate it and what the user needs to do to generate that data.

Common mistakes teams make with empty states

1. Using the same empty state component for every context in the product. The first-run state, the filtered state, and the error state need different copy. One component with generic copy serves none of them well.
2. Designing empty states without a call to action. An explanation without an action leaves the user with context but no path forward.
3. Using illustrations that do not relate to the product. A generic illustration of a clipboard or a magnifying glass adds nothing. If you use an illustration, it should relate to what belongs in the empty space.
4. Not testing empty states as part of the product's onboarding flow. The empty states are part of the onboarding experience. They should be in the onboarding testing checklist.
5. Not updating empty states when the product's terminology or features change. An empty state that references a feature by an old name is confusing to new users who only know the current name.

Where to start: a 3-step empty state audit

Step 1: List every empty state in the product. Use the app as a new user would experience it. Note every screen where data could be absent. For each one, record the current copy and whether a call to action exists.

Step 2: Classify each empty state by type. First-run, filtered, cleared, error. Each type needs different copy. Identify which current empty states use generic copy that does not serve the specific type.

Step 3: Rewrite and ship the three highest-impact empty states first. Prioritize by which features new users encounter first in the onboarding flow. The dashboard and the first major feature's list are usually the highest impact. Ship improved empty states for these three before moving to the rest.

The Product Details That Build Trust

Yashveer Singh. Founder of Yashveer Labs. The empty state is a product detail. It is also the difference between a product that feels polished and one that feels unfinished. I build products with the empty states designed from the start, not added later. If you are building a product and want someone who treats the details with the same care as the features, the work I do reflects that.

Related reading

• The Customer Onboarding Automation Map
• The Accessibility Audit Every Web App Should Pass
• The AI Onboarding Assistant: A High-Value SaaS Feature
• The Build Measure Learn Loop for Engineers