Build a First-Use Path That Answers What Happens Next

Step 1: extract the promise from every pre-start surface

Collect the sales page, plan table, checkout, receipt, welcome message, terms, support description, and any partner recommendation. Create rows for delivered item, audience, prerequisites, timing, effort, outcome boundary, access, price, renewal, cancellation, and help. Assign an operational owner and source date to each promise.

Resolve contradictions before mapping the customer journey. If one page promises instant access while identity review can take two days, neither onboarding copy nor a disclaimer should hide the conflict. Correct the source, define the real range, and identify customers affected by the old version.

Evidence: GOV.UK Design System; UK Government Digital Service; UK Financial Conduct Authority

Steps 2 and 3: define completion and issue a usable record

Step 2 states what event has completed: order accepted, account created, application submitted, payment pending, or service active. Step 3 provides the reference, product or service identity, amount or plan where appropriate, date, necessary record, and immediate next action. Choose delivery channels that respect privacy and shared-device risk.

Write success, pending, duplicate, and failure states separately. Avoid a generic thank-you page that cannot tell a customer whether another click is needed. GOV.UK's confirmation pattern is a service-design reference for this structure, not a universal rule for commercial transactions.

Evidence: GOV.UK Design System; W3C Web Accessibility Initiative

Steps 4 and 5: order prerequisites and expose dependencies

Step 4 lists required account, device, browser, document, permission, data, equipment, skill, payment, language, and time. Step 5 turns them into a dependency sequence with a smallest useful first action. Mark optional paths and let customers defer nonessential personalization rather than blocking access.

For each task, state why it is needed, who acts, estimated range, data requested, save behavior, accessible alternative, and recovery. Do not ask for information merely because it may help future marketing. A prerequisite material to fit belongs in the pre-purchase content too.

Evidence: GOV.UK Design System; UK Government Digital Service

Steps 6 and 7: design honest progress and time messages

Step 6 defines evidence-backed states, timestamps, owners, and transitions. Step 7 attaches ranges and exception messages to states influenced by manual review or third parties. Show whether the customer or service owns the next action, what notification will arrive, and when help becomes appropriate.

A progress bar should map to meaningful completed work, not animation. Do not promise exact timing from an uncontrolled dependency. When timing changes, update the range, preserve completed work, and explain available choices rather than forcing repeated submission.

Evidence: GOV.UK Design System; UK Government Digital Service

Step 8: place help and recovery at the point of failure

Map password loss, missing email, inaccessible media, unsupported device, failed payment, rejected document, interrupted upload, mistaken plan, and delayed review. Provide a predictable help mechanism, channel, availability, reference to include, response expectation, and escalation for urgent or high-impact cases.

W3C material on consistent help supports predictable repeated placement from an accessibility perspective. It does not prove conformance. Test keyboard, screen reader, zoom, captions, language, and cognitive load with appropriate methods, and retain a non-digital alternative when the service and obligations require one.

Evidence: UK Government Digital Service; W3C Web Accessibility Initiative

Steps 9 and 10: preview the whole path and close the learning loop

Step 9 walks each promise through confirmation, tasks, status, help, and recovery using authorized test data or a non-transactional prototype. Document what was actually observed; do not claim a live purchase, refund, or support result unless it occurred. Test interruption and return, small screens, assistive modes, and each major exception.

Step 10 logs repeated confusion, abandonment, duplicate action, contact reason, early cancellation, and expectation language, then routes the issue to the promise or process owner. Recheck by 2027-02-10 and after offer, workflow, support, accessibility, or terms changes. The FCA source remains a scoped UK financial-services example rather than general law.

• Promise-to-step trace complete.
• Exception owner named.
• Observed and predicted behavior separated.
• Feedback trigger has a correction deadline.

Evidence: UK Government Digital Service; UK Financial Conduct Authority; W3C Web Accessibility Initiative