Use complete multiple tasks for a saved transaction hub where users can complete independent sections over one or more sessions; step navigation for a linear in-flow sequence; process list for public journey guidance; and multi-step form for one guided form path.
Use complete multiple tasks for a saved transaction hub where users can complete independent sections over one or more sessions; step navigation for a linear in-flow sequence; process list for public journey guidance; and multi-step form for one guided form path.
Practice the judgment: Imagine this situation: A long service uses a fixed step indicator even though users need to complete sections in different sessions. 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 | Complete multiple tasks | Step navigation / step indicator | Process list / step-by-step navigation | Multi-step form | Start page | Review before submit | Draft state | Confirmation page |
|---|---|---|---|---|---|---|---|---|
| UI or UX | 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 - Single-service or single-task entry point before a transaction begins | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Unpublished object version lifecycle | UI + UX - Final endpoint page after a transaction is complete |
| 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 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 the service or task name, short purpose statement, who can use it, what users need, outcome expectation, time or cost where relevant, one primary start action, resume or sign-in route when relevant, and other access routes in a narrow readable page. | 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. | Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions. | Render a full page after commit with a prominent completion panel, a page heading that names what finished, a reference or receipt when users need one, and a clear section for what happens next. |
| UX guidance | 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. | Use a start page to help users decide whether they are in the right place and begin a specific service with the right materials, expectations, and recovery routes. | 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. | Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version. | Use a confirmation page when the transaction or service journey has ended and users need durable proof, reassurance, next-step timing, or a record they can bookmark, print, quote, or revisit. |
| Good UI | 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 permit application start page states who can apply, the fee, the estimated time, required documents, what happens after submission, a Start now button, and a Resume application link. | 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. | A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. | A grant application page says Application complete, shows reference APP-48291, lists what happens next within 5 working days, and offers Save record, Track application, and feedback links. |
| Bad UI | 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. | Returning users create duplicate applications because the resume route is missing. | Change links lack context, so assistive technology users hear a list of identical Change links. | A draft label is missing from the editor, so users publish or discard the wrong version. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Good UX | 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. | The person reaches the intended result with clear feedback. | 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. | A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers. | A user copies the reference, saves the receipt, follows Track application, and later returns from a bookmark to the same confirmation details or a helpful tracking fallback. |
| Bad UX | 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. | Returning users create duplicate applications because the resume route is missing. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user discards a shared draft and unknowingly removes another editor's unpublished changes. | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. |
| Best fit | 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 user is about to start one named service, transaction, booking, application, check, request, or registration. | A user has provided multiple answers and should verify them before a consequential submit action. | Users need to pause and resume unfinished work across sessions, devices, or routes. | A transaction or service journey has ended and users need durable proof plus next-step information. |
| Avoid when | 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 are still choosing among many topics, products, services, or articles. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The change is a small one-field edit that should be saved or canceled immediately. | The user remains inside an ongoing task and only needs local proof near the changed object. |
| Required state | 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. | Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Published or active state with an available draft. | Submitted state immediately after authoritative commit routes to the confirmation page. |
| Accessibility burden | 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. | Use a clear H1 that names the service or task and matches the page title. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use headings and status regions so screen reader users know whether they are editing a draft or viewing the active version. | Keep interactive controls out of low-contrast panel treatments unless focus and text contrast are explicitly verified. |
| Common misuse | 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. | Treating a product homepage, marketing landing page, or category directory as a start page for a specific service. | Labelling the final commit button Continue. | Using Saved to mean both saved draft and published content. | Showing a toast or local success strip as the only proof of a completed transaction. |