Feedback and System Status
Date: 2026-08-17
Telling people what happened and what’s happening now. It’s the oldest usability heuristic and the most reliably violated — and its absence produces duplicate orders, which is a data problem as well as a usability one.
Feedback is the response to an action. System status is the ongoing communication of what the system is doing.
The requirement: every action produces a perceivable response, within a timeframe that matches its cost.
The timing thresholds
Long-established, and they map to different design responses:
~0.1s feels instantaneous
→ no indicator needed
~1s noticeable, thought unbroken
→ keep the interface responsive
~10s attention wanders
→ progress indicator required,
with an estimate if possible
>10s they leave, or act again
→ set expectations, allow other
work, notify on completion
The critical band is 1–10 seconds, where something is clearly happening and nothing says so. That’s where people click again.
The duplicate submission problem
The most expensive feedback failure in commerce:
click "Place order"
→ no visible change
→ 2 seconds pass
→ click again
→ TWO ORDERS
The fix is three layers, and all three are needed:
1 IMMEDIATE visual response
button state changes on click
2 DISABLE the control while pending
3 IDEMPOTENCY KEY server-side
← the only actual guarantee
— Idempotency
See: Idempotency
Layers 1 and 2 are courtesy; layer 3 is the guarantee. A double-tap on a flaky mobile connection can fire twice before any JavaScript runs, so client-side prevention alone will not hold — Race Conditions.
Optimistic versus pessimistic feedback
| Optimistic | Pessimistic | |
|---|---|---|
| Behaviour | Show success immediately, reconcile if it failed | Wait for confirmation |
| For | Feels instant | Always accurate |
| Against | Must handle the rollback, visibly | Feels slow |
Optimistic is right for cheap, near-certain, reversible actions — adding to a wishlist, toggling a filter. Pessimistic is right for anything with money or consequence attached — payment, stock reservation, address changes.
The failure mode of optimistic UI is silent rollback. If the action failed and the interface quietly reverts, the person believes it worked — which for an add-to-basket means they discover it at checkout — Error Prevention and Recovery.
What good feedback contains
WHAT HAPPENED "Added to basket"
WHAT IT AFFECTS basket count updates
WHAT'S NEXT "View basket" / "Continue"
HOW TO UNDO where applicable
Undo is worth more than a confirmation dialogue for most reversible destructive actions. “Item removed — Undo” is faster for everyone and safer than “Are you sure?”, which people click through reflexively.
Loading states
UNDER 1s nothing, or a subtle cue
1–3s spinner or skeleton
OVER 3s progress, and what's
happening
"Checking availability…"
UNKNOWN LENGTH indeterminate indicator +
the ability to cancel
Prefer a skeleton to a spinner where the shape of the result is known — it sets the layout, prevents the shift when content arrives, and reads as faster — Loading and Perceived Performance, Cumulative Layout Shift.
Where it’s missing
- Add to basket with no confirmation. The single most common feedback gap in retail
- Filters applying with no indication anything changed, especially where the result set looks similar
- Form submission with no state change
- Background saves with no “saved” indication, so people don’t trust that it saved
- Errors that appear above the fold while the person is looking at the field below — Accessible Forms
- Success states that vanish too fast to read
Accessibility
Visual feedback is not feedback for everyone.
LIVE REGIONS aria-live announces
dynamic changes to
screen readers
FOCUS MOVEMENT move focus to the new
content, or to the error
— Focus Management
NOT COLOUR ALONE an icon or text as well
— Colour Contrast
See: Focus Management · Colour Contrast
A basket count that updates silently is invisible to a screen reader user, and the fix is one attribute — Screen Readers.