When you press a button and nothing happens, the reaction is almost always the same: you press it again. The result may be a duplicate order, a message sent twice, a form submitted halfway. Many usability problems come not from what the interface does, but from the fact that it does not communicate it.
The first of the best-known usability heuristics is precisely about this: the system should always keep users informed about what is going on, through appropriate feedback within a reasonable time.
How long a wait can last
A rule of thumb widely used in interface design distinguishes three thresholds, which are by now classic:
| Response time | Perception | What to show |
|---|---|---|
| Up to about 0.1 seconds | Instant reaction | Nothing special: the visible change is enough |
| Up to about 1 second | The flow of thought is not interrupted, but the delay is noticed | A discreet signal, such as the button changing state |
| More than a few seconds | Attention is likely to wander | A progress indicator and, if possible, an estimate |
These are orders of magnitude, not exact measurements, but they help in choosing the right kind of feedback.
Types of indicator
Immediate feedback on the element
The first feedback must appear where the user acted. A pressed button can change appearance, show a small indicator and become temporarily disabled to prevent double submission. Its text can change from «Send» to «Sending…».
Spinners
A spinning indicator says «I'm working» but not how long is left. It is fine for short waits of unpredictable length. For long waits it becomes frustrating: after ten seconds of spinning, users do not know whether the system has frozen.
Progress bars
When the duration can be estimated, as with a file upload or an export, a bar with a percentage or the number of items processed is far more reassuring. Even a rough estimate, such as «about two minutes», is better than nothing, as long as it is honest.
Skeleton screens
Instead of a blank page with a spinner in the middle, you show the structure of the page in light grey, with blocks where headings, images and text will appear. Users immediately understand what is about to arrive, and the switch to the real content is less abrupt. The skeleton must match the final layout: if the real content has a different shape, the page «jumps» when it loads.
Optimistic interfaces
For actions that almost always succeed, such as liking something or ticking off a task, you can update the interface immediately as if the operation had already succeeded, and sync with the server in the background. The experience feels instant.
The condition is handling the failure case well: if the server rejects the operation, the interface must return to its previous state and explain this clearly. It is not a suitable approach for important or irreversible actions, such as a payment: there the user needs to know for certain how it went.
Confirmations and status messages
When an action is complete, a proportionate confirmation is needed:
- for frequent, minor actions, a short temporary message such as «Saved»;
- for important actions, a confirmation page or section with the details, such as order number and summary;
- for actions that can be reversed, the message can offer «Undo» for a few seconds.
Temporary messages, sometimes called toasts, have a flaw: they disappear. If they contain important information or an action such as «Undo», they must stay long enough, be reachable with the keyboard and not vanish while the user is interacting with them.
Accessibility: people who cannot see need to know too
A spinner or a green message appearing in a corner is invisible to screen reader users unless it is announced. WCAG criterion 4.1.3 on status messages requires that this information is conveyed to assistive technologies without moving the focus.
The main tool is a live region:
<div role="status" aria-live="polite" id="save-status"></div>
When a script inserts text into the element, for example «Changes saved», the screen reader reads it as soon as it has finished what it was saying. For urgent errors you can use role="alert", which interrupts current speech: use it sparingly. The region must already be present in the page before the message is inserted, otherwise some screen readers do not pick it up.
Loading indicators also need text: «Loading results» announced at the start and «20 results found» at the end are much more useful than a silent animation.
Common mistakes
- buttons that stay active during submission, causing duplicate orders;
- endless spinners when the request has failed, with no error message;
- confirmation messages that vanish in two seconds;
- content that shifts as images or ads load, making readers lose their place;
- updates to results and filters not announced to screen readers.
In short
- Every user action deserves visible feedback, proportionate to the waiting time.
- Spinners are fine for short waits; long ones need progress and an estimate.
- Skeleton screens and optimistic interfaces make waiting smoother, if used judiciously.
- Buttons must prevent double submission and failures must produce a clear message.
- Live regions with
role="status"make confirmations and states accessible to screen readers.
