Feedback, Loading, Errors & Recovery

Heuristic #1 (visibility of system status) in practice. Every user action gets an immediate, proportionate response; every wait is managed; every failure has a path out.

Response-time playbook (Nielsen 1993 thresholds, after Miller 1968)

• <0.1 s: no indicator needed — the change itself is the feedback (pressed state, instant toggle).
• 0.1–1 s: subtle acknowledgment (button spinner, ripple); keep UI responsive.
• 1–10 s: visible progress. Indeterminate spinner only if truly unknown and short; skeleton screens for content-shaped loads (set layout expectations, reduce perceived wait — popular convention with favorable but not unanimous research); determinate bar when progress is knowable.
• >10 s: determinate progress + time estimate + cancel; let the user do other things; notify on completion.
• Perceived performance tricks: optimistic UI (assume success, reconcile on failure — standard for likes/sends), progressive content loading (text first, media after), and honest skeletons (don't fake content). Note: operations that feel too instant for their gravity can reduce trust ("labor illusion," Buell & Norton 2011 — showing the work increases perceived value); a brief "Searching 400 airlines…" can help.

Optimistic UI — the rollback contract

Optimism is only honest if failure is handled visibly:

• On failure, revert the UI state AND say so — a silent revert reads as a bug or gaslighting. Toast/inline notice: what failed + retry.
• For content the user created (message, comment), never discard it — keep the item in place marked "Failed to send · Retry / Delete" so the work and its context survive.
• Queue and auto-retry transient failures with idempotency keys so retries can't double-post; cap retries, then surface the error.
• Don't be optimistic about irreversible or high-stakes operations (payments, deletes of shared data) — those wait for the server.

Offline & sync-conflict UX

• Offline: cached content + queued actions + clear reconnect behavior; show sync state per item ("pending", "synced") rather than a global mystery spinner; timestamp staleness ("last updated 2 h ago").
• Conflicts: last-write-wins silently destroys work — acceptable only for trivial, single-owner data. Prefer field-level merging; for collaborative text, CRDT/OT approaches make most conflicts disappear structurally (engineering choice with direct UX payoff).
• When a real conflict must be surfaced, show both versions with authorship and time, offer keep-mine / keep-theirs / merge, and never delete either side until the user decides. Only interrupt for conflicts that matter; auto-resolve the rest and make the resolution inspectable (version history as the safety net).

Confirmations, results & undo

• Action results: inline state change > toast/snackbar (transient, non-blocking) > dialog (only when a decision is required).
• Toast accessibility: expose toasts as ARIA live regions — role="status" (polite) for confirmations, role="alert" only for urgent problems (WCAG 4.1.3 Status Messages: state changes must be announced without focus moving). Never put the only route to an action inside an auto-dismissing toast (keyboard/screen-reader users may never reach it); pair "Undo" toasts with another undo path, keep them on screen long enough to act (generous timeouts or dismiss-on-hover; auto-dismissal of essential info runs afoul of WCAG 2.2.1 Timing Adjustable), and don't stack more than needed.
• Prefer undo to confirmation for destructive-but-recoverable actions (Gmail's undo send is the canonical case); confirmation dialogs suffer habituation — users click through them reflexively (documented in security-warning research, e.g., Egelman et al. CHI 2008). Reserve confirmation for irreversible/high-stakes acts, and make it specific (type the project name to delete) when stakes are extreme.

Error message anatomy (heuristic #9)

1. Say what happened, precisely, in plain language (no codes alone, no jargon, no ALL-CAPS alarm).
2. Say why, if known and useful.
3. Say what to do next — the fix, a retry button, an alternative path, or who to contact WITH the error reference.
4. Tone: calm, no blame, no cutesy jokes on high-stakes failures (money, data loss). Humor reads as mockery when the user is blocked.
5. Placement: at the point of failure (inline by the field; in the component that failed), visible without scrolling.

• Preserve user work through ANY error. Losing typed content is among the most rage-inducing failures (documented in "rage click" analytics literature and every usability lab ever).

System-level failures & status pages

• Partial failure: degrade by feature, not whole-app error page. Maintenance: advance notice + in-product banner. 404s: search + popular destinations, not a joke dead-end.
• Status pages: host on separate infrastructure so the status page survives the outage; state impact in user terms ("logins failing for ~20% of users"), timestamp updates at a stated cadence, and post an honest retrospective. Link to it from in-product error states so support tickets say "known issue" instead of piling up. Update the status page before users discover the outage themselves — a green dashboard during a visible outage permanently damages trust (convention across major incident-communication practice, e.g., Atlassian's and Google's public incident guidance).

Sources

• Nielsen, J. (1993). Usability Engineering — response-time limits; Nielsen heuristics #1, #3, #5, #9 (nngroup.com); Miller, R. (1968) — original response-time thresholds.
• Buell, R. & Norton, M. (2011). "The Labor Illusion." Management Science, 57(9).
• Egelman, S., Cranor, L. & Hong, J. (2008). "You've been warned…" Proc. CHI '08 — warning habituation.
• W3C WCAG 2.2 — SC 4.1.3 Status Messages, 2.2.1 Timing Adjustable; WAI-ARIA live-region documentation (w3.org).
• Material Design — progress indicators, snackbars (m3.material.io); Apple HIG — feedback, alerts (developer.apple.com/design).
• Atlassian — incident communication / statuspage guidance (atlassian.com/incident-management) — practitioner convention.