Fallback path gives users a different route to continue or complete the task when the primary path is blocked. Retry repeats the same operation, error state explains and recovers from a failure in place, and service unavailable page owns a whole-service closure or outage route.
Fallback path gives users a different route to continue or complete the task when the primary path is blocked. Retry repeats the same operation, error state explains and recovers from a failure in place, and service unavailable page owns a whole-service closure or outage route.
Practice the judgment: Imagine this situation: An error state hides the fallback in a support article rather than making it part of the recovery surface. 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 | Fallback path | Retry | Error state | Service unavailable page |
|---|---|---|---|---|
| UI or UX | UI + UX - User-directed alternate route when the primary path cannot complete | UI + UX - Scoped failed-operation retry control | UI + UX - Recoverable failure surface | UI + UX - Whole-service unavailable page |
| UI guidance | Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence. | 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 full page with the service name, unavailable scope, status, return time or update promise, saved-work status, alternate route, support contact, and request or incident reference when available. |
| UX guidance | Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task. | 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. | Use a service unavailable page when the service, transaction, or route is intentionally closed, under maintenance, overloaded, permanently closed, or unable to handle requests at the entry point. |
| Good UI | A service dependency outage panel says Identity check unavailable, shows saved application answers, and offers Upload documents for manual review with expected review time. | 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 benefits application page says the service is unavailable from 22:00 to 01:00, names the affected transaction, says saved drafts remain for 30 days, and links to urgent phone support. |
| Bad UI | The only visible action repeats the failing lookup or request. | Retry creates duplicate records, payments, invitations, exports, or queued jobs. | Tiny transient toast for a blocking failure. | A blank white page with only 503 in the browser title. |
| Good UX | The person reaches the intended result with clear feedback. | 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. | A user returns during planned maintenance, sees a precise reopening time, learns their draft is saved, and uses an alternate phone channel for an urgent deadline. |
| Bad UX | A user tries the same failed lookup five times because the manual route is hidden until after repeated failure. | The app retries aggressively every second during an outage and makes the service harder to recover. | Clearing work after save failure. | Users miss a deadline because urgent offline support is omitted from the outage page. |
| Best fit | A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish. | 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. | Maintenance, overload, incident response, dependency failure, deployment, or permanent closure blocks normal use. |
| Avoid when | The only honest next step is retrying the same operation after a transient failure. | The error is caused by invalid user input and correction is required. | Nothing exists yet and the state is expected. | Only one local section or action failed and users can recover inside the current page. |
| Required state | Primary path available state. | Retryable failed state with affected operation, object, and preserved request context. | Normal expected state before failure. | Planned maintenance page with start or return time. |
| Accessibility burden | Use specific link and button names that describe the alternate method and outcome. | 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. | Keep the explanation in normal reading order with clear paragraphs and links that describe the destination. |
| Common misuse | Hiding manual entry or support until users repeatedly fail. | Offering Retry for every error regardless of whether the user or system state can change. | Using a transient toast for critical errors. | Using a full-page spinner for a closed service. |