Design every state, not just the happy path

Open almost any design file and you will find beautiful screens full of perfect data. Three items in the list, a name that fits on one line, a photo that loaded instantly, a user who has already completed onboarding. It is a screenshot of the best day the product will ever have.

Then it gets built, and reality arrives: an empty list, a name in a script that wraps to three lines, a photo that fails on hotel wifi, a first-time user with nothing to look at. None of that was designed, so an engineer designs it — at speed, at midnight, without the context you had.

The eleven states worth drawing

For any screen carrying real data, I work through the same list. Most screens need six or seven of them; almost none need zero.

• Empty — nothing here yet, and what the user should do about it.
• First-run — empty, but for a brand-new user who also needs teaching.
• Loading — skeleton or spinner, and what happens if it takes eight seconds.
• Partial — some content arrived, some did not.
• Error — what broke, whose fault it is, and the way out.
• Offline — what still works without a connection.
• Permission denied — the user cannot see this, phrased without blame.
• Too much data — 10,000 rows, a 90-character name, a 40-item cart.
• Success — the confirmation, and where attention goes next.
• Stale — this was true four minutes ago, here is how to refresh.
• Destructive confirm — the last chance before something is irreversible.

It is faster, not slower

The objection is always time. In practice, designing the states takes hours and saves days — the build stops stalling on questions, QA stops filing tickets about screens that were never specified, and nobody ships a blank white rectangle labelled 'no data'.

It also changes the design itself. Sketching the empty state is how you discover the onboarding is wrong. Sketching the error state is how you discover the flow has no recovery path. The states are not decoration around the design. Quite often they are the design.