Designing Empty States That Actually Help Users, Not Just Fill Space

We used to treat empty states as an afterthought, something to fill in after the 'real' screens were done. On a project management tool we built for a logistics client, the empty task board just said 'No tasks yet' with a gray icon. Support tickets from new accounts spiked in the first week because users genuinely didn't know whether that screen was broken or just, well, empty.

The fix wasn't cosmetic. We rewrote every empty state to answer three questions in order: what belongs here, why is it empty right now, and what's the one action that fixes it. For the task board, that became 'Tasks assigned to you will show up here. Create your first task or ask a teammate to assign one,' with a single button, not two competing ones.

Not every empty state should be an onboarding moment, though. We learned this the hard way by putting a full illustration and three-sentence explainer on a search-results-empty state, which just made a fast interaction feel slow. Search-no-results needs speed and a way to broaden the query, not a tutorial. Reserve the heavier, more didactic empty states for screens people land on once, like a new workspace or an unconfigured integration.

We also design for the state between empty and full, the one with one or two items, since it reveals whether the layout actually works or was just designed around the empty illustration. A card grid that looks great with zero items and great with fifty often looks broken with one, floating alone with acres of whitespace around it. We now mock that in-between state explicitly, every time.

The measurable payoff was fewer 'is this broken' tickets in the first session, which is really what empty states are for: they're not decoration, they're the product's first attempt at customer support.