Use task list for the component-level rows, links, hints, and statuses that show task completion; complete multiple tasks for the saved transaction hub; step navigation for an ordered in-flow sequence; and process list for public journey guidance.
Use task list for the component-level rows, links, hints, and statuses that show task completion; complete multiple tasks for the saved transaction hub; step navigation for an ordered in-flow sequence; and process list for public journey guidance.
Practice the judgment: Imagine this situation: Status tags look like clickable buttons and users try to activate them instead of the task row. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Task list | Complete multiple tasks | Step navigation / step indicator | Process list / step-by-step navigation | Multi-step form | Tag / status tag | List view | Progress bar | Review before submit |
|---|---|---|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Component-level list of linked task rows with names, hints, and statuses | UI + UX - Saved transaction hub for completing several sections or tasks over one or more sessions | UI + UX - Linear multistep task progress indicator | UI + UX - End-to-end ordered journey guidance with linked tasks | UI + UX - Multi-page transaction with saved step state | UI + UX - Compact static category or status label attached to an object | UI + UX - Vertical object-summary browsing surface | UI + UX - Measurable system-operation progress indicator | UI + UX - Final editable answer summary before committing a transaction |
| UI guidance | Give each control a clear label and visible state. | 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 a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states. | 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. | Render each step as a focused page with a clear heading, progress context when useful, Back and Continue controls, local validation, and a final review page before submission. | Render a tag as a short non-interactive label attached to the object, row, card, heading, count, or result it describes, using stable placement and a visual weight lower than the object's title or primary action. | Render a labelled vertical list where each row has a strong primary label, concise supporting text, metadata, status, optional leading media, and row-scoped actions with clear hit targets. | Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. |
| 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. | 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. | Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains. | Use process lists to help users understand an end-to-end journey that may span guidance pages, transactions, departments, offline actions, or separate sessions. | Use a multi-step form when a transaction is too long, conditional, high-stakes, or hard to recover from as one page, and users need manageable saved progress. | Keep tag meaning synchronized with the underlying object state and route interactive filtering, selection, removal, or recovery work to chips, controls, inline messages, or alerts instead. | Use list view when scanning and opening object summaries is faster than comparing columns or inspecting large visual cards. | Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. |
| Good UI | 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 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 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 '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 benefit application has Eligibility, Contact details, Documents, Review, and Submit pages, with the current step named in the heading and completed steps shown from saved data. | A claims table shows status tags such as Pending review, Approved, and Needs evidence in the Status column, with semantic colors and the same text used in detail views. | A ticket list row shows TCK-2048 Database backup failed, a one-line incident summary, Critical status, owner, updated time, selected state, and a labelled More actions menu. | A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. |
| Bad UI | A task list uses uppercase button-like status pills and users click the status instead of the row. | A long transaction uses a linear step indicator even though users need to complete independent sections over several sessions. | All future steps look clickable and complete even though required earlier fields are blank. | A live form page shows a process list where the Continue button should be, so users leave the transaction to read unrelated guidance. | A five-screen flow shows all steps as complete after users only viewed them. | Every ticket row has nine colorful tags for team, priority, system, phase, age, owner, source, queue, and channel, making the table harder to scan. | Every row has five unlabeled icon buttons, and the whole row also navigates. | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. | Change links lack context, so assistive technology users hear a list of identical Change links. |
| Good UX | 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 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. | After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current. | 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 completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step. | A user sees an Approved status tag beside a claim title and then opens the detail page where the same status and next-step explanation appear in context. | A user filters tickets to Critical, selects two rows, opens the details panel for one ticket, then clears the filter and the selected count and active ticket remain understandable. | A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. |
| Bad UX | A completed row has the strongest colour treatment, so users repeatedly revisit it instead of incomplete rows. | A task is marked completed because it was visited, even though required fields are missing. | The indicator says Step 4 of 5 while the page content and route still show Step 2. | The process list says 'Complete identity check' but opens another step-by-step page that loops back to the original guide. | A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again. | A record changes from Pending to Denied but a cached tag still says Pending, so the user starts the wrong follow-up task. | A user tries to preview a file but the row click opens navigation while the small trailing icon deletes the file. | Users leave after 100% transfer even though server processing later rejects the file. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. |
| Best fit | A page needs to display a known set of tasks with status and links to start or resume them. | A transaction has several meaningful sections or tasks and progress is saved. | A linear form, application, checkout, or setup flow has three or more meaningful steps. | An end-to-end journey spans several pieces of guidance, service links, departments, or channels. | A transaction spans several ordered pages or sections. | A compact category, state, phase, freshness marker, priority, or count helps users scan a group of objects. | Users need to scan and act on a collection of objects using compact summaries. | A system operation has a measurable total or bounded progress value. | A user has provided multiple answers and should verify them before a consequential submit action. |
| Avoid when | Users are browsing arbitrary records rather than completing a fixed set of service tasks. | The service is short enough to complete in one simple flow. | The journey has only one or two screens. | The user is inside a live transactional form or wizard. | The fields are short, related, and easier to scan together on one page. | Users need to click, remove, select, or edit the label. | Users need to compare many records across shared attributes. | The wait is short and only needs scoped activity feedback. | The task is a single low-risk field with clear inline validation and an obvious submit action. |
| Required state | Linked startable task row. | First visit state with task groups, task names, initial statuses, and start guidance. | Default state with completed, current, and upcoming steps. | Standalone process overview with introduction and ordered high-level steps. | Current step state with heading, saved context, local answer controls, Back, and Continue. | Neutral category tag attached to a row, card, heading, or object summary. | Default list state with label or heading, row count or context, visible row summaries, and primary row identity. | Idle state before the operation starts. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. |
| Accessibility burden | Use list semantics for the collection of task rows and clear heading structure for grouped task lists. | Use headings for the service, task groups, and final action area so users understand the hub structure. | Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states. | Use the correct heading level for each step heading rather than hard-coding heading ranks from examples. | Use a clear page heading on every step and keep it synchronized with route and progress context. | Keep read-only tags out of the tab order and avoid hover, active, or focus styling that implies a control. | Use semantic list markup for ordinary object lists; use listbox only when rows are options in a single control. | Provide an accessible name that identifies the operation and affected object. | Use headings that make the review task explicit, such as Check your answers before sending your application. |
| Common misuse | Using task list as an answer summary. | Using complete multiple tasks for a service that can be simplified into a single short flow. | Using a step indicator as breadcrumbs, tabs, side navigation, or pagination. | Using a process list as a transactional progress indicator. | Using a multi-step form to hide a short related form that users should review on one page. | Making a static tag look clickable or focusable. | Putting too many independent controls in every row until the list becomes a keyboard trap. | Fabricating progress values just to make users feel movement. | Labelling the final commit button Continue. |