Loading, empty, error: the interface states everyone forgets

In a presentation, the mockup looks flawless: the order list is full, the photos have loaded, the connection is fast. In real life, someone opens that same screen in an elevator with one bar of signal, on day one when there are no orders yet, or right when the payment provider fails to respond. Those are the moments when people decide whether to trust the product.

That's why on InterLAB projects we describe a set of states for every key screen, not a single view. It's cheap at the design stage and expensive to remember after launch, once the complaints are already coming in.

The right indicator depends on how long the wait is. For years Nielsen Norman Group has relied on three response-time thresholds:

A skeleton screen is a wireframe of the page made of neutral blocks in place of headings, images and lines of text. It only works if it mirrors the real layout: a “skeleton” of three identical bars is no better than a spinner. For long operations — exporting a report, importing a price list, processing a video — it's more honest to show step-by-step progress: “120 of 400 items processed”.

An empty state is a screen with nothing to show yet. Nielsen Norman Group describes it as an opportunity to communicate system status, help people learn the product and offer a direct path to a key task. In practice it's usually an empty table that says “No data”.

• First use — explain what the section is for and lead to the first action
• No results — help adjust the query instead of leaving a dead end
• All done — say it plainly when, for example, every request has been processed
• No access — explain whom to ask for permissions

Errors are inevitable: connections drop, sessions expire, third-party services go silent. What separates a cheap product from a premium one is what happens next. The core of Nielsen Norman Group's error-message guidelines: the message is visible, written in plain language, names the problem precisely, offers a fix and preserves whatever the user has already entered.

Mobile connections drop at the worst possible moment. Browsers can tell an app that the connection is gone (MDN documents the navigator.onLine property and the online/offline events), so the interface can say “You're offline — we'll update as soon as you're back” instead of spinning forever.

Optimistic UI goes a step further: it shows the result of an action immediately, before the server responds. A like fills in instantly, a task moves to “Done” without waiting. If the server returns an error, the change is rolled back gracefully and a clear notification appears.

• Good for frequent actions that almost always succeed: checkmarks, likes, dragging cards
• Not for payments, order submission or anything where a failure costs money — use an honest indicator there
• Unsent changes are best stored locally and synced once the connection returns

A confirmation dialog on every delete quickly becomes a reflex: people click “Yes” without reading. Nielsen Norman Group advises against confirmations for routine actions and recommends offering undo wherever possible. Delete an email, and a short “Email deleted” message with an “Undo” button appears at the bottom. Keep confirmations for actions that truly can't be reversed.

That short pop-up message is called a toast. It's a good fit for confirmations like “Saved”, “Link copied” or “Undo delete”. The rules are simple:

• One action per toast, and one toast on screen at a time
• It doesn't disappear while the pointer or focus is on it — otherwise there's no time to hit “Undo”
• Critical errors don't go in a toast — they stay on screen until resolved
• Screen readers must announce the message: WCAG covers this under status messages (4.1.3)

Run through it when reviewing designs or the first version of the product. If an item has no answer, discuss it with the team before development starts.