State coverage

The happy path is one state out of about ten. It gets designed, built, demoed and tested. The other nine are discovered by users.

This is the cheapest quality work available on any interface: enumerate the states before building, because each one is a five-minute decision in advance and a support ticket afterwards.

1. The matrix

For every screen, list and every meaningful component, decide all of these. Most have a sensible default; the point is that you chose it.

Write the matrix as a table in the design or the ticket. A screen with ten states and three designed is a screen that is 30% done, and the table is what makes that visible before it ships.

2. Empty is an invitation, not an absence

An empty state does three things: says what belongs here, says why it is empty, and offers the action that fills it.

Bad:   No results.

Good:  No reports yet
       Reports you complete will appear here, newest first.
       [ Start a report ]

Distinguish the three empties, because they need different words:

• First run — "Nothing here yet" plus the primary action.
• Empty now — "You have no open items" is a success in many products. Say so; don't make a clean queue feel like a failure.
• Empty after filter — name the filter and offer to clear it. "No sites match north. [Clear search]"

3. Loading: show the shape, hold the space

• Under ~300ms, show nothing. A flash of skeleton is worse than a short wait.
• Beyond that, a skeleton in the shape of the content beats a spinner: it tells the user what is coming and stops the layout jumping when it arrives.
• Reserve the space. Content that appears and shoves the page down causes mis-taps, especially on a phone.
• Over ~10 seconds, it needs progress, an estimate, or a way out. A spinner with no end is indistinguishable from a hang, and users are right to reload.
• Never block the whole screen on a non-critical region.

4. Errors say what happened, what it means, and what to do

Three parts. Most error messages have one.

Bad:   Error: request failed (500)

Good:  Couldn't save your answers
       They're saved on this device, so nothing is lost. We'll try again
       automatically when you're back online.
       [ Try now ]

Rules:

• Never lose their input. Not on validation failure, not on a server error, not on a navigation. This is the one that turns an annoyance into an abandonment.
• Put validation errors next to the field, on blur or submit — not on every keystroke, which scolds people mid-typing.
• Distinguish retryable from terminal, and only offer the retry that can work.
• No error codes as the whole message. A code in addition is useful for support; keep it small and copyable.
• Write in the interface's voice, not a person's. Errors do not apologise repeatedly.

5. Denied is its own state

"You don't have access" is not an error and not a 404. Users hit it constantly in multi-role products, and treating it as a generic failure sends them to support.

Say what is restricted, and what to do — usually "ask an admin", ideally with the admin named. Note the tension with access-control-proof: where confirming that a resource exists would leak information, "not found" is the correct response and the honest message is generic. Decide which case you are in deliberately.

6. Overflow: test with ugly data

The data in the design file is always tidy. Real data is not.

• A name with 200 characters, and one with an emoji, and one in a right-to-left script.
• A list with 0, 1, 2 and 10,000 items. Virtualise beyond a threshold and pick the threshold deliberately.
• A number with 11 digits, a negative, a zero, a null.
• A field that is legitimately empty versus one that failed to load — those must not look the same.
• The longest translated string, if you have translations.

Seed a fixture with all of this and keep it. It catches more layout bugs than any amount of reviewing the tidy version.

7. In flight and after

• Disable the control and show it working. A button that can be pressed twice will be.
• Give feedback within ~100ms of the press, even if the work takes longer.
• Confirm success in a way that survives: a toast that vanishes in three seconds is not a receipt. For anything consequential, the state of the page should show it.
• Optimistic updates need a visible, non-destructive rollback. If you show it as done before it is, you must be able to take it back clearly.

8. Destructive actions: prefer undo to confirm

Confirm dialogs are dismissed reflexively and stop working after the third one. An undo window is better for almost everything that can be soft-deleted.

Where a confirmation is genuinely required, make it specific — name the thing being deleted and what else goes with it — and never make the destructive button the default focus.

9. Write the copy at the same time as the state

The copy is the state. A state designed without its words gets "Error" by default, and a placeholder that ships. Put the actual sentence in the design.

Keep it plain, in the second person, and about the user's situation rather than the system's internals. "We couldn't reach the server" tells them nothing they can act on; "You're offline — your work is saved here and will sync" does.

Checklist

• The state matrix written out for each screen, with a decision per row
• Three empty states distinguished, each with an action
• Skeletons over spinners; space reserved; a way out beyond ~10 seconds
• Errors say what happened, what it means and what to do
• Input never lost on error or navigation
• Denied handled as its own state, or deliberately made generic to avoid leaking
• Tested with an ugly-data fixture: long, empty, huge, zero, null, RTL
• In-flight controls disabled; success visible in page state, not just a toast
• Optimistic updates have a visible rollback
• Undo preferred over confirm; confirmations name the thing
• Real copy written for every state, not placeholders