The Full-States Checklist: Loading, Empty, Error, Success, Disabled

The happy path is maybe 60% of a screen’s real life. The rest is loading, empty, erroring, succeeding, or disabled, and if those states aren’t designed, your engineers will improvise them at 11pm before a release.

Here’s the checklist I run on every screen before calling it dev-ready.

Loading

• Does the layout hold its shape while loading (skeletons over spinners)?
• Is there a distinct treatment for first load vs. refresh?
• What happens if loading takes ten seconds instead of one?

Empty

• Does the empty state explain what will live here?
• Is there one clear call-to-action to create the first item?
• Is there a difference between “empty because new” and “empty because filtered”?

Error

• Can the user tell what failed and what to do next?
• Are field-level errors adjacent to their fields, written in plain language?
• Is there a retry path that doesn’t lose the user’s work?

Success

• Is success confirmed where the user is looking, not just in a corner toast?
• Does the confirmation offer the logical next step?

Disabled

• Does a disabled control explain why it’s disabled (tooltip, helper text)?
• Should it be hidden instead? Disabled-with-no-explanation is the worst of both.

Why this matters for handoff

When these states ship in the Figma file, engineers stop guessing, QA stops filing “what should happen here?” tickets, and the product stops accumulating those slightly-off improvised screens that make software feel unfinished. It’s the cheapest quality win in SaaS design.