Every screen has six states

Designing a flow means designing all of it — not just the moment everything works.

The idea

The screen you sketch in your head is the happy path: data loads, the upload succeeds, everyone’s online. Real users hit the other paths — a dropped connection, a file that’s too big, a session that timed out.

A reliable rule of thumb: every screen that fetches or changes data has six states — empty, loading, partial, success, error, and offline. If you don’t design one, the code still reaches it — and the user gets a blank screen or a spinner that never stops.

See it work

How it works

Walk every screen through the same checklist, then design each state deliberately — including how the user recovers.

THE SIX STATES (for any data-driven screen)
  empty     nothing yet          -> invite the first action
  loading   working on it        -> progress, and a way to cancel
  partial   some, not all        -> show what worked and what didn't
  success   done                 -> confirm it, and offer undo
  error     it failed            -> what happened / why / what next
  offline   no connection        -> save their work, retry later

ERROR-MESSAGE ANATOMY (three parts, always)
  1. what happened   "Upload failed."
  2. why             "report.pdf is 41 MB, over the 25 MB limit."
  3. what to do next  "Compress it, or choose a smaller file."   [Try again]

Recovery affordances — retry, undo, and preserving the user’s input — turn a dead end into a detour. An error without a next step is just a wall.

When to use it

Reach for it when	Trade-off to remember
Any screen that loads, uploads, saves, or syncs data	Designing six states per screen is more work — prioritize by how likely and how costly each path is
Design critiques and whiteboard rounds — a fast completeness check	Not every state needs a bespoke screen; some can be a well-worded inline message
Reviewing a build before ship — “show me the error and offline states”	The states interact (offline during a partial upload); the matrix can grow

Watch out for

• Only designing the happy path. The demo looks great; the first real user with a flaky connection sees a blank screen. Error and offline are not edge cases — they are Tuesday.
• “Something went wrong.” A generic error with no cause and no next step leaves the user stuck. Always give what happened, why, and what to do.
• Confusing empty with loading. A spinner that never resolves and a truly empty list look different and need different copy. Distinguish “still loading” from “nothing here yet.”
• Losing the user’s input on error. If the upload fails, keep the file and the form. Making them start over is the real failure.
• No offline handling. Mobile users go through tunnels. Queue the action and retry rather than dropping it silently.

Worked example

You’re asked to design photo upload for a mobile app. The tempting answer is empty → loading → success. Instead, name all six states out loud: an empty state that invites the first photo; a loading state with progress and cancel; a partial state for a batch where two of five uploaded; a success state with an undo; an error state with the full anatomy and a retry; and an offline state that saves the photo and uploads it later. Sketching offline and error — and the recovery affordances — is exactly the signal an interviewer is listening for: you design the flow, not just the screenshot.

Check yourself

Powering your career growth.