8.5 Interaction & the four states every screen needs

A demo shows one screen: data loaded, everything perfect. A real product shows four — because data is sometimes loading, sometimes empty, sometimes failing, and only sometimes the happy success you designed. AI almost always builds just the success state and stops. Knowing the other three by name — and asking for them — is the single biggest jump from “looks done” to “is done.”

Key vocabulary

The four states: Any view that loads data has a loading state (data in flight), an empty state (zero results), an error state (the request failed), and the success state (data shown). Build all four.
Empty state: What a view shows when there's no data yet. A good one explains why it's empty and offers the action to fill it (“No projects yet — create your first”). A blank screen is a bug, not an empty state.
Skeleton screen: A grey placeholder shaped like the content that's loading, shown instead of a spinner. It makes the wait feel shorter because the layout appears immediately.
Optimistic UI: Showing the result of an action before the server confirms it (the message appears instantly), then rolling back if the request fails. Feels fast — but needs a rollback path.
Component state: The visual states of a single control: default, hover, focus (keyboard), active (pressed), disabled, and loading. AI often builds only default — name the rest.

The four states every data view needs

The moment a screen depends on data from a server, it has four lives. While the request is in flight, it’s loading. If the data comes back empty, it’s empty. If the request fails, it’s error. And when data arrives, it’s success. Users hit the first three constantly — slow networks, brand-new accounts, flaky connections — so a component that only renders “success” shows a blank or broken screen at exactly the moments something’s already going wrong.

FIG 1 · the four states of one list The same list view, four ways. Ship only the rightmost and your UI breaks on every slow network or empty account.

Spec a view by its four states, not its happy path

"Build a <ProjectList>. Spell out all four states:
 • loading: skeleton rows (not a centered spinner)
 • empty:   'No projects yet' + a 'New project' button
 • error:   'Couldn't load projects' + a Retry button
 • success: the list of project cards
 Each card shows name, last-edited, and a ghost ⋯ menu."

The AI now cannot ship a success-only component — you named the other three, so it has to build them. This one habit eliminates the most common class of “it broke in production” UI bugs.

Forms: validate at the right moment, in the right place

Validation timing is a small decision with a big feel. Validating on every keystroke screams errors at someone who’s still typing; validating only on submit lets them fill a whole form before learning the first field was wrong. The comfortable default is on blur (when they leave a field) plus a final check on submit — and the error message belongs next to the field, not in a banner at the top. Disable the submit button while a request is in flight so it can’t be double-fired.

Feedback, and a component’s own states

For the wait, prefer a skeleton (a grey shape of the coming content) over a spinner — it shows the layout instantly so the wait feels shorter. For actions, optimistic UI makes things feel instant by showing the result before the server confirms (the sent message appears immediately) — but you must handle the rollback if it fails. Finally, every interactive element has its own states: a button is not just “a button,” it’s default, hover, focus (the keyboard ring), active, disabled, and loading. Name them so the AI builds the disabled and loading looks, not just the default.

FIG 2 · a button is six states Default is the easy one. The other five — especially focus, disabled, and loading — are what AI tends to skip.

01 Learning objectives

0 / 6 done

02 Curated reading

Scott Hurff — The UI Stack (the 5 states of a screen)
essential 15m — The canonical “every screen has more than one state” argument.
NN/g — Skeleton Screens
optional 8m — Why skeletons beat spinners for perceived speed.
MDN — Client-side form validation
optional 15m — When and how to surface validation feedback.

03 Knowledge check

knowledge check3 questions · pass ≥ 70%

01easy
Which states should every data-driven view handle? (select all)
02medium
Why prefer a skeleton screen over a spinner while content loads?
03medium
Optimistic UI (showing the result before the server confirms) needs a rollback path.

04 Interview questions

browse all ↗

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

Commonly asked mid concept common When should form validation fire, and where should the error message appear?
The comfortable default is on blur (when the user leaves a field) plus a final check on submit — not on every keystroke, which nags someone who's still typing. The error message belongs right next to the field it concerns, not in a banner far from the problem, and the field should be visually marked (colour plus an icon or text, never colour alone). Disable the submit button while the request is in flight so it can't be double-fired.
What a strong answer covers
- Validate on blur + on submit; avoid validating on every keystroke.
- Show the error inline, next to the offending field.
- Mark the error with more than colour (icon/text) for accessibility.
- Disable submit while a request is in flight.
Follow-ups they push on
- Why is per-keystroke validation a poor experience?
- Why isn't client-side validation enough on its own? (see Module 9)
Red flag Collecting all errors into a summary at the top of the page and leaving the fields themselves unmarked — the user can't tell which input is wrong.
source: MDN — Client-side form validation ↗