The Three States: Loading, Empty, Error
The three abnormal moments in a UI are exactly where experience splits. Empty states should teach the next step; loading should report progress; errors should speak plain language and offer a way out. Pick winners in three A/B duels yourself
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “The Three States: Loading, Empty, Error”?
The three abnormal moments in a UI are exactly where experience splits. Empty states should teach the next step; loading should report progress; errors should speak plain language and offer a way out. Pick winners in three A/B duels yourself
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
Ask AI for「a notes app」and it ships a screen preloaded with pretty fake data. A real user's first screen has no data. The first search may time out. The first sync may fail. AI won't invent how those moments look. Skip the ask, and it phones them all in.
| State | AI's default phoned-in version | What it should look like |
|---|---|---|
| Empty state | A blank field, or a gray line「No data yet」 | Teach the next step: say what this is for, offer an action, ideally with an example |
| Loading | A bare spinner that looks the same at second one and second thirty | Say how far you've gotten: show content shape first; make progress visible |
| Error state | An alert dumps a code stack—or nothing happens at all | Plain language plus a way out: what happened, why, what to do |
Last lesson's considerate checklist all applies here: empty state tests anticipatory; loading tests informs in time; error state tests doesn't burden you with its problems. One state at a time.
In About Face 4, Chapter 8, Cooper likens helpful software to a good shop clerk: ask for directions and a good clerk also points you to a smarter option. Empty state is the user asking directions: I'm here—now what? A blank screen is a shrug.
A good empty state answers three questions: what is this for, what can I do now, and what will it look like when I do. The first two take one sentence plus a button. The third wants sample data or a template. Both notes apps below are first opens. Tap the one you find more considerate.
Considerate software informs in time: progress users care about must be visible. A bare spinner only says「busy」. By second five, users suspect a freeze. A skeleton screen draws the content's shape first—you're almost there, and it'll look like this—then a progress line cuts most of the anxiety.
Which wait deserves which feedback—the three-tier wait psychology—was covered in the Psychology part. Here's a jump card; we won't reteach it.
Cross-Part link · Waiting psychology: the pain was never those 5 seconds0.1s / 1s / 10s three-tier feedback decisions, and why managing expectation beats raw speed—Psychology Part, lesson 2 covers it. Tap to jump.In About Face 4, Chapter 15, Cooper is blunt on error messages: old-style dialogs either blame the user or dump a tech failure; most shouldn't appear at all. When you must speak, tell the user three things: what happened, why, and what to do now. All three make plain language. Skip「what to do」and you trap them in a dead end.
One more floor: never blame the user in the wording. Chapter 15's rule is there is no fault in the user's view—swap「You entered illegal characters」for「This field only allows letters and numbers」. Same info, different attitude. Two sync-failure prompts below. Tap the more considerate one.
upload.ts:214 (code 10060)
Copying the three-element formula isn't enough—you need the feel. The three error lines below match real AI output. Tap「Rewrite」on each, see the weak copy rebuilt with the three elements, and note where each one fails.
Three states taught—close with a self-check sheet. Think of the page you last had AI generate. Check each of the five states you've actually built; coverage scores on the spot. This sheet is also a prompt template for AI: Lesson 9 shows how to paste the whole thing into a prompt.
Abnormal moments are the split: AI defaults to「everything fine」. Unless you write empty state, loading, and error state into the brief, it phones them all in.
Empty state teaches the next step: say what this is for, offer an action, give an example. Empty state is a new user's first screen—a blank pushes them out.
Loading should say how far you've gotten: skeleton screen for content shape, plus progress copy. Wait-feedback timing lives in psy-2; we don't reteach it.
The three error elements: what happened, why, what to do—and never blame the user in wording (Cooper, About Face 4, Chapter 15). Better still: stop the error from happening at all. Next lesson covers error prevention and reversible actions.
Source: Original to Xiaoshan Academy's「Interaction Engineering」series; some interaction principles adapted from About Face 4: The Essentials of Interaction Design.
Turn the feeling in “Normal is a pass. Abnormal moments are where you pull ahead” into a judgment
“Ask AI for「a notes app」and it ships a screen preloaded with pretty fake data.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “Last lesson's considerate checklist all applies here: empty state tests anticipatory ;” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “The three error elements: what happened, why, what to do—and never blame the user in wording (Cooper, About Face 4 , Chapter 15).” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Normal is a pass. Abnormal moments are where you pull ahead” to “Empty state is a new user's first screen—don't hand them a blank”
“Normal is a pass. Abnormal moments are where you pull ahead” grounds the problem in “Ask AI for「a notes app」and it ships a screen preloaded with pretty fake data. A real user's first screen has no data. The first search may time out. The first sync may fail. AI won't invent how those moments lo…”. “Empty state is a new user's first screen—don't hand them a blank” then moves it toward “In About Face 4 , Chapter 8, Cooper likens helpful software to a good shop clerk: ask for directions and a good clerk also points you to a smarter option. Empty state is the user asking directions: I'm here—now…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Normal is a pass. Abnormal moments are where you pull ahead”: Ask AI for「a notes app」and it ships a screen preloaded with pretty fake data. A real user's first screen has no data. The first search may time out. The first sync may fail. AI won't invent how those moments lo…
- “Empty state is a new user's first screen—don't hand them a blank”: In About Face 4 , Chapter 8, Cooper likens helpful software to a good shop clerk: ask for directions and a good clerk also points you to a smarter option. Empty state is the user asking directions: I'm here—now…
- “The closing point”: One more floor: never blame the user in the wording. Chapter 15's rule is there is no fault in the user's view—swap「You entered illegal characters」for「This field only allows letters and numbers」. Same info, dif…
The final “The closing point” brings the discussion to “One more floor: never blame the user in the wording. Chapter 15's rule is there is no fault in the user's view—swap「You entered illegal characters」for「This field only allows letters and numbers」. Same info, dif…”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.