Confirmation page

Problem Context

• The user has completed a transaction such as applying, booking, paying, submitting a survey, publishing, closing an account, or sending a consequential request.
• The action is committed enough that pre-submit editing is no longer the main model, but the service may still need track, amend, cancel, or contact routes.
• The user may need to show proof later, quote a reference number, wait for a response, prepare for an appointment, or understand that there is nothing more to do.
• The page may be bookmarked, printed, screenshotted, emailed, or reopened from browser history, so the service needs a helpful return behavior.

Selection Rules

• Choose confirmation page when the transaction is finished and the user needs endpoint proof plus what happens next.
• Include a reference number only when it has a real support, tracking, payment, booking, or audit use; explain what it is for and whether users should keep it.
• State the next responsible party, expected timing, and whether the user needs to do anything else.
• Summarize submitted details when they help the user verify an appointment, payment, booking, application, or survey response after commit.
• Provide contact, tracking, amend, cancel, save, print, email receipt, feedback, or related-service links only when they support the completed transaction.
• Use success confirmation instead when the user remains in the same task and the success proof belongs near the changed object.
• Use review before submit instead when users still need Change links and final pre-commit inspection.
• Use notification banner instead when a previous-page action succeeded but the current journey continues.
• Use error state, service unavailable page, permission denied state, or error summary instead when completion did not happen.
• Avoid filling the endpoint with unrelated promotional content or multiple equal calls to action that obscure the completion message.

Required States

• Submitted state immediately after authoritative commit routes to the confirmation page.
• Completion panel state with success heading and reference or receipt details when available.
• Next-step state that names timing, responsible party, contact route, and whether any user action remains.
• Record-keeping state with save, print, email, copy reference, or downloadable receipt when users may need proof.
• Submitted-detail summary state for bookings, payments, survey responses, or applications where details matter after commit.
• Post-commit correction state that replaces pre-submit Change links with amend, cancel, track, or contact guidance.
• Bookmarked-return state that either restores the receipt or provides a helpful tracking or support path.
• Start-again state for users who need to begin another transaction without confusing it with the completed one.
• Failure handoff state where uncommitted, denied, invalid, or unavailable outcomes do not render as completion.

Interaction Contract

• The page appears only after the final action succeeds according to the authoritative system of record.
• The H1 or panel title names the finished transaction rather than saying only Success.
• Reference numbers, timestamps, submitted details, and next steps are generated from canonical committed data.
• Pre-submit Change links are removed after commit; any correction path uses explicit amend, cancel, contact, or track rules.
• Save, print, email, copy, feedback, and tracking actions preserve the completion context and keep users on or return them to the receipt when appropriate.
• Starting a new transaction clears the old flow state while leaving the completed reference accessible through tracking or history if supported.
• Returning through a bookmark does not show stale private data without authorization; if the receipt cannot be restored, the page explains how to track or contact the service.

Implementation Checklist

• Identify the authoritative commit event, receipt identifier, user-visible reference, timestamp, submitted details, and next-step owner before rendering the page.
• Write the completion heading as a finished outcome, such as Application complete, Booking complete, Payment sent, or Response submitted.
• Show the reference in a durable readable form and explain why users may need it.
• Add next-step content with concrete timing, responsible organization or system, and what the user should do if nothing happens.
• Provide a record-keeping route such as print, save PDF, email receipt, copy reference, or tracking link when the receipt is useful later.
• Remove review-page editing controls and replace them with post-submit amend, cancel, contact, or support guidance.
• Handle browser Back, reload, refresh, duplicate submit, bookmarked return, expired sessions, and unauthenticated access without creating a second transaction.
• Test mobile layout, print styles, screen reader heading order, focus after submit, long reference numbers, repeated applications, privacy-sensitive receipts, and unavailable tracking.

Common Generated-UI Mistakes

• Showing a toast or local success strip as the only proof of a completed transaction.
• Using a confirmation page before the transaction is committed.
• Leaving Change links active after final submit.
• Showing a reference number without explaining whether users need to keep it.
• Omitting what happens next or when the user should expect a response.
• Using a green completion page for permission denial, service failure, or validation recovery.
• Adding so many unrelated links and cards that the completion message no longer reads as the page purpose.
• Breaking bookmarked returns with a blank or hostile expired-session page.

Critique Questions

• What system event proves the transaction is complete?
• What reference, receipt, timestamp, or submitted details will users need later?
• What exactly happens next, who owns it, and when should the user expect it?
• Is the page still offering pre-submit editing after commit?
• How can users save, print, email, copy, track, amend, cancel, or contact support from this endpoint?
• What happens if users bookmark, refresh, go Back, submit twice, or return after their session expires?