Retry is the action contract for safely attempting the same failed operation again. Error state owns the persistent failure surface, loading spinner represents active pending work before success or failure is known, and offline state explains connectivity mode plus local or queued work.
Retry is the action contract for safely attempting the same failed operation again. Error state owns the persistent failure surface, loading spinner represents active pending work before success or failure is known, and offline state explains connectivity mode plus local or queued work.
Practice the judgment: Imagine this situation: A generic Try again button appears for every failure and traps users in repeated validation or permission errors. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Retry | Error state | Loading spinner | Offline state |
|---|---|---|---|---|
| UI or UX | UI + UX - Scoped failed-operation retry control | UI + UX - Recoverable failure surface | UI + UX - Bounded indeterminate wait indicator for a named action or region | UI + UX - Connectivity-mode and local-work continuity state |
| UI guidance | Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Render a compact spinner only beside, inside, or over the affected action, component, or page region, and pair it with concise text that names what is loading or processing. | Show offline status where it changes the current task, naming what remains available such as cached reports, local draft editing, queued saves, or read-only history. |
| UX guidance | Help the person reach a clear task outcome. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Prevent duplicate or conflicting actions while the operation is in flight, but keep context, status, safe cancellation, and timeout recovery available when the wait exceeds the expected threshold. | Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share. |
| Good UI | A report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | A Pay invoice button becomes Processing payment with a small spinner, disables only duplicate payment actions, and leaves the invoice reference visible. | A field report says Offline: 3 edits saved on this device, cached customer history shown from 10:42, Submit disabled until connection returns, and Retry connection. |
| Bad UI | Retry creates duplicate records, payments, invitations, exports, or queued jobs. | Tiny transient toast for a blocking failure. | A search results panel shows skeleton rows, a spinner, and a progress bar for the same request. | A blank page says You are offline even though the app has cached drafts and help content. |
| Good UX | A second failure increases the wait before the next attempt and then offers cached export, background notification, or support reference after attempts are exhausted. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | After submit, users see payment PAY-2048 processing, can tell the button is temporarily unavailable, and then get either success or retry guidance. | A user loses connection while editing an inspection note, sees it saved on this device, attaches photos to a queue, and later watches the queue sync after reconnect. |
| Bad UX | The app retries aggressively every second during an outage and makes the service harder to recover. | Clearing work after save failure. | The spinner blocks the whole workspace for a small table refresh and prevents users from continuing other work. | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. |
| Best fit | A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason. | A system or task failure blocks expected content or action. | The operation has defined resolution, timeout, cancellation, or failure paths. | Connection loss or server reachability changes the user's current task. |
| Avoid when | The error is caused by invalid user input and correction is required. | Nothing exists yet and the state is expected. | The content layout is predictable and a skeleton would better preserve structure. | A single request failed while the rest of the app is reachable and an error state is clearer. |
| Required state | Retryable failed state with affected operation, object, and preserved request context. | Normal expected state before failure. | Inline processing state for a button or small local action. | Offline banner or local status that names affected scope. |
| Accessibility burden | Expose pending, failed again, cooldown, succeeded, exhausted, and non-retryable outcomes through status text or live regions. | Use appropriate alert or status semantics for newly appearing critical errors. | Give the spinner or affected region an accessible name that identifies the operation. | Announce significant connectivity changes with status messaging when they affect the current task. |
| Common misuse | Offering Retry for every error regardless of whether the user or system state can change. | Using a transient toast for critical errors. | Showing an unlabeled spinner on a blank page. | Showing only a browser-style offline page when useful cached or local content exists. |