UX Patterns Guide
UI + UX Task And Workflow Patterns established

Complete multiple tasks

Provide a saved task-completion hub that groups meaningful sections, shows task-specific statuses and dependencies, preserves progress across sessions, lets users enter and edit each task, and gates final review or submission until required tasks are complete.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A transaction has several meaningful sections or tasks and progress is saved.
  • Users may need to stop and return later, choose section order, or reopen completed tasks.
  • The final action depends on accurate completion of required tasks and visible unresolved blockers.

Avoid when

  • The service is short enough to complete in one simple flow.
  • The order is strictly linear and users should follow a single Continue path.
  • The page only explains a public process before a transaction starts.
  • The page is mainly a read-only answer review.
  • The product cannot store task completion or dependency state reliably.

Problem it prevents

Long transactions fail when users cannot see the sections involved, which ones are complete, which can be done next, what is blocked, whether progress is saved, or when the transaction is ready to submit.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Complete multiple tasks in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The user is completing an application, registration, onboarding, claim, setup, renewal, disclosure, case file, or other transaction made of several sections.

Pattern promise

Provide a saved task-completion hub that groups meaningful sections, shows task-specific statuses and dependencies, preserves progress across sessions, lets users enter and edit each task, and gates final review or submission until required tasks are complete.

Required state

First visit state with task groups, task names, initial statuses, and start guidance.

Recovery path

Users cannot resume because the hub does not show saved progress or the first incomplete task.

Access contract

Use headings for the service, task groups, and final action area so users understand the hub structure.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An application hub shows Check before you start, Your details, Business information, Upload evidence, Review and send, statuses for Completed, In progress, Not started, Cannot start yet, and a disabled Apply button with the remaining requirement.
  • A health registration service groups related tasks under About you, Medical information, and Evidence, shows 3 of 6 sections complete, and provides a skip link to the first incomplete section.
  • A user completes contact details, leaves work history in progress, returns later, follows Resume work history, edits contact details, uploads evidence, then reaches Review and send only after all required sections are complete.
  • A user tries to open Review and send before uploading evidence and sees that the task is locked until Upload evidence is complete.
Weak implementation

Vague, hidden, hard to recover from

  • A long transaction uses a linear step indicator even though users need to complete independent sections over several sessions.
  • A task list shows coloured status pills only, lets users click the pills instead of rows, and enables Submit while required tasks are incomplete.
  • A returning applicant sees six numbered steps but no saved status, so they reopen completed sections to discover what is missing.
  • A user reaches the final Apply button even though a required disclosure task is still marked Not started.
UI guidance
  • Render complete multiple tasks as a transaction hub with a service name, grouped task sections, task rows, short task names, optional concise hints, completion statuses, blocked or unavailable reasons, completed count, resume cue, and a final action that only becomes available when required tasks are complete.
  • Show completed, in progress, not started, cannot start yet, needs attention, and changed since last visit states as text tied to each task row, with the row itself acting as the primary link into the task rather than status tags behaving like buttons.
UX guidance
  • Use complete multiple tasks when users need control over a long or complex transaction, may not finish in one sitting, and can complete meaningful sections in an order that works for them.
  • Help returning users resume safely by preserving task progress, naming the first incomplete or changed section, explaining dependencies, allowing completed sections to be reopened for edits, and routing to review before final submission.
Implementation contract

What the implementation must handle

States

  • First visit state with task groups, task names, initial statuses, and start guidance.
  • Returning session state with saved progress and resume cue.
  • Not started task state.
  • In progress task state.

Interaction

  • Selecting a task row opens that task and returns users to the same hub with updated status after save, skip, or completion.
  • Task statuses are stored from canonical task data, not inferred only from visited pages or client-side progress.
  • Changing an answer in one task updates dependent task statuses, warnings, and final action readiness.
  • Blocked tasks remain visible with the reason and the task that unlocks them.

Accessibility

  • Use headings for the service, task groups, and final action area so users understand the hub structure.
  • Make the whole task row keyboard reachable when it is a link, and ensure status text is included in the accessible name or description.
  • Do not rely on colour alone for completed, in progress, not started, blocked, optional, or needs attention states.
  • Keep hint text concise because screen readers read it when users interact with the task link.

Review

  • Do users need to complete this transaction over more than one sitting or choose the order of sections?
  • What are the real task groups, required tasks, optional tasks, dependencies, and final submission rules?
  • Which statuses are necessary for users to plan their work, and which create noise?
  • How does the hub change when users return, edit a completed task, or change an answer that affects another section?
Evidence trail

Source-backed claims behind this guidance

GOV.UK complete multiple tasks pattern

GOV.UK Design System - checked

GOV.UK supports transaction-level task visibility, order, completion state, grouping, completion questions, and editable previous sections.

GOV.UK task list component

GOV.UK Design System - checked

GOV.UK supports task row names, statuses, hints, grouped lists, whole-row links, and chosen-order task completion.

NHS complete multiple tasks pattern

NHS digital service manual - checked

NHS supports using complete multiple tasks pages at start and returning sessions, grouping actions into tasks, statuses, and avoiding answer-summary misuse.

NHS task list component

NHS digital service manual - checked

NHS supports task list status updates, all-completed gating, clear task descriptions, concise hints, and grouped lists.

Scottish Government task list pattern

Scottish Government Design System - checked

Scottish Government supports completion counts, current states, application incomplete heading, and skip to first incomplete section.

GOV.UK task list iteration research

Design in government - checked

GOV.UK research supports whole-row clickable tasks, hint text, status tags that do not look like buttons, and less visual weight for completed tasks.

Full agent/debug reference

Problem Context

  • The user is completing an application, registration, onboarding, claim, setup, renewal, disclosure, case file, or other transaction made of several sections.
  • Some sections may be independent while others depend on eligibility, identity, previous answers, uploaded evidence, payment, review, or approval.
  • Users may need to stop, return later, edit completed sections, complete tasks in a personal order, or share work with another contributor.
  • The product must store progress and expose the difference between not started, in progress, completed, blocked, changed, stale, and ready to submit.
  • The final action may have legal, financial, service, or operational consequences, so completion state must be accurate before review or submit.

Selection Rules

  • Choose complete multiple tasks when users need a saved progress hub for several meaningful task sections in a transaction.
  • Use the task list component inside this pattern for row-level task names, hints, links, and statuses; the pattern owns grouping, session return, dependency, edit, and submit readiness behavior.
  • Use step navigation when the service must be completed in a strict linear order and users should continue one page at a time.
  • Use process list when users need public guidance for an ordered journey outside the active saved transaction.
  • Use multi-step form when the work is one guided form path rather than independent sections users can complete in different orders.
  • Use draft state to describe the persisted incomplete record; use complete multiple tasks to navigate and update the sections inside that record.
  • Use review before submit after every required task is complete and users need to check answers before the final action.
  • Use confirmation page only after the final action has succeeded.
  • Group related actions into tasks that match user goals, not internal data models, and split tasks that are too broad to name clearly.
  • Show unavailable task dependencies before users open the task, such as Complete identity check first or Upload evidence before review.
  • Keep statuses few and research-backed; completed tasks should draw less attention than tasks needing action.
  • Always allow users to reopen completed tasks to edit answers and return to the hub with the updated status.

Required States

  • First visit state with task groups, task names, initial statuses, and start guidance.
  • Returning session state with saved progress and resume cue.
  • Not started task state.
  • In progress task state.
  • Completed task state.
  • Cannot start yet or dependency-blocked task state.
  • Needs attention, changed, or stale task state.
  • Optional task state that does not block final action.
  • Task reopened for edit state.
  • Task completion question or explicit return-to-hub state when needed.
  • All required tasks complete state.
  • Final review available state.
  • Final action disabled or blocked state with reasons.
  • Submitted handoff state to confirmation page.

Interaction Contract

  • Selecting a task row opens that task and returns users to the same hub with updated status after save, skip, or completion.
  • Task statuses are stored from canonical task data, not inferred only from visited pages or client-side progress.
  • Changing an answer in one task updates dependent task statuses, warnings, and final action readiness.
  • Blocked tasks remain visible with the reason and the task that unlocks them.
  • Completed tasks remain editable, and edits can move dependent tasks back to needs attention when necessary.
  • The final review or submit action is disabled or replaced with a clear blocked reason until all required tasks are complete.
  • Returning sessions show saved progress, first incomplete task, changed tasks, and any expired or stale evidence.

Implementation Checklist

  • Define transaction tasks, task groups, required versus optional tasks, dependencies, completion rules, status vocabulary, resume behavior, edit behavior, review readiness, and final submission rules.
  • Build task status from server-side saved answers, uploads, verification, payments, approvals, and dependency state rather than page-visit history.
  • Design task rows with short names, optional concise hints, text statuses, whole-row links, unavailable reasons, completed count, and first incomplete shortcut when useful.
  • Add return paths from each task to the hub, including saved, skipped, incomplete, completed, changed, error, and edit outcomes.
  • Update dependent statuses when an answer changes, evidence expires, a required task becomes optional, or a previously completed section needs attention.
  • Gate review and final submission against canonical required task completion and show exact missing or blocked tasks.
  • Test first visit, returning session, mobile wrapping, long task names, screen readers, keyboard row activation, completed edit, dependency changes, stale evidence, optional tasks, final gating, browser Back, and saved-progress recovery.

Common Generated-UI Mistakes

  • Using complete multiple tasks for a service that can be simplified into a single short flow.
  • Using it as an answer summary instead of a progress hub.
  • Showing a task list when the user must complete every step in one strict order.
  • Letting the final action proceed while required tasks are incomplete or stale.
  • Making status tags look like clickable buttons while the task row is the real link.
  • Using too many statuses so users cannot remember what each one means.
  • Hiding locked tasks or dependencies until after users click them.
  • Preventing users from reopening completed tasks to edit answers.

Critique Questions

  • Do users need to complete this transaction over more than one sitting or choose the order of sections?
  • What are the real task groups, required tasks, optional tasks, dependencies, and final submission rules?
  • Which statuses are necessary for users to plan their work, and which create noise?
  • How does the hub change when users return, edit a completed task, or change an answer that affects another section?
  • What exact task blocks review or submission, and can users see how to fix it?
  • Is this page a progress hub, or is it being misused as an answer summary or process guide?
Accessibility
  • Use headings for the service, task groups, and final action area so users understand the hub structure.
  • Make the whole task row keyboard reachable when it is a link, and ensure status text is included in the accessible name or description.
  • Do not rely on colour alone for completed, in progress, not started, blocked, optional, or needs attention states.
  • Keep hint text concise because screen readers read it when users interact with the task link.
  • Do not put separate links inside task hint text when the whole row links to the task.
  • Expose disabled or unavailable task reasons as text tied to that task.
  • After returning from a task, move focus to the updated task row or status summary and announce changed completion state.
Keyboard Behavior
  • Tab order follows the progress summary, task groups, task rows, first incomplete shortcut when present, and final action area.
  • Task rows activate with standard link or button behavior and do not require drag, swipe, or pointer-only interaction.
  • If tasks can be reordered, provide a keyboard and non-drag method.
  • Returning from a task preserves hub scroll position or focuses the task whose status changed.
  • Blocked tasks explain their dependency without trapping focus on disabled controls.
  • Final review or submit controls remain reachable but explain missing required tasks when blocked.
Variants
  • Application task hub
  • Registration task hub
  • Saved service checklist
  • Grouped task list
  • Returning-session task hub
  • Evidence completion hub
  • Setup checklist with dependencies
  • Multi-contributor task hub
  • Review-ready task hub
  • Stale task recovery

Verification

Source trail checked:

Saved items