Empty-state copy that earns action

Empty states are not blank space. They are product explanations at the moment the interface has no content to show.

The mistake is writing empty states like brand moments. A clever headline can be charming, but the user usually needs orientation first.

Say what happened

Start with the literal state. No invoices match these filters. No teammates have joined this workspace. No reports have been generated. No orders have synced yet.

That sentence prevents the user from wondering whether the product is broken, still loading, or hiding data because of permissions.

Explain why it matters

The second line should explain the product implication. If there are no reports, the user cannot compare performance yet. If there are no teammates, work cannot be assigned. If no orders synced, the dashboard will stay empty.

This does not need to be dramatic. It needs to connect absence to the user's goal.

Offer one primary next step

Empty states get weaker when they offer too many choices. Pick the action that most directly creates value.

Connect store. Invite teammate. Clear filters. Create project. Import CSV. Start report.

Secondary links can exist, but the primary action should be obvious.

Match tone to consequence

An empty inspiration board can be playful. An empty billing history should be plain. An empty error log can be reassuring. An empty permissions screen should be precise.

Tone should follow consequence. The more operational the surface, the less the copy should perform.

Avoid fake celebration

Some empty states overdo encouragement. "You're all caught up!" can be right for a queue. It is wrong when the product has not connected data yet. "Nothing to see here" can sound casual, but it may also make the user wonder whether they missed a setup step.

The copy should respect the user's uncertainty. If the product is empty because work is complete, celebrate quietly. If it is empty because setup is incomplete, be direct about the missing step.

Separate true empty from filtered empty

Filtered empty states need different copy from first-use empty states.

"No matching customers" should offer filter recovery. "No customers yet" should offer creation or import. If those states share copy, the product gives the wrong next step.

A simple structure

I usually write empty states like this:

• Title: what happened.
• Body: why it matters.
• Primary action: create or recover.
• Optional secondary: learn more or change context.

Example:

No invoices match these filters.

Try a wider date range or clear filters to return to all invoices.

That pattern also helps design. The layout can stay compact because the copy is doing specific work instead of trying to sound impressive.

That is not exciting copy. It is useful copy. Useful is the point.

Empty states are product routing

An empty state is not just a blank place with a friendly sentence. It is a routing decision. The product is deciding where the user should go next, what they should understand, and whether the current absence is normal, fixable, filtered, blocked, or broken.

That is why I do not start empty-state copy with tone. I start with diagnosis. Why is this area empty?

• The user has not created anything yet.
• The filters removed everything.
• The integration has not synced.
• The user lacks permission.
• The product is waiting for another person.
• The system failed to load.
• The feature is not available on this plan.

Those situations deserve different interfaces. A generic "Nothing here yet" is usually wrong for at least half of them.

NewTeach the first action

Explain what will exist here after setup.

FilteredShow the active constraint

Help the user widen or clear the current view.

BlockedName the missing requirement

Permissions, plan limits, sync status, or external ownership.

The copy formula I trust

For most product surfaces, I use a simple structure:

1. State what happened.
2. Explain why it matters.
3. Offer one next action.
4. Keep secondary education nearby, not in the headline.

For example:

"No matching invoices. This view only shows overdue invoices from the last 30 days. Clear filters or widen the date range."

That sentence is not cute, but it is useful. It tells the user the data did not vanish. It points to the constraint. It gives a recovery path.

The weak version is:

"No invoices yet. Create your first invoice."

That might be correct for a new account, but it is wrong for a filtered table. Bad empty-state copy creates support questions because it misdiagnoses the product state.

Empty states should preserve context

When a table, report, or dashboard is empty, I want the surrounding frame to stay visible. Keep the filter bar. Keep the column labels when they help. Keep the selected workspace, date range, or segment. The user needs to understand what produced the absence.

This is especially important in admin and analytics products. If the chart disappears completely, the user cannot tell whether the issue is data, filters, permissions, or a broken integration. A good empty state keeps enough structure on the page to make the missing data legible.

I like empty states that say, in effect: "Here is the room you are in, here is why it is quiet, and here is the door."

One action, not a menu of hope

Empty states often become dumping grounds for every thing the product wishes the user would do: create, invite, import, read docs, watch a video, contact sales, browse templates.

That is not helpful. It is the product avoiding a decision.

Pick one primary action. If the state is new, maybe it is "Create project." If the state is filtered, maybe it is "Clear filters." If the state is blocked, maybe it is "Request access." If the state is waiting on sync, maybe it is "Check integration status."

Secondary links can exist, but they should not compete with the recovery path.

The states I write before polish

I write these before I design the final card:

• First-use empty.
• Filtered empty.
• Permission empty.
• Sync pending.
• Broken integration.
• Archived or removed content.
• Search with no result.
• Plan limit or upgrade required.

Each one gets a rough sentence. If the sentence is hard to write, the product state is probably unclear. That is a useful discovery.

For example, "No customers found" might become:

• "No customers yet. Import a CSV or create the first customer manually."
• "No customers match 'acme' in Enterprise accounts."
• "You do not have access to customer records in this workspace."
• "Customer sync is still running. The first records usually appear in two minutes."

Same empty surface. Four different product truths.

Empty states are also analytics

I like tracking empty states because they show where the product fails to route people. If users keep landing in filtered empty states, maybe the default filter is too narrow. If people hit permission empty states, maybe invitation roles are unclear. If search no-results is common, maybe object names and product language do not match.

The event does not have to be complicated:

track("empty_state_viewed", {
  surface: "invoices_table",
  reason: "filtered",
  filters_count: 3,
});

The goal is not surveillance. It is to learn which absences cost people time.

The final pass

Before shipping, I ask:

• Does the headline correctly diagnose the state?
• Does the surrounding UI preserve enough context?
• Is there one obvious next action?
• Would this still make sense to a new teammate?
• Does the copy avoid blaming the user?
• Can support use the sentence to explain the behavior?

An empty state earns action when it reduces uncertainty. It should feel calm because the product is being clear, not because the copy is trying to be charming.

Examples I would rewrite

Here are a few empty states I see often and how I would tighten them.

Generic:

"No data yet."

Better:

"No revenue data has synced for this date range. Connect Stripe or choose a range after your first transaction."

Generic:

"No results."

Better:

"No customers match these filters. Clear the plan filter or search all accounts."

Generic:

"You cannot access this page."

Better:

"Only workspace admins can manage billing. Ask an admin to update your role or open the invoices page instead."

The difference is not voice. It is diagnosis. Each stronger version tells the user what condition created the empty state and what path remains open.

I also like writing the support version of the sentence. If a customer asks, "Why is this blank?" the support team should be able to reuse the interface language. That is a good test of clarity. If support has to invent a better explanation, the product copy is underwritten.

Another useful test is whether the empty state still works after the first month of product use. A lot of onboarding empty states assume a brand-new account. But products also have empty states for churned data, cleared filters, expired integrations, plan changes, deleted records, and permission changes. The copy should know which absence it is talking about.

Empty states are small, but they carry a lot of product responsibility. They are often the first time a user discovers how the system thinks. If that moment is specific, the product feels trustworthy. If it is generic, the user starts guessing.

A final copy check

Before shipping, I read the empty state out loud with the page context included. "In the invoices table, no invoices match these filters." "In the integrations page, customer sync is still running." "In the admin settings page, only owners can change billing."

If the sentence sounds like it could belong anywhere, it is too generic. If it names the surface, condition, and next step, it is usually close.

That is the level of specificity I want. Not clever. Useful.