Design the states everyone forgets

The happy-path problem

Open almost any design file and you’ll find beautiful screens full of perfect data. Twelve neat rows in the table, a chart trending gently upwards, every name exactly the right length. Then the product ships, and real users see an empty table on day one, a spinner that never stops, or an error message written by whoever was on call that week.

Designers care about these states; they simply weren’t listed. When they’re not in the design, engineers have to make them up under deadline pressure, and each one ends up slightly different.

The states worth listing

For each screen in a workflow, we go through the same short list:

• First use: nothing’s been created yet. What should the person do first?
• No results: there’s data, but nothing matches the current filters or search.
• Loading: the data’s on its way. Is it seconds, or could it take minutes?
• Partial: some of the data loaded, or some of it is out of date.
• Error: something failed. Is it the user’s mistake, a rule, or the system?
• No permission: the data exists, but this person can’t see it.
• Success: the task worked. What happened, and what’s next?
• Extreme content: very long names, huge numbers, hundreds of rows.

Not every screen needs all eight. But going through the list takes ten minutes and regularly turns up gaps that would otherwise surface in QA, or in a support ticket.

Zero, unknown and “not for you” are different

These three often get the same blank treatment, and they really shouldn’t. “You have no overdue requests” is good news. “We couldn’t load your requests” is a problem. “You don’t have access to this team’s requests” is a permissions question. Show them all as an empty table and you leave people guessing, or worse, believing everything’s fine when it isn’t.

On dashboards especially, a zero that’s really a failed data refresh can lead to a bad decision. Label the difference clearly.

Make empty states do some work

A first-use empty state is one of the best teaching moments in a product. Rather than “No data”, tell people what will appear here and give them the single most useful action to get started. “No events yet. Create your first event, or import a guest list.” Keep it short. One clear next step beats a paragraph of help text.

Be honest about waiting

For quick loads, a simple loading indicator is fine. For anything longer than a few seconds, people want to know whether it’s working and roughly how long it’ll take. If a process runs in the background, let them leave and come back, and tell them where the result will appear.

Don’t forget people using screen readers. A spinner that appears visually says nothing to them unless the change is announced. WCAG’s guidance on status messages covers this, and it’s much easier to plan for in the design than to retrofit.

Write errors that help people continue

A good error message says what happened, in plain language, and what to do next. It also distinguishes the user’s mistake from the system’s. “That date is outside the booking window. Choose a date before 30 November.” is useful. “Something went wrong” is not, unless you add what the person can do about it, and whether their work is safe.

Hand it over as an inventory

The most practical output is a simple table for each screen: the state, what triggers it, what the user sees and what they can do. Engineers value it, because it answers questions they would otherwise have to raise during the build. On an enterprise events platform our founder worked on, every component was specified across its configuration, preview and empty states for exactly this reason.

Complex Workflow Design includes loading, empty, error and permission states for every screen in the journey, so your engineers don’t have to guess.