UX Patterns Guide
UI + UX Task And Workflow Patterns established

Task list

Provide task rows with short user-facing names, concise hints only when useful, accessible status text, clear link targets, understandable unavailable reasons, appropriate grouping, and visual emphasis on tasks needing action rather than completed rows.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A page needs to display a known set of tasks with status and links to start or resume them.
  • Users must scan completion state and choose a task row.
  • The broader service already owns task completion logic and the component needs to present it clearly.

Avoid when

  • Users are browsing arbitrary records rather than completing a fixed set of service tasks.
  • The flow is strictly linear and should not allow free task selection.
  • The page is primarily an answer summary or final review.
  • The service has no reliable status source for each task.
  • The task names or statuses cannot be made understandable without long explanatory text in every row.

Problem it prevents

Task lists fail when row names are vague, hint text is too long, statuses look like buttons, unavailable tasks have no reason, status text is not connected to the row link, or the component tries to carry full transaction behavior by itself.

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 Task list in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The component appears inside a service, application, setup, onboarding, registration, renewal, case, or task hub where users complete a known set of tasks.

Pattern promise

Provide task rows with short user-facing names, concise hints only when useful, accessible status text, clear link targets, understandable unavailable reasons, appropriate grouping, and visual emphasis on tasks needing action rather than completed rows.

Required state

Linked startable task row.

Recovery path

Status is only shown by colour, so users miss whether a task is complete or blocked.

Access contract

Use list semantics for the collection of task rows and clear heading structure for grouped task lists.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A task list row for Upload evidence shows the task name, a short hint, a linked row, and a Needs attention status with the unavailable reason in the row text.
  • A grouped task list shows Company details, Financial history, and References with Completed as plain text and Incomplete as a lower-emphasis status tag.
  • A user scans five task rows, sees that Financial history is incomplete, selects anywhere on that row, completes the section, and returns to find the row status changed to Completed.
  • A user cannot start Review yet, but the disabled row explains Upload evidence first and keeps the task visible.
Weak implementation

Vague, hidden, hard to recover from

  • A task list uses uppercase button-like status pills and users click the status instead of the row.
  • A row contains three inline links, a long explanation, hidden status colour, and no clear target for starting the task.
  • A user returns to a list of internal section codes and cannot tell which task relates to evidence upload.
  • A completed row has the strongest colour treatment, so users repeatedly revisit it instead of incomplete rows.
UI guidance
  • Render a task list as a set of row-level tasks where each row has a short task name, optional single-sentence hint, link target when startable, and status text that indicates whether the task is completed, incomplete, in progress, not started, unavailable, optional, or ready.
  • Keep the row or task name as the primary activation target, attach status and hint text to the task link for assistive technology, and keep status tags visually distinct from buttons so users do not mistake statuses for actions.
UX guidance
  • Use task list when users need to scan a known set of service tasks, understand what each task is, choose a task to start or resume, and see each task's current status.
  • Use the component inside a larger transaction hub or service flow, while keeping component concerns focused on task row anatomy, status readability, hint clarity, grouping, and unavailable-task affordance.
Implementation contract

What the implementation must handle

States

  • Linked startable task row.
  • Completed task row.
  • Incomplete or not started task row.
  • In progress task row.

Interaction

  • A startable task row opens the represented task; the status label is not a separate primary command.
  • Task statuses update when the user returns from the task, using the broader service state as the source of truth.
  • Unavailable tasks remain visible with the reason and do not trap focus on disabled links.
  • Hint text adds context only to the row it describes and does not contain separate links when the whole row is linked.

Accessibility

  • Use list semantics for the collection of task rows and clear heading structure for grouped task lists.
  • Make each startable row reachable through a single obvious link or button target.
  • Associate each row's hint and status with the row link so screen readers announce the task state before navigation.
  • Keep hint text short and avoid nested links inside hints.

Review

  • What task does each row start, and is the name clear enough without internal jargon?
  • Does each row need hint text, or can the name carry the task by itself?
  • Can users distinguish the row link from the non-interactive status label?
  • Is the status text accurate, current, and connected to the row for assistive technology?
Evidence trail

Source-backed claims behind this guidance

GOV.UK task list component

GOV.UK Design System - checked

GOV.UK supports task row title, optional hint, status, href, id prefix, whole-row links, clear task names, concise hints, grouping, and status behavior.

NHS task list component

NHS digital service manual - checked

NHS supports task rows for long complex services, chosen order, status updates after return, all-completed gating, clear names, hints, grouping, and status text.

Scottish Government task list pattern

Scottish Government Design System - checked

Scottish Government supports completion states, completed counts, incomplete heading, and first-incomplete navigation in task lists.

GOV.UK task list iteration research

Design in government - checked

GOV.UK research supports whole-row clickable tasks, hint text, non-uppercase status tags, avoiding button-like statuses, and lower emphasis for completed rows.

Full agent/debug reference

Problem Context

  • The component appears inside a service, application, setup, onboarding, registration, renewal, case, or task hub where users complete a known set of tasks.
  • Each task row may represent one page, a section, a group of questions, an upload, a verification, a review task, or a dependent task.
  • Users need to scan which rows are complete, which need action, which cannot yet start, and which row to open next.
  • Task names, hints, status labels, grouping, and row activation determine whether users can navigate the broader transaction safely.
  • The component may be used with a complete-multiple-tasks hub, but the component itself does not define the service's completion model.

Selection Rules

  • Choose task list when the interface needs row-level task names, links, hint text, and status labels for a known set of service tasks.
  • Use complete multiple tasks when the problem includes saved transaction progress, grouping across sessions, dependencies, final action gating, or review readiness beyond row anatomy.
  • Use step navigation when users must move through a strict ordered path and should not choose any task row in any order.
  • Use process list when users need public journey guidance rather than live task completion status.
  • Use list view when users are browsing or managing arbitrary records with sorting, filtering, pagination, row menus, or bulk selection.
  • Use progress bar when progress is continuous or measured as a bounded operation rather than a set of discrete tasks.
  • Use tag inside task rows only for status labels that need emphasis; keep Completed lower weight so unfinished tasks remain prominent.
  • Use review before submit for answer review after task completion, not inside the task list row itself.
  • Include hint text only when users need extra context to decide whether to open the row, and keep it short.
  • Hide neither blocked nor unavailable tasks; explain the dependency and route users to the unlocking task.
  • Task names should be user-recognizable actions or sections, not internal model names.
  • Connect each row's status and hint to its link or accessible description so screen reader users hear the task state before opening it.

Required States

  • Linked startable task row.
  • Completed task row.
  • Incomplete or not started task row.
  • In progress task row.
  • Unavailable or cannot start yet task row with reason.
  • Needs attention task row.
  • Optional task row.
  • Ready task row.
  • Task row with concise hint text.
  • Task row without hint text.
  • Grouped task list section.
  • Updated status after returning from a task.
  • Mobile stacked row state.
  • Long task name or long status wrapping state.
  • Keyboard focus and hover state for the row link.

Interaction Contract

  • A startable task row opens the represented task; the status label is not a separate primary command.
  • Task statuses update when the user returns from the task, using the broader service state as the source of truth.
  • Unavailable tasks remain visible with the reason and do not trap focus on disabled links.
  • Hint text adds context only to the row it describes and does not contain separate links when the whole row is linked.
  • Completed rows remain navigable if the broader service allows editing or review.
  • Status labels are text first and colour second, and they do not rely on uppercase styling or button-like treatment.
  • Rows wrap cleanly on mobile without detaching the status from the task name.

Implementation Checklist

  • Define each task row's user-facing name, route, status source, optional hint, dependency reason, grouping, and completed-row edit behavior.
  • Use semantic list markup or equivalent list structure with one focusable row or task link per startable task.
  • Associate hint and status text with the task link through visible text and accessible description relationships.
  • Keep status vocabulary small and consistent with the broader service, such as Completed, In progress, Not started, Cannot start yet, Needs attention, Optional, and Ready.
  • Style Completed with lower emphasis than tasks needing action, and avoid status pills that look like primary buttons.
  • Design mobile wrapping so long names, hints, and statuses remain readable without horizontal scrolling.
  • Test keyboard activation, screen reader task names and statuses, blocked rows, status updates after return, long labels, grouping, high zoom, mobile, and row hover/focus affordance.

Common Generated-UI Mistakes

  • Using task list as the whole service architecture without defining saved progress, dependencies, or final readiness elsewhere.
  • Using task list as an answer summary.
  • Using it for arbitrary records that need list view features such as sorting, filters, row actions, or selection.
  • Using it for a strict linear journey that should use step navigation.
  • Making status tags look like buttons or links.
  • Putting several links or actions inside one task row.
  • Writing long hints that screen reader users must hear every time they focus the task.
  • Using colour alone to show status.

Critique Questions

  • What task does each row start, and is the name clear enough without internal jargon?
  • Does each row need hint text, or can the name carry the task by itself?
  • Can users distinguish the row link from the non-interactive status label?
  • Is the status text accurate, current, and connected to the row for assistive technology?
  • What should users do when a task cannot start yet?
  • Is this really a task list component problem, or a complete-multiple-tasks service pattern problem?
Accessibility
  • Use list semantics for the collection of task rows and clear heading structure for grouped task lists.
  • Make each startable row reachable through a single obvious link or button target.
  • Associate each row's hint and status with the row link so screen readers announce the task state before navigation.
  • Keep hint text short and avoid nested links inside hints.
  • Do not rely on colour alone for task status.
  • Ensure non-interactive status tags are not styled like primary buttons or links.
  • Provide text reasons for unavailable tasks and preserve focus when users return from a task with an updated status.
Keyboard Behavior
  • Tab moves through startable task rows or task links in visible order.
  • Enter activates the task row or link, not the status label.
  • Unavailable tasks either expose a focusable explanation or remain readable without creating a dead disabled control.
  • Returning from a task restores focus to the changed row or nearby status summary when possible.
  • Grouped task headings do not add unnecessary tab stops.
  • Mobile and high-zoom layouts preserve one logical activation target per row.
Variants
  • Simple task list
  • Grouped task list
  • Task list with hints
  • Task list with blocked rows
  • Task list with status tags
  • Application task rows
  • Setup task rows
  • Service section list
  • Returning-session task rows
  • Review-ready task rows

Verification

Source trail checked:

Saved items