UX Patterns Guide
UI + UX Navigation And Wayfinding standard

Step navigation / step indicator

Provide a source-backed step indicator for linear tasks with three or more meaningful steps, validated completion states, a matching step heading, and separate Back and Continue controls that preserve entered data.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A linear form, application, checkout, or setup flow has three or more meaningful steps.
  • Users benefit from knowing total progress and remaining work.
  • Steps have stable labels and a mostly stable order.
  • Each step can report completion, current, upcoming, optional, or error status honestly.

Avoid when

  • The journey has only one or two screens.
  • Steps can be completed in any order or the set of steps changes substantially based on answers.
  • The user needs parent hierarchy, same-page section jumps, or result-page traversal.
  • The product cannot preserve or validate data when users move between steps.

Problem it prevents

Users completing a long task across multiple screens need to understand their current position, what is already complete, and what remains without confusing progress with hierarchy or result paging.

Pattern anatomy

What a strong implementation has to make clear

User need

The task spans several screens and users may worry about how much work remains.

Pattern promise

Provide a source-backed step indicator for linear tasks with three or more meaningful steps, validated completion states, a matching step heading, and separate Back and Continue controls that preserve entered data.

Required state

Default state with completed, current, and upcoming steps.

Recovery path

Current step, route, and heading drift out of sync.

Access contract

Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading.
  • A checkout uses short labels such as Cart, Shipping, Payment, Review, and Confirmation with a visible error marker only on the invalid Payment step.
  • After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current.
  • A user returns to a completed step, edits an answer, and the later Review step updates without clearing unrelated data.
Weak implementation

Vague, hidden, hard to recover from

  • A two-page form adds a large stepper that consumes space without explaining meaningful progress.
  • All future steps look clickable and complete even though required earlier fields are blank.
  • Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite.
  • The indicator says Step 4 of 5 while the page content and route still show Step 2.
UI guidance
  • Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states.
  • Keep labels short and task-specific; pair the indicator with an explicit step heading such as 'Step 2 of 5: Contact details' rather than relying on the strip alone.
UX guidance
  • Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains.
  • Treat completion as validated task progress, not page visitation; keep Back and Continue controls separate and preserve answers when users revisit completed steps.
Implementation contract

What the implementation must handle

States

  • Default state with completed, current, and upcoming steps.
  • Current step heading with step number and total step count.
  • Validated completion state after the user successfully continues.
  • Future step blocked or unavailable state before prerequisites are met.

Interaction

  • The current indicator segment always matches the visible page, route, and task heading.
  • A step becomes complete only after required information for that step is valid or saved.
  • Back and Continue move through the linear journey and preserve previously entered answers where valid.
  • Completed steps may be revisited if the product supports editing; future steps remain unavailable until prerequisites are satisfied.

Accessibility

  • Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states.
  • Do not rely on color alone; combine shape, text, icon, or status copy with accessible contrast.
  • Use the correct page heading level for the current step and ensure the indicator does not replace the page title.
  • If the indicator is interactive, make each available step keyboard focusable with visible focus and explain unavailable future steps.

Review

  • Are these stable task milestones, or are they hierarchy pages, result pages, or same-page sections?
  • What proof marks a step complete, and what happens if a completed answer changes later?
  • Can the user revisit completed steps without losing data or invalidating hidden downstream answers?
  • Will future-step links be locked, explained, or removed until prerequisites are complete?
Interactive lab

Inspect the states before you copy the pattern

Track multistep progress

Validate the current step, continue, revisit a completed step, and check whether future steps stay locked until ready.

Step navigation / step indicator
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 state with completed, current, and upcoming steps.

Keyboard / Access

Tab reaches interactive completed steps, Back, Continue, and current form controls in a predictable order.

Avoid Generating

Using a step indicator as breadcrumbs, tabs, side navigation, or pagination.
Evidence trail

Source-backed claims behind this guidance

USWDS Step indicator

U.S. Web Design System - checked

USWDS defines step indicators for multi-page linear forms or processes with three or more high-level steps and requires separate navigation plus current-step semantics.

Carbon Progress indicator

IBM Carbon Design System - checked

Carbon defines progress indicators for linear multistep tasks with completed, current, future, optional, disabled, and error states plus validation guidance.

Material Design Steppers

Material Design - checked

Material defines steppers as progress through logical numbered steps with editable, non-editable, optional, mobile, horizontal, vertical, linear, and non-linear variants.

Full agent/debug reference

Problem Context

  • The task spans several screens and users may worry about how much work remains.
  • The steps have a stable order that can be explained before or during the task.
  • Users must complete or validate information before moving safely to later steps.

Selection Rules

  • Choose step navigation when a form, checkout, onboarding, or application has three or more high-level linear steps.
  • Use it to communicate completed, current, upcoming, optional, and error states; do not use it as ordinary site navigation.
  • Show the current step in the indicator and in the page heading, and keep those labels synchronized with the route or task state.
  • Keep Back and Continue controls separate from the indicator unless the product deliberately supports interactive step navigation.
  • Allow navigation to completed steps only when previous data can be preserved and revisited safely.
  • Lock, disable, or explain future steps until prerequisites are complete; never let users skip required validation silently.
  • Avoid a step indicator for fewer than three steps, nonlinear tasks, highly conditional step counts, or same-page content sections.
  • Use a task list or process list when users need a detailed overview of many tasks that can be completed out of order.

Required States

  • Default state with completed, current, and upcoming steps.
  • Current step heading with step number and total step count.
  • Validated completion state after the user successfully continues.
  • Future step blocked or unavailable state before prerequisites are met.
  • Completed step revisit state with previous answers preserved.
  • Error state on the affected step when validation fails.
  • Responsive compact state with labels shortened or counters used when space is limited.

Interaction Contract

  • The current indicator segment always matches the visible page, route, and task heading.
  • A step becomes complete only after required information for that step is valid or saved.
  • Back and Continue move through the linear journey and preserve previously entered answers where valid.
  • Completed steps may be revisited if the product supports editing; future steps remain unavailable until prerequisites are satisfied.
  • Optional steps are labeled as optional and do not block progress when skipped.
  • If a step has an error, the indicator shows the error state and the page provides field-level or inline recovery guidance.

Implementation Checklist

  • Model steps as task milestones with stable IDs, labels, route ownership, prerequisites, completion status, and optional or error metadata.
  • Render the indicator near the task heading and include a text heading that states the current step number, total, and label.
  • Use semantic ordered-list or equivalent step semantics, and apply aria-current to the current labeled step.
  • Validate the current step before marking it complete or unlocking later steps.
  • Preserve answers when users go back or revisit completed steps, and recompute downstream status when earlier answers change.
  • Keep labels short, responsive, and readable; use counters or omitted labels only when the heading still communicates the current step.
  • Test keyboard operation, focus order, visible focus, screen reader status text, and mobile wrapping.

Common Generated-UI Mistakes

  • Using a step indicator as breadcrumbs, tabs, side navigation, or pagination.
  • Marking steps complete because they were visited rather than validated.
  • Letting users jump to unavailable future steps without saved prerequisites.
  • Showing a fixed step count for a journey whose steps change based on answers.
  • Hiding the actual page heading and expecting the indicator to serve as the only title.
  • Using vague labels such as Details, More, Next, or Processing that do not explain what the step accomplishes.

Critique Questions

  • Are these stable task milestones, or are they hierarchy pages, result pages, or same-page sections?
  • What proof marks a step complete, and what happens if a completed answer changes later?
  • Can the user revisit completed steps without losing data or invalidating hidden downstream answers?
  • Will future-step links be locked, explained, or removed until prerequisites are complete?
  • Does the current route, heading, and indicator all name the same step?
Accessibility
  • Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states.
  • Do not rely on color alone; combine shape, text, icon, or status copy with accessible contrast.
  • Use the correct page heading level for the current step and ensure the indicator does not replace the page title.
  • If the indicator is interactive, make each available step keyboard focusable with visible focus and explain unavailable future steps.
  • Keep disabled future steps honest: if users need to perceive them, do not use disabled styling that removes them from assistive technology without alternate text.
Keyboard Behavior
  • Tab reaches interactive completed steps, Back, Continue, and current form controls in a predictable order.
  • Enter or Space activates an available step button when the indicator is interactive.
  • Arrow-key movement may be supported for an interactive progress indicator if the component documents that behavior.
  • Unavailable future steps are skipped or announced as unavailable with an explanation, not silently focused.
  • After Continue or Back, focus moves to the new step heading or first invalid field according to the validation outcome.
Variants
  • Horizontal step indicator
  • Vertical progress indicator
  • Counter-only step indicator
  • Interactive stepper for revisiting completed steps
  • Non-interactive progress indicator with separate navigation buttons
  • Mobile compact step progress
  • Error-state step indicator
  • Optional-step indicator

Verification

Last verified: