| UI or UX | UI + UX - Purchase commitment and order finalization flow | UI + UX - Secure card payment capture and verification form | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Linear multistep task progress indicator | UI + UX - Structured postal or contact address capture flow | UI + UX - Final endpoint page after a transaction is complete |
| UI guidance | Render checkout as a purchase commitment flow with order summary, customer contact, shipping or pickup choice, payment handoff, discount and tax state, total due, review, place-order action, payment processing, and confirmation handoff. | Render card entry as a secure grouped checkout surface with processor-hosted or payment-element fields for card number, expiry, CVC or CID, billing postal code when required, clear labels, card brand feedback, field errors, wallet options, and a masked review summary. | 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. | Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states. | Render address capture as a labelled fieldset or page section with address line, locality, region when needed, postal code, country, and an address lookup only when its coverage is clear. | 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 checkout when a user is ready to turn selected items, services, tickets, or subscriptions into a committed order and needs confidence about total cost, delivery, payment, and recovery before placing the order. | Use payment card entry when a user needs to pay with a card or add a card-on-file payment method and the product can protect cardholder data through a payment processor or compliant card-data environment. | 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 step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains. | Use address entry when the service needs a complete address for delivery, billing, correspondence, identity, eligibility, routing, tax, or account records and downstream systems need reliable address parts. | 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 checkout shows cart items, shipping address, delivery options, taxes, discount, total, payment state, and a Place order button that disables while authorization is pending. | A checkout uses hosted fields for Card number, Expiry, CVC, and ZIP code; it detects Visa, accepts pasted spaces, validates expiry, tokenizes the card, and reviews Visa ending 4242 before charge. | 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 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 benefits claim asks for postcode lookup, lists matching addresses, includes Enter address manually, and then shows editable address line 1, address line 2, town or city, postcode, and country. | 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 checkout hides shipping costs until after card entry and changes the total at the last moment. | A page asks users to paste card number, expiry, CVC, and billing address into one notes field. | A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links. | A two-page form adds a large stepper that consumes space without explaining meaningful progress. | A form has one full-width Address field with placeholder-only instructions and no country, postcode, apartment, or manual recovery path. | A submitted application only redirects to a dashboard toast that says Done, with no reference, receipt, or next-step details. |
| Good UX | A user changes shipping speed, sees delivery date and total update in the sticky order summary, reviews the final charge, places the order once, and lands on a confirmation page with an order number. | A user pastes 4242 4242 4242 4242, sees Visa detected, enters 12/30 and 123, tokenizes the card, and reviews Visa ending 4242 before paying. | 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. | After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current. | A user enters SW1A1AA, sees several addresses, selects Flat 2, adds an organization name, and reviews the stored line, town, postcode, and country parts before continuing. | 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 user cannot find guest checkout, creates an unwanted account, then abandons when email confirmation blocks payment. | A user enters an expired card and receives only Payment failed after submit with no field-level route back to expiry. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite. | A user in a new building cannot proceed because the lookup cannot find the postcode and there is no manual entry option. | A user closes the page after seeing a transient message and later cannot prove the payment or application happened. |
| Best fit | A user is ready to purchase selected items, services, tickets, subscriptions, donations, or orderable options. | Users need to pay with a credit, debit, prepaid, or network card. | A user has provided multiple answers and should verify them before a consequential submit action. | A linear form, application, checkout, or setup flow has three or more meaningful steps. | The product needs a complete postal, delivery, billing, service, or official contact address. | A transaction or service journey has ended and users need durable proof plus next-step information. |
| Avoid when | The task is only secure card capture, bank-details entry, address entry, or a final answer review without purchase state. | The task is to collect bank account identifiers for payout, ACH, direct debit, open banking, or bank transfer. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The journey has only one or two screens. | The product only needs one short location label, room name, or delivery note. | The user remains inside an ongoing task and only needs local proof near the changed object. |
| Required state | Cart summary state with items, quantities, price, shipping, tax, discount, and total due. | Initial secure checkout state with amount, accepted card brands, wallet option, card number, expiry, CVC or CID, and billing postal code if required. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Default state with completed, current, and upcoming steps. | Initial state with country or domestic coverage explained and lookup or manual entry available. | Submitted state immediately after authoritative commit routes to the confirmation page. |
| Accessibility burden | Use headings that expose the current checkout task and step, such as Delivery, Payment, or Review order. | Use visible labels for card number, expiry, CVC or CID, cardholder name, and billing postal code; do not rely on placeholder examples alone. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states. | Group related address fields with a clear heading or legend that states which address is being requested. | Use one clear page H1 or panel title that communicates completion without relying on green color alone. |
| Common misuse | Forcing account creation before purchase when guest checkout would work. | Using one multiline field for card number, expiry, CVC, and billing details. | Using a review page that contains no captured answers. | Using a step indicator as breadcrumbs, tabs, side navigation, or pagination. | Forcing every address through a domestic postcode or ZIP lookup. | Showing a toast or local success strip as the only proof of a completed transaction. |