Graceful degradation keeps the same task usable on the same surface when an enhancement, browser capability, script, media layer, device API, or third-party widget is missing. Fallback path moves users to a different route, offline state handles connectivity loss, and service unavailable page handles whole-service closure.
Graceful degradation keeps the same task usable on the same surface when an enhancement, browser capability, script, media layer, device API, or third-party widget is missing. Fallback path moves users to a different route, offline state handles connectivity loss, and service unavailable page handles whole-service closure.
Practice the judgment: Imagine this situation: A map widget fails and the location choice disappears even though a list is available. 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 | Graceful degradation | Fallback path | Offline state | Service unavailable page |
|---|---|---|---|---|
| UI or UX | UI + UX - Reduced-capability same-surface experience that preserves the core task | UI + UX - User-directed alternate route when the primary path cannot complete | UI + UX - Connectivity-mode and local-work continuity state | UI + UX - Whole-service unavailable page |
| UI guidance | Show the baseline controls on the same surface as the failed enhancement: date fields behind a date picker, a location list behind a map, a file input behind drag-and-drop, readable content behind animation, and plain links behind scripted navigation. | 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. | 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. | 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 graceful degradation when a richer layer is unavailable but the user can still complete the core task with a simpler interaction on the current page. | 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. | Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share. | 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 | An appointment date picker says Calendar unavailable, keeps Day, Month, and Year fields with a format hint, and lets users continue after valid entry. | 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 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. | 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 | A failed calendar script leaves an empty rectangle and a disabled Continue button. | The only visible action repeats the failing lookup or request. | A blank page says You are offline even though the app has cached drafts and help content. | A blank white page with only 503 in the browser title. |
| Good UX | The person reaches the intended result with clear feedback. | The person reaches the intended result with clear feedback. | 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. | 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 must enable JavaScript to continue even though the server could accept the same date fields. | A user tries the same failed lookup five times because the manual route is hidden until after repeated failure. | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. | Users miss a deadline because urgent offline support is omitted from the outage page. |
| Best fit | The product can express the core task with standard controls, server-rendered content, or a simpler same-surface interaction. | A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish. | Connection loss or server reachability changes the user's current task. | Maintenance, overload, incident response, dependency failure, deployment, or permanent closure blocks normal use. |
| Avoid when | The user must leave the current surface for manual review, phone support, paper submission, or another route; that is a fallback path. | The only honest next step is retrying the same operation after a transient failure. | A single request failed while the rest of the app is reachable and an error state is clearer. | Only one local section or action failed and users can recover inside the current page. |
| Required state | Enhanced available state with the richer control active. | Primary path available state. | Offline banner or local status that names affected scope. | Planned maintenance page with start or return time. |
| Accessibility burden | Start from semantic controls and labels that remain available before and after enhancement. | Use specific link and button names that describe the alternate method and outcome. | Announce significant connectivity changes with status messaging when they affect the current task. | Keep the explanation in normal reading order with clear paragraphs and links that describe the destination. |
| Common misuse | Treating JavaScript as mandatory for form submission when server-validated fields could submit the task. | Hiding manual entry or support until users repeatedly fail. | Showing only a browser-style offline page when useful cached or local content exists. | Using a full-page spinner for a closed service. |