Fallback path

Problem Context

• The primary route depends on search, lookup, verification, payment, upload, network, JavaScript, device capability, third-party service, account access, or user digital confidence.
• The product has a credible alternate route such as manual entry, evidence upload, phone support, webchat, cached data, branch office, paper form, later handoff, or replacement service.
• Users may have already entered data or gathered evidence that must not be lost when switching paths.
• The alternate route may have different timing, eligibility, tracking, privacy, support, or proof requirements that users need before committing.

Selection Rules

• Choose fallback path when the user needs an alternate way to finish the same task after the primary method is blocked, unsupported, unavailable, or unsuitable.
• Offer fallback before repeated failure traps users; do not require users to fail several times before seeing a manual or assisted route.
• Name the fallback by method and outcome, not vague copy such as Other options or Continue.
• Preserve entered data, selected records, uploads, payment state, application reference, and deadline context across the switch whenever technically and legally possible.
• Explain tradeoffs such as slower review, manual evidence check, limited availability, support hours, offline submission, or missing automatic validation.
• Keep the primary path available to retry or return to when it remains useful, but separate retrying the same action from switching to a different route.
• Use error state to explain the failed condition; use fallback path for the alternate route that changes how users continue.
• Use service unavailable page when an entire service route is closed; include fallback path there only when users can complete by another channel.
• Use offline state when connection loss changes what users can do locally; include fallback path only when cached, local, or alternate-channel completion is actually supported.
• Do not present a link as a fallback unless it has a real completion, submission, tracking, or support contract.

Required States

• Primary path available state.
• Primary path blocked or unsupported state with cause.
• Fallback offered state with method, scope, and tradeoff.
• Fallback selected state showing what data carries over.
• Fallback in-progress state with changed fields, evidence, channel, or support handoff.
• Return-to-primary state when switching back is safe.
• Fallback completed state with confirmation or next step.
• Fallback unavailable state that explains why no alternate route exists.
• Data-loss prevention state before leaving or restarting the current path.
• Assisted-support state with reference, contact route, hours, and information needed.

Interaction Contract

• The fallback path is a different route to the same user outcome or an explicitly named support handoff, not another attempt at the same failing operation.
• Users can see what will happen to their current data before switching paths.
• The fallback route carries forward a stable reference or clearly explains why the user must start a separate process.
• The UI distinguishes Try again, edit input, switch to manual entry, contact support, download form, and return later actions.
• If the fallback has reduced validation, slower review, limited hours, or extra evidence, that tradeoff is visible before users choose it.
• If no credible fallback exists, the page says so directly and gives the safest next step instead of inventing a dead-end route.
• Switching paths does not silently clear user work, create duplicate submissions, or change eligibility decisions.

Implementation Checklist

• Map each primary-route dependency to whether a real fallback exists, who owns it, and what outcome it can complete.
• Define the data handoff contract: retained fields, dropped fields, uploaded files, references, timestamps, consents, and audit trail.
• Write fallback labels that name both method and outcome, such as Enter address manually or Upload documents for manual review.
• Store a stable reference before switching to support, paper, offline, or manual review channels.
• Show expected timing, support hours, proof requirements, privacy implications, and tracking behavior for slower or assisted paths.
• Provide a safe return-to-primary control where switching back can preserve work and reduce unnecessary manual processing.
• Instrument fallback selection, completion, abandonment, return-to-primary, and support demand so owners can identify failing primary paths.
• Test no-match lookup, JavaScript failure, unsupported file/device, third-party outage, support closed, duplicate submission, back button, refresh, mobile width, keyboard flow, and screen readers.

Common Generated-UI Mistakes

• Hiding manual entry or support until users repeatedly fail.
• Calling Retry a fallback even though it repeats the same broken operation.
• Offering a download or phone number without an application reference or completion contract.
• Clearing typed data, selected files, or uploaded evidence when users switch paths.
• Using a fallback path to avoid fixing a primary route that fails for many users.
• Giving a fallback that changes eligibility, price, deadline, or privacy without saying so.
• Showing no fallback when a known alternate channel exists.

Critique Questions

• What primary path can fail or be unsuitable, and what exact route lets users continue?
• Does the fallback complete the same task, or is it only a support handoff?
• Which data, uploads, consents, and references carry over when users switch?
• What timing, validation, privacy, deadline, or support-hour tradeoffs change?
• Can users return to the primary path without losing work?
• How will the team know the fallback is being used because the primary path is broken?