Design every state

Loading, empty, error and success each need a deliberate design.

How to apply it

Never ship a screen with only its data-full state designed.

Design every state in practice: a concrete example

The empty state is the first thing a new user sees

A brand-new Notion or Todoist account isn't full of data, it's empty, and that blank screen is the first real impression the product makes. The strong version turns it into onboarding: one clear next action, a sample to copy, a line of encouragement. Skip it and the new user lands in a void and leaves. The same care applies to loading (a skeleton, not a frozen screen), errors (what happened and how to recover), and success (confirm the action actually landed).

Common Design every state mistakes

Designing only the data-full “happy path” and letting empty, loading, and error states fall back to whatever the code happens to do.
Writing generic error copy (“Something went wrong”) that never says what failed or how to fix it.
Treating the empty state as a dead end rather than the best onboarding moment the product gets.

When Design every state doesn't apply

This is about deliberate design, not maximal design. A tiny, self-evident component rarely needs a bespoke empty or error treatment, and lavishing effort on every micro-state is a poor use of time. Spend the care where a state is common, confusing, or costly: first run, a failed payment, a dropped connection.

Practise it on a real challenge

Match each AI feature state to the right treatment

Teams design the AI's 'here's your answer' state and forget generating, empty, and failure — the states users actually get stuck in.

Support Agent — Incorrect Refund

An automated agent issues the wrong refund and leaves no clear route to correct it.

AI Generator — No Error or Empty State

An AI generation feature only designed its success state — failures and waits look broken.

Design every state

How to apply it