Empty states as a design problem

A user who has never seen this page before needs three things, in this order: to know what the page is for, to see one thing they can do, and to have a cheap way to get started without a blank canvas.

The pattern I reach for:

• A one-sentence explanation. What is a project in this app? What does having one let you do? The text under “start your first project” is the most-read sentence in the product.
• A primary action. One button, bold, named after the thing. “New project,” not “Get started.”
• An on-ramp. A template, a sample import, a “show me yours” example. Starting from nothing is harder than starting from something.

The mistake is treating this like a null state. “No projects yet” is a failure message. “Start your first project” is the first step of onboarding. They look similar. They’re not.

A user with two items has committed to the product just enough to be disappointed by it. The populated design assumes abundance. Show a sparse user a toolbar built for filtering twenty items and the UI feels out of proportion to their situation.

Two moves fix it:

• Hide the toolbar until it earns its place. Search, filters, bulk actions: none of them help someone with two items. Fade them in once the list crosses a threshold (5? 10?). Until then, the layout breathes.
• Keep an on-ramp visible. A dashed “new project” tile sitting alongside the existing ones suggests the next move. It’s not pushy. It’s there when they’re ready.

The sparse state is also where habits are formed. If the second project is as easy as the first, the third one becomes likely. Designing for the third project is designing for retention.

Most teams design here first, and the design expands with the feature set. Filters grow, bulk actions multiply, a search gets added, a sort. By the time the user has twenty items, the toolbar has six controls and the content has less room than the chrome.

Two questions for any populated state:

• What does a power user actually do? Probably search, not filter. Probably reorder, not bulk delete. Design the 80%-case UI for that and tuck the rest behind a menu.
• What degrades gracefully? When the list hits 100 items, does the page still feel calm? When it hits 1,000, does it still load? The answer to both should be yes, and it usually isn’t unless someone pushed.

A surprising number of products render the same screen for “you have no projects” and “we couldn’t load your projects.” The first is an invitation. The second is a failure. Treating them the same is how users end up clicking “Create new” while your API is down.

Three distinct states to design:

• Empty. Inviting. “Start your first.”
• Filtered empty. “No matches for ‘onboarding’.” Clear filter as the primary action.
• Error. Apologetic. “We couldn’t load this.” Retry as the primary action. A link to status page.

One is a welcome mat. One is a diagnostic. One is an apology. They look different, they use different language, they offer different actions.

Seed data.

When a new user lands, consider pre-populating the feature with one sample project, titled clearly (“Welcome to Nexus”) and marked as sample. They can delete it in a click. What they can’t do otherwise is see what the populated state looks like for their account.

This is controversial. Some teams treat seed data as dishonest. It isn’t, if it’s labelled. It’s the difference between handing someone a blank page and handing them an example to remix. Most users want to remix.

A product designed only for the populated state is designed for users it doesn’t have yet. Start at zero. Design the first screen a new user sees as carefully as the hero. Then design for two items, three, five. By the time the list is populated, the design has earned the chrome you give it.

The empty state isn’t a fallback. It’s the product’s introduction.