Building an app with a genuinely empty state and making it feel intentional

Every product with user-generated data, workouts logged, projects created, transactions recorded, has a first moment where a brand-new user sees a genuinely empty screen: no history, no data, nothing to show yet. This state gets designed as an afterthought more often than any other screen in a product, and it's one of the most consistently under-invested moments in mobile app design.

A poorly designed empty state, a blank screen with no explanation, or worse, an error-looking state that implies something's broken, is often the very first real screen a new user sees after completing account setup. It's setting the tone for the entire product experience at the exact moment a user has the least context and the least patience for confusion.

It explains clearly what will appear here once the user takes action, gives a specific, direct call to action to take that first step, and ideally shows a visual example or illustration of what the populated state will eventually look like, so the user has a concrete mental model of where they're headed rather than an abstract description.

The workout history screen previously showed just the text "No workouts yet" with no further guidance. We redesigned it to show a sample workout card, visually marked as an example, alongside a clear "log your first workout" button, and first-week workout logging completion rose 22 percent, since new users could now see exactly what they were working toward instead of guessing.

A filtered view that returns zero results, a search with no matches, an inbox that's genuinely empty after a user clears it, all deserve the same care. A generic "no results" message is a missed opportunity to either explain why (filters are too narrow) or suggest a next action (broaden your search, try a different filter), rather than just stating an absence and leaving the user to guess what to do next.

We design and review every empty state as its own deliberate screen during the design phase, not as a default fallback state generated automatically by whatever's left over after the populated version is designed. It's a small addition to the design timeline and it's consistently one of the highest-leverage details in how a new user's first experience actually feels.

An empty state because there's genuinely nothing there yet and an error state because something failed to load look confusingly similar if a team doesn't design them separately, and a user seeing the wrong one gets the wrong message: either wrongly reassured that everything's fine when a request actually failed silently, or wrongly alarmed that something's broken when the screen is simply, correctly, empty. We design these as two visually and textually distinct states from the start, since conflating them is a common source of confused support tickets that a small amount of upfront design work avoids entirely.

Beyond the completion rate lift we saw on the fitness app example, we track time-to-first-action from account creation as a general empty state health metric across projects: how long, on average, does it take a new user to complete the specific action an empty state is trying to prompt. A redesigned empty state that shortens this time meaningfully is doing its job; one that doesn't move the number, even if it looks more polished, hasn't actually solved the underlying problem it was meant to address.

The example workout card we designed for the fitness app wasn't a generic placeholder, it was built to look like a genuinely plausible first workout for the app's actual target user, specific enough to feel real rather than obviously synthetic. Sample data that looks clearly fake, lorem ipsum text, a placeholder image with an obvious watermark, undercuts the entire purpose of an illustrative empty state, since a new user's mental model of what to expect is only as good as how believable the example actually looks.

We now treat sample data design as its own deliberate task within any empty state project, reviewed with the same care as the surrounding copy and layout, rather than something a developer fills in quickly with whatever placeholder content happens to be lying around.

Empty states are, by definition, the least visible screens in a product demo, since a demo almost always shows a populated, feature-complete version of the app rather than the exact moment a brand-new user actually sees first. This makes empty state design easy to deprioritize under normal project pressure, since nobody in a stakeholder review is looking at it, even though it's the literal first thing every single new user encounters. We keep a standing checklist item for empty state review specifically because it's the kind of quietly important work that otherwise loses out to whatever's currently more visible in a sprint planning conversation, and it's a checklist item we protect deliberately for exactly that reason, treating its absence from a stakeholder demo as a reason to look harder, not a reason to assume it's fine. On a recent handoff, this checklist item caught two empty states nobody on the client's own team had ever actually seen in production, since their test accounts had been populated with sample data from day one and had simply never encountered the blank version a real new user would.

The fix, once it's actually noticed, is rarely expensive. A well-designed empty state is usually a small amount of copy and one clear call to action, not a significant engineering investment. The hard part is remembering to look for it at all in a review process that naturally gravitates toward whatever the demo happens to show, which is exactly why we've made it a standing checklist item rather than something we trust ourselves to remember on judgment alone.