| 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 | 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 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 | 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 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. | 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 page titled Start contains a hero carousel, five equal buttons, news cards, and no clear transaction entry point. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links. | An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes. | A submitted application only redirects to a dashboard toast that says Done, with no reference, receipt, or next-step details. |
| 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. | A user checks that they live in the eligible region, sees they need a reference number and 10 minutes, starts the service, and returns later through Resume application without losing their draft. | 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 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 clicks Start now, answers four pages, and only then learns they needed a document that was not mentioned on the start page. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list. | A user closes the page after seeing a transient message and later cannot prove the payment or application happened. |
| 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 create or edit objects that should not become visible, active, submitted, or externally effective until a later action. | 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. | Not-started state with clear start point and expectation of the steps or sections ahead. | 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 no 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 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. | 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. | Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon. | Use one clear page H1 or panel title that communicates completion without relying on green color alone. |
| 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. | Using a review page that contains no captured answers. | 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. |