| 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 | 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. | 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. | 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. | 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. | Use tag when a compact label helps users scan, compare, prioritize, or understand an object's state without opening a message, filter control, or detail panel. | 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. | 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 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. | A two-page form adds a large stepper that consumes space without explaining meaningful progress. | 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. | A tag labelled Click to approve looks like a small button but is not keyboard focusable or actionable. | A list row shows columns of owner, amount, due date, and status but no headers or column sort state. | A blue bar fills across the top of the page with no label, no percent, and no affected object. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or 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 reviewer sorts a queue by due date, then uses Needs evidence tags to triage records that require outreach without opening each record first. | 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 user returns to a list of internal section codes and cannot tell which task relates to evidence upload. | A returning applicant sees six numbered steps but no saved status, so they reopen completed sections to discover what is missing. | Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite. | The process list says 'Complete identity check' but opens another step-by-step page that loops back to the original guide. | A user changes an early answer and the form silently submits later answers that no longer apply. | A user tries to remove a category tag because it looks like an active filter chip, but the page gives no response. | A user selects rows, changes sort order, and the bulk action count still includes hidden rows without saying which rows are affected. | A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option. | 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. | Progress cannot be measured or would be guessed. | 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. | Not-started state with clear start point and expectation of the steps or sections ahead. | 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 semantic ordered-list structure so step order is available without relying on visual counters. | Use a clear page heading on every step and keep it synchronized with route and progress context. | Do not rely on color, icon, or shape alone to express semantic status. | 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 the whole service architecture without defining saved progress, dependencies, or final readiness elsewhere. | 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. | Using list view as a table without column headers or column-state feedback. | Fabricating progress values just to make users feel movement. | Using a review page that contains no captured answers. |