The Tellenze blog

An Empty Screen Has More Than One Meaning

A blank parts list can send someone to an order form when the cupboard is full. The explanation should fit what the software actually knows.

· The Tellenze team

A teal sliding panel partly covers a bicycle-parts cabinet, leaving an empty cubby visible.

A volunteer looks at the parts screen and reaches for the order form. No brake pads.

In this fictional community bike workshop, there are brake pads in the cupboard. The screen is showing none because a filter from the previous repair is still active. It is looking for a particular model.

The volunteer's conclusion is reasonable. A screen called “Parts” has a large empty space where parts usually appear, followed by “Nothing here yet” and an Add button. The small filter chip has done little to qualify that message.

The software team might describe this as an empty-state problem. For the workshop, it's a question of whether to buy something.

That gap is what makes an empty screen worth designing carefully. The interface is still telling a story when it has nothing to show.

What have we actually counted?

“No parts” could mean several things, even when the software is working correctly.

On the workshop's first day using the system, nobody has entered the cupboard's contents. There are no registered parts. That says something about the records, and very little about the cupboard.

A useful first-use message might explain this plainly: “Your parts register is empty. Add the parts you already have.” A volunteer can begin with the contents of one shelf. There's no need to suggest placing an order.

A month later, the register is populated. The same empty rectangle now means that the selected brake model has no matching entries. “No registered pads match this model” gives the volunteer a different starting point. Keeping the model visible and offering to remove that filter lets them understand what was searched.

Even that wording has a limit. A successful search describes the recorded inventory. It doesn't establish that an unrecorded packet hasn't been left in a drawer.

This is easy to lose when a count becomes a confident sentence. Zero records, zero matches and zero physical objects are different claims. A system can know the first two while knowing nothing dependable about the third.

IBM's Carbon guidance on empty states distinguishes first use, feedback after an action and situations where data is unavailable. That is useful design guidance, rather than evidence that a particular message will improve a product's results.

For our workshop, the distinction gives the team a practical writing question: what does the person now have grounds to believe?

They may have grounds to believe the register needs setting up. They may have grounds to check a filter. They may still need to open the cupboard.

A useful invitation can be the wrong one

An Add button makes sense when the volunteer is entering stock for the first time. Put it under a failed load, however, and it can invite them to recreate records that already exist.

Imagine the workshop's connection fails while the parts screen is opening. The application falls back to an empty list and displays its usual welcome message.

The volunteer remembers entering several boxes yesterday. Now the software appears to say that nothing was saved. They start adding the boxes again.

No amount of warmer wording will make that response helpful. The application hasn't obtained an answer about the records. It needs to preserve that uncertainty.

“We couldn't load the parts register” is an honest starting point. A retry can repeat the read while keeping the selected model in place. If the volunteer can work from a previously loaded view, the interface should make its age clear. Yesterday's list may be useful; calling it current would give it more authority than it deserves.

GitHub's Primer guidance recommends explaining the particular problem and offering a route that helps with the task. An unrelated action is a poor escape from an error. In this example, inviting the volunteer to add stock takes them further from finding the records they were trying to read.

The team also shouldn't promise “Your data is safe” just because that sounds reassuring. A failed read doesn't establish what happened to an earlier write. The screen can say what it couldn't load without pretending to have checked everything else.

This is partly a behavior decision. The people writing the copy need to know whether the request succeeded, which filters it used and whether the displayed information is current. If implementation merges those outcomes into one empty list, the writer is being asked to explain a distinction the application has already thrown away.

Sometimes the right action is outside the screen. If the register is unavailable and the volunteer urgently needs a part, checking the cupboard may be the sensible route. A recovery message can acknowledge that without pretending the cupboard is empty or sending them into another setup flow.

Leave room for a good kind of empty

Later that afternoon, the workshop finishes its reorder list. Every agreed purchase has been dealt with. The current list has no open entries.

There is a temptation to reuse the first-use illustration and suggest adding another item. But the person came here to clear the list. The empty space is the result they wanted.

A modest “No outstanding reorder items” may be enough, provided the screen has actually checked that state. The usual controls can remain available for next time. They don't need to become an assignment.

Carbon makes room for cases where an empty display requires no further action. That is a useful counterweight to the habit of treating every blank area as an opportunity to get someone moving.

Quiet can be good product behavior.

The same applies to the image. A small illustration may make the first-use screen welcoming. On a failed load, cheerful confetti would suggest the wrong mood. On a familiar, cleared list, a large explanation may simply get in the way.

The message must also work for someone who doesn't see the image or the changing rows. W3C's guidance on status messages explains how dynamic status text, including a no-results message, can be made available to assistive technology without moving focus. Its scope is specific; it doesn't require every change on a page to become an announcement.

For the workshop's filter, the useful information is what was searched and that it returned no matches. An announcement of “zero” alone would leave the person to reconstruct the rest.

Before drawing another empty-state illustration, try reading the proposed message beside the action it offers. In the workshop, “Nothing here yet” plus Add suggests missing records. “No registered pads match this model” plus Remove filter suggests a search to reconsider. “We couldn't load the parts register” plus Try again suggests an unanswered read.

Those are different decisions for the volunteer, even if the rectangles look identical.

And when there are no outstanding reorder items, the workshop can get back to fixing bikes.

Further reading