UX Patterns Guide
UI + UX Navigation And Wayfinding standard

Back link

Provide one Back link at the top of transaction pages that returns to the previous page in its last-seen state, with clear target text when the journey is complex and safe fallback behavior when history or JavaScript is unreliable.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A multi-page transaction or form asks users one thing per page.
  • Users may need to revise the immediately previous service page.
  • The service can preserve or safely restore the previous page's state.
  • A related details page was reached from a page without additional navigation and needs a simple return.

Avoid when

  • The page is an informational content page with a stable hierarchy.
  • Breadcrumbs are already present and better support orientation.
  • The user needs to move through pages of an ordered result collection.
  • The previous page cannot be known or safely restored.
  • The control would perform an action rather than navigate or intentionally post form state back.

Problem it prevents

Users in a multi-page transaction need an explicit, predictable way to return to the previous service page without losing progress or interpreting hierarchy navigation.

Pattern anatomy

What a strong implementation has to make clear

User need

The journey has multiple pages or questions and users may need to revise a previous answer.

Pattern promise

Provide one Back link at the top of transaction pages that returns to the previous page in its last-seen state, with clear target text when the journey is complex and safe fallback behavior when history or JavaScript is unreliable.

Required state

Default transaction page with one Back link before main content.

Recovery path

The control sends users to an unrelated browser-history entry.

Access contract

Keep the Back link in a predictable reading order before main content, so skip links can bypass repeated navigation.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A question page shows a single 'Back' link above the H1, before the form, and the Continue button remains the only primary action after the fields.
  • A complex admin journey labels the control 'Back to eligibility' so users know which page they will return to.
  • A user goes back from Review answers to Contact details and sees the email address and phone number they already entered.
  • A user who is unsure about an answer can return one page, change it, and continue without re-entering unrelated data.
Weak implementation

Vague, hidden, hard to recover from

  • A page shows Back, breadcrumbs, a previous button, and pagination controls at the same time.
  • The Back link sits next to Continue and looks like a secondary form action rather than navigation.
  • Clicking Back returns to the browser's previous marketing page instead of the last service page.
  • Going back clears the previous page's fields, forcing the user to re-enter information.
UI guidance
  • Render one unobtrusive Back link near the top-left of a transaction page, before the main content, with a destination that returns to the previous service page.
  • Use a normal link when navigating to a known previous URL, and render it as a button only when the control must submit or post current form state back to the previous page.
UX guidance
  • Use Back links to help users safely move one step back in a multi-page transaction without relying on browser history or losing previously entered information.
  • Preserve the previous page in the state the user last saw it; if that cannot be guaranteed, hide the control without JavaScript or use a server-backed route that can restore state.
Implementation contract

What the implementation must handle

States

  • Default transaction page with one Back link before main content.
  • Previous-page restored state with valid entered values pre-populated.
  • Complex journey state with target-specific back text.
  • No safe previous page or no-JavaScript state where the control is hidden or uses a safe route.

Interaction

  • Activating the Back link returns one service step or previous transaction page, not a parent hierarchy page.
  • The destination page restores the values, filters, or answers the user last saw when those values remain valid.
  • The Back link appears before main content in reading order so skip links can bypass it with other navigation.
  • The control does not submit the current page unless it is deliberately implemented as a button to preserve posted form data.

Accessibility

  • Keep the Back link in a predictable reading order before main content, so skip links can bypass repeated navigation.
  • Use link semantics for navigation and button semantics only for form-posting behavior.
  • Ensure focus style, link underline, and target size make the small control discoverable and operable.
  • Do not rely on color or an icon alone; include visible Back or destination text.

Review

  • What exact page will this Back link return to, and can that page restore its last-seen state?
  • Is this page part of a transaction, or would breadcrumbs or related links better fit the user's mental model?
  • Will a direct visitor or user without JavaScript see a safe and honest control?
  • Does the link text need to name the destination because the journey branches?
Interactive lab

Inspect the states before you copy the pattern

Enter a value, continue, then use Back and check whether the previous transaction page is restored.

Back link
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

Default transaction page with one Back link before main content.

Keyboard / Access

Tab reaches the Back link before the main content and before form fields on a transaction page.

Avoid Generating

Using Back as a breadcrumb or parent-category link.
Evidence trail

Source-backed claims behind this guidance

Back link

GOV.UK Design System - checked

GOV.UK defines Back links for multi-page transactions, requires previous-page state restoration, places them before main content, and forbids combining them with breadcrumbs.

Back link

NHS Digital service manual - checked

NHS limits Back links to transactional services or forms, documents redundant-entry restoration, top-left placement, and button-backed variants when posting form data.

Link

VA.gov Design System - checked

VA documents the Back link variation as a breadcrumb replacement for multi-step forms, short forms, and related-page returns.

Full agent/debug reference

Problem Context

  • The journey has multiple pages or questions and users may need to revise a previous answer.
  • Users may distrust or misunderstand the browser Back button because some services lose progress when it is used.
  • The current page is part of a transaction rather than a hierarchical content structure.

Selection Rules

  • Choose a Back link on question pages and other multi-page transaction pages where users may need to return one step.
  • Return users to the previous page they were on in the state they last saw it, including pre-populated valid answers.
  • Use simple 'Back' text for simple linear services, and use target-specific text such as 'Back to eligibility' when the journey has branching or admin areas.
  • Never show a Back link together with breadcrumbs; research which is more useful if both seem plausible.
  • Do not use a Back link on ordinary content pages where hierarchy, related links, or breadcrumbs better explain where the page sits.
  • Do not rely on JavaScript-only history if there may be no safe previous page; provide a real href, hide the link without JavaScript, or route through server state.
  • Use a button only when the back control needs to post form data back; otherwise keep it a navigation link.

Required States

  • Default transaction page with one Back link before main content.
  • Previous-page restored state with valid entered values pre-populated.
  • Complex journey state with target-specific back text.
  • No safe previous page or no-JavaScript state where the control is hidden or uses a safe route.
  • Button-backed state when current form data must be posted before returning.
  • Validation state where returning preserves valid entries and does not silently reuse invalid or unsafe information.

Interaction Contract

  • Activating the Back link returns one service step or previous transaction page, not a parent hierarchy page.
  • The destination page restores the values, filters, or answers the user last saw when those values remain valid.
  • The Back link appears before main content in reading order so skip links can bypass it with other navigation.
  • The control does not submit the current page unless it is deliberately implemented as a button to preserve posted form data.
  • If the destination is ambiguous, the visible text names the target page rather than relying on a generic Back label.
  • The control is removed, disabled by routing, or changed to a safe URL when there is no trusted previous transaction page.

Implementation Checklist

  • Place the Back link before the main content and away from primary submit or Continue controls.
  • Store transaction step state server-side, in the URL, or in form state so the previous page can be restored.
  • Use a real href to the previous service URL where possible instead of depending only on window.history.back().
  • Pre-populate previous answers when the user goes back, unless the information is invalid, unsafe, or security-sensitive.
  • Remove breadcrumbs from pages that use a transaction Back link.
  • Choose target-specific copy for non-linear or administrative journeys.
  • Test keyboard order, focus visibility, target size, and no-JavaScript fallback.

Common Generated-UI Mistakes

  • Using Back as a breadcrumb or parent-category link.
  • Combining Back links with breadcrumbs on the same transaction page.
  • Putting Back next to Continue so it looks like a secondary form action.
  • Calling browser history when the previous page might be outside the service.
  • Clearing the previous page's entered values when users go back.
  • Showing a Back link on content pages that need hierarchy or related-link navigation instead.

Critique Questions

  • What exact page will this Back link return to, and can that page restore its last-seen state?
  • Is this page part of a transaction, or would breadcrumbs or related links better fit the user's mental model?
  • Will a direct visitor or user without JavaScript see a safe and honest control?
  • Does the link text need to name the destination because the journey branches?
  • Could the previous values become invalid, unsafe, or security-sensitive when restored?
Accessibility
  • Keep the Back link in a predictable reading order before main content, so skip links can bypass repeated navigation.
  • Use link semantics for navigation and button semantics only for form-posting behavior.
  • Ensure focus style, link underline, and target size make the small control discoverable and operable.
  • Do not rely on color or an icon alone; include visible Back or destination text.
  • If an accessibility checker warns about the back link outside landmarks, evaluate the service context rather than moving it into a worse reading order.
Keyboard Behavior
  • Tab reaches the Back link before the main content and before form fields on a transaction page.
  • Enter activates a link-backed Back control; Enter or Space activates a button-backed back control.
  • After returning, focus follows the service's page-load convention and the restored page heading or first field is reachable.
  • The Back control is not placed so close to Continue or other buttons that keyboard or pointer users accidentally activate the wrong control.
Variants
  • Simple Back link
  • Back to named page
  • Inverse back link on dark background
  • Button-rendered back control for posted form state
  • Safe fallback back link
  • Related-page return link

Verification

Last verified: