UX Patterns Guide
UI + UX Error Prevention And Recovery established

Graceful degradation

Design the baseline task first, layer enhancements on top, detect unsupported or failed capabilities, expose the reduced-capability state locally, preserve user work, and keep the core submission, selection, reading, or navigation path available whenever it is genuinely possible.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A richer UI control, script, API, media layer, device capability, or third-party widget improves the task but is not essential to the outcome.
  • The product can express the core task with standard controls, server-rendered content, or a simpler same-surface interaction.
  • Users may reasonably encounter blocked scripts, unsupported APIs, device limits, assistive technology variance, strict firewalls, or low-power conditions.

Avoid when

  • The missing capability is legally, security, or domain required and no simpler route can complete the task.
  • The user must leave the current surface for manual review, phone support, paper submission, or another route; that is a fallback path.
  • The primary issue is connectivity loss that changes save, sync, stale data, or cached behavior; use offline state.
  • The whole service is closed or unavailable; use service unavailable page.
  • Reduced mode would silently submit incomplete, stale, or misleading data.

Problem it prevents

Modern interfaces often rely on JavaScript, CSS, browser APIs, device sensors, heavy media, third-party widgets, or high network performance, and a single missing layer can block users even when the underlying task has a simpler path.

Pattern anatomy

What a strong implementation has to make clear

User need

The enhanced layer improves convenience, speed, visualization, personalization, or input ergonomics but is not the only way to satisfy the user need.

Pattern promise

Design the baseline task first, layer enhancements on top, detect unsupported or failed capabilities, expose the reduced-capability state locally, preserve user work, and keep the core submission, selection, reading, or navigation path available whenever it is genuinely possible.

Required state

Enhanced available state with the richer control active.

Recovery path

A failed script leaves a blank widget with no baseline control.

Access contract

Start from semantic controls and labels that remain available before and after enhancement.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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 branch finder map says Map view unavailable, keeps a searchable list of locations, distance text, and the Select branch action.
  • A user on an older browser books an appointment through labeled date fields even though the calendar enhancement never loaded.
  • A user blocked from geolocation selects a pickup location from a sorted list without restarting the transaction.
Weak implementation

Vague, hidden, hard to recover from

  • A failed calendar script leaves an empty rectangle and a disabled Continue button.
  • An upload flow requires drag-and-drop and hides the standard file picker from keyboard and touch users.
  • A user must enable JavaScript to continue even though the server could accept the same date fields.
  • A user loses typed answers when a third-party address widget fails and the page reloads into an error.
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.
  • Name the unavailable capability in local status text, then keep the working control, entered values, validation messages, primary action, and saved-work state visible.
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.
  • Separate reduced capability from failure: the enhanced experience may be missing, slower, blocked by policy, unsupported by device, or unavailable through a third party, but the task contract should remain clear and honest.
Implementation contract

What the implementation must handle

States

  • Enhanced available state with the richer control active.
  • Reduced-capability state naming the unavailable enhancement.
  • Core path available state with baseline controls and primary action enabled.
  • Unsupported browser or device capability state.

Interaction

  • The baseline path can complete the same core task or the interface explicitly says why it cannot.
  • Enhanced controls mirror their values into baseline controls or share a canonical value so switching modes does not lose work.
  • Unavailable capability messages sit next to the affected feature and do not replace the whole page when the rest of the task remains usable.
  • The primary action stays enabled when baseline values are valid and only the enhancement is missing.

Accessibility

  • Start from semantic controls and labels that remain available before and after enhancement.
  • Do not depend on pointer gestures, drag actions, geolocation, animation, canvas, or custom widgets as the only way to complete the task.
  • Announce capability changes with visible text or status regions tied to the affected component.
  • Keep keyboard order stable when enhanced widgets appear, disappear, or restore.

Review

  • What is the smallest working version of this task before enhancements are added?
  • Which enhancement dependencies can fail independently, and what remains usable when each one fails?
  • Can users complete the same outcome with baseline controls, or does the product need a named fallback path?
  • What data must be preserved when enhancement state changes after the user has already interacted?
Interactive lab

Inspect the states before you copy the pattern

Preserve the task when enhancements fail

Disable enhanced calendar, map, drag/drop, geolocation, animation, and third-party widgets; verify core fields and submission remain usable, then compare blank-widget, feature-only, blocked-submit, hidden-core, and fake-success failures.

Graceful degradation
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Enhanced available state with the richer control active.

Keyboard / Access

Baseline controls are reachable in a logical order even when the enhanced control cannot initialize.

Avoid Generating

Treating JavaScript as mandatory for form submission when server-validated fields could submit the task.
Evidence trail

Source-backed claims behind this guidance

MDN: Graceful degradation

Mozilla - checked

MDN defines graceful degradation as retaining essential functionality in older or less capable environments.

MDN: Progressive enhancement

Mozilla - checked

MDN distinguishes progressive enhancement from graceful degradation and describes their relationship.

Full agent/debug reference

Problem Context

  • The enhanced layer improves convenience, speed, visualization, personalization, or input ergonomics but is not the only way to satisfy the user need.
  • Users may have blocked scripts, older browsers, assistive technologies, low-powered devices, strict corporate firewalls, slow networks, disabled motion, missing permissions, or third-party dependencies outside the product team's control.
  • The product can submit or complete the core task with ordinary HTML, server validation, text fields, select lists, links, file inputs, static content, or a saved state.
  • Some capabilities may be legally, security, or domain required; in those cases the degraded state must explain the blocker rather than pretending the task can continue.

Selection Rules

  • Choose graceful degradation when users stay on the same surface and the core task continues with fewer capabilities.
  • Prefer baseline controls that are always present in the document or reliably rendered by the server before enhancing them with JavaScript or advanced APIs.
  • Use feature detection and dependency health rather than browser labels to decide whether to show enhanced or reduced capability behavior.
  • Tell users which capability is unavailable only when it affects their task; avoid alarming technical language for harmless cosmetic loss.
  • Keep typed values, selected records, uploaded file names, validation results, references, and saved progress intact while switching between enhanced and reduced modes.
  • Allow users to retry or restore the enhancement when it is likely to recover, but do not make retrying the enhancement block the baseline path.
  • Use fallback path when the user must switch to another channel or method outside the current surface.
  • Use offline state when connectivity loss changes what can be cached, saved locally, queued, or synced.
  • Use service unavailable page only when the whole service or transaction route is unavailable, not for a single degraded component.
  • If no core path exists, state that honestly, explain why the missing capability is required, save work when possible, and provide the next accountable route.

Required States

  • Enhanced available state with the richer control active.
  • Reduced-capability state naming the unavailable enhancement.
  • Core path available state with baseline controls and primary action enabled.
  • Unsupported browser or device capability state.
  • JavaScript unavailable or failed enhancement state.
  • Third-party dependency degraded state.
  • Heavy media, animation, or low-power reduced state.
  • Restore or retry enhancement state that does not erase baseline input.
  • Saved-work state when capability changes after user input.
  • No core path state explaining why completion is blocked and what accountable route remains.

Interaction Contract

  • The baseline path can complete the same core task or the interface explicitly says why it cannot.
  • Enhanced controls mirror their values into baseline controls or share a canonical value so switching modes does not lose work.
  • Unavailable capability messages sit next to the affected feature and do not replace the whole page when the rest of the task remains usable.
  • The primary action stays enabled when baseline values are valid and only the enhancement is missing.
  • Retry enhancement, enable permission, use baseline controls, save work, and contact support are distinct actions with distinct outcomes.
  • Reduced mode does not fake success, hide validation, submit partial data, or change eligibility without telling the user.

Implementation Checklist

  • Define the core task independently from enhancement layers, including minimum input, validation, submit, review, and confirmation requirements.
  • Render semantic HTML controls, links, labels, hints, and server validation before JavaScript enhancement attaches richer behavior.
  • Map each enhancement dependency to a reduced-capability behavior: calendar to date fields, map to list, drag-and-drop to file input, geolocation to manual search, animation to static content, and widget to direct form fields.
  • Add feature detection, timeout handling, dependency error handling, and low-power or reduced-motion checks before enabling enhanced-only controls.
  • Preserve canonical values across enhancement failure, restore, reload, browser back, permission denial, and third-party outage.
  • Write local status copy that names the affected capability and the working core path without exposing unnecessary implementation detail.
  • Test with JavaScript disabled, CSS partially failed, unsupported APIs, blocked third-party scripts, older browsers, keyboard-only input, screen readers, touch devices, reduced motion, slow network, and low memory.
  • Instrument degraded-mode entry, successful core completion, enhancement restore, blocked completion, and support handoff so owners see whether an enhancement is harming task completion.

Common Generated-UI Mistakes

  • Treating JavaScript as mandatory for form submission when server-validated fields could submit the task.
  • Leaving a blank widget, spinner, disabled button, or invisible error when an enhancement fails.
  • Hiding baseline controls after enhancement loads, then failing to restore them when the enhanced layer breaks.
  • Calling a separate support route graceful degradation instead of identifying it as a fallback path.
  • Using browser sniffing rather than feature detection and real capability checks.
  • Discarding user input when moving between enhanced and reduced modes.
  • Claiming completion succeeded when the degraded mode omitted required data.

Critique Questions

  • What is the smallest working version of this task before enhancements are added?
  • Which enhancement dependencies can fail independently, and what remains usable when each one fails?
  • Can users complete the same outcome with baseline controls, or does the product need a named fallback path?
  • What data must be preserved when enhancement state changes after the user has already interacted?
  • Does the UI distinguish unsupported capability, denied permission, slow dependency, offline mode, and whole-service outage?
  • How will owners know whether degraded-mode users still complete the task?
Accessibility
  • Start from semantic controls and labels that remain available before and after enhancement.
  • Do not depend on pointer gestures, drag actions, geolocation, animation, canvas, or custom widgets as the only way to complete the task.
  • Announce capability changes with visible text or status regions tied to the affected component.
  • Keep keyboard order stable when enhanced widgets appear, disappear, or restore.
  • Respect reduced motion, zoom, high contrast, assistive technology, and user-disabled scripts without treating them as unsupported users.
  • Make no-core-path states explicit when an accessible same-surface route cannot honestly complete the task.
Keyboard Behavior
  • Baseline controls are reachable in a logical order even when the enhanced control cannot initialize.
  • Restoring an enhancement does not steal focus from a field the user is editing.
  • Retry enhancement and use baseline controls are separate keyboard-operable actions.
  • Disabled enhanced controls are not left in the tab order unless their unavailable state and alternative are clear.
  • Drag, map, calendar, and media enhancements all have keyboard-operable baseline alternatives on the same surface.
Variants
  • No-JavaScript baseline
  • Calendar-to-date-fields degradation
  • Map-to-list degradation
  • Geolocation-to-manual-search degradation
  • Drag-and-drop-to-file-input degradation
  • Animation-to-static-content degradation
  • Third-party-widget degradation
  • Low-bandwidth reduced media
  • Reduced-motion presentation
  • No core path available

Verification

Last verified: