Confirmation page pattern

patterns specs/patterns/confirmation-page.kmd

The receipt surface shown AFTER a user successfully completes a transaction or submission: a prominent success panel with a reference number, an explicit "what happens next" section, and confirmation that any follow-up (email/SMS) was sent. Closes the loop on a journey so the user knows it worked and what to expect. Modeled after the GOV.UK Design System "Confirmation pages" pattern.

Quando este padrão se aplica

Triggers primários

Todos os triggers

Pattern — Confirmation page

Status: v0.1.0 — Draft. Promoted from the GOV.UK parity scan (meta/docs/stack #096). Live URL once rendered: kds.koder.dev/<locale>/patterns/patterns-confirmation-page.html. Source: https://design-system.service.gov.uk/patterns/confirmation-pages/

R1 — When to use

Use a confirmation page when a user completes a discrete transaction with a meaningful outcome the user may need to reference later: a submission, an application, a payment, a booking, a signature.

Do NOT use a confirmation page for:

  • Trivial, reversible actions (a saved setting → use a transient specs/components/snackbars.kmd).
  • Errors or partial success (→ specs/errors/user-facing-messages.kmd).

R2 — Anatomy

ElementRequiredNotes
Confirmation panelYesFull-width success-colored panel; large heading stating the outcome ("Application complete")
Reference numberRecommendedInside or directly under the panel; visually prominent and selectable; the user's claim check
Follow-up noticeRecommended"We have sent a confirmation to {email}" when a message was dispatched
What happens nextYesA short ordered/unordered list of concrete next steps + timeframes
Secondary actionsOptionalPrint/save (R5), give feedback, return to a dashboard

R3 — The confirmation panel

  • Uses the success semantic color from Verge tokens (never raw green); meets contrast for large text on the panel fill.
  • The heading states what was achieved in past tense, plain language ("Payment received", not "Success").
  • The panel is a distinct visual region, not a snackbar/banner (it is the page's primary content, persistent, not dismissible).

R4 — Reference number

  • Rendered as selectable text (the user can copy it); not inside an image.
  • Labeled ("Your reference number is HDX-4827-PLQ").
  • When the same value is emailed (R6 follow-up), the on-page and emailed values are identical.

R5 — What happens next

  • Always present, even when the answer is "nothing — you do not need to do anything else."
  • Concrete and time-bound where possible ("We will review within 5 working days and email you the outcome").
  • Links here open the relevant surface; this page itself does NOT offer a path back INTO the just-completed flow (the journey is done — see R7).

R6 — Email/SMS follow-up

  • State whether a follow-up was sent and to which (masked) destination.
  • If no follow-up is sent, do not imply one.
  • The follow-up content mirrors the on-page reference + next steps so the record survives the user leaving the page.

R7 — Navigation & history

  • The confirmation page is a journey terminus: it does not surface a "back" affordance into the completed flow, and re-submitting (browser back + resubmit) must be idempotent server-side (no double-charge / double-application — see policies/always-on.kmd idempotency).
  • A clear exit exists (to a dashboard / home), distinct from the flow.

R8 — Accessibility & i18n

  • On load, focus moves to the confirmation heading and the outcome + reference are announced (<h1> + live region) so non-visual users get the result immediately.
  • Success is conveyed in words, not color alone (WCAG 1.4.1).
  • All strings are separate i18n keys per specs/i18n/contract.kmd; reference numbers and dates are formatted per locale.

Não-escopo

  • The transactional backend (payment capture, application persistence).
  • Email/SMS template design (owned by the relevant product + brand).
  • Downloadable PDF receipts (optional product-level addition).

Referências