UX Patterns Guide
UI + UX Navigation And Wayfinding standard

Process list / step-by-step navigation

Provide an end-to-end process list with numbered expandable steps, task links, branch and cost information, and a clear standalone overview that explains the journey order while keeping transaction progress and local navigation separate.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • An end-to-end journey spans several pieces of guidance, service links, departments, or channels.
  • The journey has a specific start and end point and a helpful sequence.
  • Users need a standalone overview they can return to outside an active transaction.
  • Steps require supporting links, essential conditions, costs, offline actions, or alternative paths.

Avoid when

  • The user is inside a live transactional form or wizard.
  • The sequence is actually same-page sections, local page hierarchy, or result pagination.
  • Tasks can be completed in any order and the service must store completion status.
  • The content is only guidance to read and users do not need to take actions.
  • There is no logical or helpful order.

Problem it prevents

Users trying to complete a broad journey across several pieces of guidance, transactions, or offline actions need a coherent ordered map without mistaking that map for the current form step or page hierarchy.

Pattern anatomy

What a strong implementation has to make clear

User need

The journey has a recognizable start and end but spans multiple pages, services, organizations, or channels.

Pattern promise

Provide an end-to-end process list with numbered expandable steps, task links, branch and cost information, and a clear standalone overview that explains the journey order while keeping transaction progress and local navigation separate.

Required state

Standalone process overview with introduction and ordered high-level steps.

Recovery path

Users leave a form because the process list looks like the next-step navigation.

Access contract

Use semantic ordered-list structure so step order is available without relying on visual counters.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A 'Apply for a permit' guide shows numbered steps for Check eligibility, Prepare documents, Submit application, Pay fee, and Track decision, each expanding to relevant links and conditions.
  • A process sidebar on a related content page links back to the standalone process overview and highlights the step that contains the current content page.
  • A user unsure where to start expands 'Prepare documents' and sees both online upload guidance and an offline identity check requirement before starting the application.
  • A user returns later to the standalone process page and can understand what they already read without being forced into an active transaction.
Weak implementation

Vague, hidden, hard to recover from

  • A live form page shows a process list where the Continue button should be, so users leave the transaction to read unrelated guidance.
  • A process list uses headings such as Details, More, Things, and Finish, with no parallel action verbs or clear order.
  • The process list says 'Complete identity check' but opens another step-by-step page that loops back to the original guide.
  • A user clicks a future process step expecting saved progress, but it only opens static guidance and loses the form context.
UI guidance
  • Present the process as a numbered ordered list of three to ten high-level steps, each with a short parallel action heading and enough supporting text or links to complete that stage.
  • Use expandable sections or a clear vertical process layout when steps need task links, conditions, costs, offline actions, or alternative branches; keep the process visually separate from local navigation and transaction buttons.
UX guidance
  • Use process lists to help users understand an end-to-end journey that may span guidance pages, transactions, departments, offline actions, or separate sessions.
  • Explain the intended order honestly while supporting branches such as 'and' or 'or' only when users can tell which tasks apply to their situation.
Implementation contract

What the implementation must handle

States

  • Standalone process overview with introduction and ordered high-level steps.
  • Collapsed step state showing the step number and action heading.
  • Expanded step state showing task links, conditions, costs, or supporting content.
  • Contextual page state with a link back to the standalone process overview.

Interaction

  • Activating a step expands or collapses its supporting task content without changing the user's transaction state.
  • Task links open the relevant guidance, transaction, or external/offline instruction and are labeled with the action users will take.
  • A process page does not claim completion unless it is backed by a service task-list model that stores status.
  • The current content page can point back to the standalone process overview, but the process list itself remains journey guidance.

Accessibility

  • Use semantic ordered-list structure so step order is available without relying on visual counters.
  • Use the correct heading level for each step heading rather than hard-coding heading ranks from examples.
  • Ensure the step number, expanded state, branch labels, costs, and task link purpose are announced or readable.
  • Do not rely on connector lines, numbers, or color alone to explain branch relationships or current context.

Review

  • Does this journey have a clear start, end, and useful order, or is it a set of related options?
  • Which tasks are guidance, transactions, offline actions, external services, costs, or conditional branches?
  • Would users be inside a transaction when they see this, and if so should progress be owned by step navigation or a task list instead?
  • Can each step heading be a short parallel action phrase that users understand without reading the whole step?
Interactive lab

Inspect the states before you copy the pattern

Expand an end-to-end process

Open process steps, inspect task links, and check whether guidance, branches, costs, and offline actions stay separate from transaction progress.

Process list / step-by-step navigation
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

Standalone process overview with introduction and ordered high-level steps.

Keyboard / Access

Tab reaches each expandable step control and task link in the visual process order.

Avoid Generating

Using a process list as a transactional progress indicator.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Step by step navigation

GOV.UK Design System - checked

GOV.UK defines step-by-step navigation for end-to-end journeys with specific start and end points, linked guidance or transactions, useful order, standalone and contextual presentations, and explicit transactional-service exclusions.

USWDS Process list

U.S. Web Design System - checked

USWDS defines process lists for high-level sequential process steps or instructions and distinguishes them from step indicators, side navigation, unordered lists, and general text lists.

GOV.UK task list component

GOV.UK Design System - checked

GOV.UK Task list guidance distinguishes flexible in-service task completion and statuses from specifically ordered journey guidance.

Full agent/debug reference

Problem Context

  • The journey has a recognizable start and end but spans multiple pages, services, organizations, or channels.
  • Users may need to complete the journey over time, return to guidance, or choose between conditional paths.
  • The order is helpful or necessary, but each step may contain several links or pieces of instruction.

Selection Rules

  • Choose a process list when users need an ordered overview of an end-to-end journey that combines guidance, service links, offline actions, or external tasks.
  • Use a process list when the content has a specific start and end point and the order helps users decide what to do next.
  • Keep process steps high-level; split a step when the heading cannot stay short, parallel, and action-oriented.
  • Use expandable detail only for essential context, task links, conditions, costs, or alternate routes that help users complete the step.
  • Use 'and' branches when users must do multiple parallel activities, and 'or' branches when users choose one applicable path.
  • Do not use process lists inside active transactional services where Back, Continue, step navigation, or a task list should own progress.
  • Do not use process lists for unordered option sets, site hierarchy, same-page sections, or a single document's table of contents.
  • Use a task list when the service stores completion status and users need to choose the order of tasks.

Required States

  • Standalone process overview with introduction and ordered high-level steps.
  • Collapsed step state showing the step number and action heading.
  • Expanded step state showing task links, conditions, costs, or supporting content.
  • Contextual page state with a link back to the standalone process overview.
  • Branch state using clear 'and' or 'or' subheadings for parallel or alternative tasks.
  • External or offline task state that explains what happens outside the current website.
  • Mobile state where expanded content remains readable and the process does not become a dense side navigation.

Interaction Contract

  • Activating a step expands or collapses its supporting task content without changing the user's transaction state.
  • Task links open the relevant guidance, transaction, or external/offline instruction and are labeled with the action users will take.
  • A process page does not claim completion unless it is backed by a service task-list model that stores status.
  • The current content page can point back to the standalone process overview, but the process list itself remains journey guidance.
  • Branch labels make it clear whether tasks are cumulative, parallel, alternative, conditional, online, offline, or external.
  • The process order remains stable unless content governance deliberately changes the published journey.

Implementation Checklist

  • Map the real journey before designing the list: start point, end point, required actions, guidance pages, transactions, external links, offline steps, costs, and conditional branches.
  • Write each step heading as a short parallel action phrase and keep the total number of steps between three and ten when possible.
  • Use semantic ordered-list structure with correctly leveled headings inside each step.
  • Provide a standalone overview page and, when shown contextually, include a clear link back to that overview.
  • Keep only essential explanatory text inside steps; move long guidance to linked pages.
  • Label costs, offline requirements, external services, and alternate routes close to the task link.
  • Test expanded/collapsed behavior, keyboard operation, screen reader heading order, mobile wrapping, and whether users understand which tasks apply to them.

Common Generated-UI Mistakes

  • Using a process list as a transactional progress indicator.
  • Using it as side navigation for a website section.
  • Using it as a table of contents for headings on the same page.
  • Numbering a set of unordered options or related links.
  • Showing completion statuses without a service model that can prove completion.
  • Linking step-by-step journeys in loops that send users back and forth.

Critique Questions

  • Does this journey have a clear start, end, and useful order, or is it a set of related options?
  • Which tasks are guidance, transactions, offline actions, external services, costs, or conditional branches?
  • Would users be inside a transaction when they see this, and if so should progress be owned by step navigation or a task list instead?
  • Can each step heading be a short parallel action phrase that users understand without reading the whole step?
  • Will screen reader users hear the step number, heading, branch label, and task links in a useful order?
Accessibility
  • Use semantic ordered-list structure so step order is available without relying on visual counters.
  • Use the correct heading level for each step heading rather than hard-coding heading ranks from examples.
  • Ensure the step number, expanded state, branch labels, costs, and task link purpose are announced or readable.
  • Do not rely on connector lines, numbers, or color alone to explain branch relationships or current context.
  • Keep expanded content concise enough that keyboard and screen reader users can move through the process without excessive repetition.
Keyboard Behavior
  • Tab reaches each expandable step control and task link in the visual process order.
  • Enter or Space expands and collapses a step when the step heading is implemented as a button.
  • Focus remains on the activated step control after expansion unless the product deliberately moves focus to newly revealed content.
  • Task links follow normal link behavior and do not silently mutate transaction state.
  • A contextual back-to-overview link is reachable before the detailed content it orients.
Variants
  • Standalone step-by-step page
  • Contextual process sidebar
  • Expandable numbered process list
  • Static instructional process list
  • Process list with task links
  • Process list with costs
  • Process list with and branches
  • Process list with or branches
  • Process list with offline actions

Verification

Last verified: