Design a three-step checkout flow for an online store

## Role and objective

You are a UX architect designing a three-step checkout flow for an online store. Produce a screen-and-interaction specification that a product, design and engineering team can implement, while keeping the shopper’s path understandable and recoverable. The deliverable must contain exactly three checkout steps, with the screens, components, behaviours and design tokens required by the UI modality. Completion means that a team can identify what appears in each step, what happens during loading, empty and error states, and how a shopper completes or corrects the purchase without leaving the defined three-step flow.

## Scope and given facts

In scope is the checkout flow for an online store, limited to exactly three sequential steps. Cover the shopper-facing screens, components, state behaviour, accessibility interactions, responsive constraints and formatting conventions needed to specify that flow.

Confirmed facts:
- The requested deliverable is a design for a three-step checkout flow.
- The context is an online store.

Unconfirmed values must remain slots:
- **Brand continuity:** `[FILL IN: store brand description]` — provide the exact brand wording and visual characteristics that must remain unchanged.
- **Implementation context:** `[FILL IN: checkout platform or implementation environment]` — provide the platform, framework or design tool that will receive the specification.
- **Accessibility jurisdiction:** `[FILL IN: governing accessibility audience]` — state whether ADA Title III, Section 508, both, or neither governs the intended audience.
- **US formatting requirements:** use `[FILL IN: required date, number, currency and address conventions]` if the store has conventions different from standard US presentation.

Do not invent a store name, product catalogue, payment provider, shipping policy, discount, tax rate, account requirement or legal applicability.

## Working rules

Use the confirmed request as the only factual basis. Treat the checkout as exactly three steps; do not add a preliminary cart step, an optional fourth step or a separate confirmation step. If an operation normally needs its own screen, place it within one of the three steps and label the in-step transition clearly. If the store’s business rules are unknown, mark them `[FILL IN: business rule]` and state what information would resolve them.

Apply WCAG 2.2 AA as the accessibility target. Also ask whether `[FILL IN: governing accessibility audience]` means ADA Title III or Section 508 governs this audience; name the applicable regime only when confirmed, and otherwise mark it `[VERIFY]`. Require keyboard access to every control, visible focus, logical tab order, usable focus after validation errors, and screen-reader labels that identify each field, control, status message and error. Do not rely on colour alone.

Specify loading, empty and error behaviour for every step. For each state, define the trigger, visible feedback, whether controls are disabled, how the shopper recovers and where focus moves. Empty states must explain what action is available; error states must identify the affected field or operation and provide a corrective path. If a failure is retryable, include retry; if it is not, provide an alternative or explain the blocking condition without inventing a policy.

Ensure the layout remains usable at 200% zoom and at a 320px viewport with no horizontal scrolling. State date, number, currency and address formats explicitly; use `[FILL IN: format]` where the store’s convention is unknown.

## Output structure

Order the deliverable as follows:

1. **Screen list** — list exactly three checkout steps. For each, give its purpose, entry condition, primary action and exit condition. Allocate approximately 10% of the specification to this list.
2. **Components per screen** — for each of the three steps, list fields, controls, summaries, navigation, validation messages and any persistent progress indicator. Identify required versus optional elements only when the input confirms that distinction; otherwise use `[FILL IN: requiredness rule]`. Allocate approximately 35%.
3. **Behaviour per state** — for every step, specify the default, loading, empty and error states, including keyboard behaviour, screen-reader announcements, focus placement, recovery and responsive behaviour. Include submission, back navigation and prevention of accidental duplicate submission. Allocate approximately 40%.
4. **Design tokens** — define colour roles, typography, spacing, focus treatment, control sizing, borders and responsive breakpoints. Use `[FILL IN: brand token]` for values not supplied. Allocate approximately 15%.

Include a short assumption-and-input register after the design tokens only if needed to collect unresolved slots; do not use it to add a fourth checkout step. Use concise tables or bullet lists for screens, components, states and tokens. Include no invented product, customer, payment or policy data.

## Style rules

Use a hybrid style. Use itemized tables and numbered lists for the screen list, components, state behaviours, accessibility requirements and design tokens. Use short narrative paragraphs only to explain the overall shopper progression and the rationale for a transition or recovery path. Keep the register practical and implementation-ready. Avoid checkout clichés such as “seamless experience,” “frictionless journey,” “delight your customers,” and “one-click” unless the input confirms the underlying feature.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable designs exactly three checkout steps and does not introduce a fourth step, separate cart step or unrequested confirmation screen.
2. Confirm that every step appears in the screen list and has corresponding components and state behaviour.
3. Confirm that the subject remains an online-store checkout rather than expanding into catalogue, marketing, fulfilment or general account design.
4. Confirm that loading, empty and error states are specified for all three steps, with triggers, feedback, recovery and focus handling.
5. Confirm that keyboard operation and screen-reader labels are addressed for every interactive control and validation message.
6. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is marked `[VERIFY]` unless the governing audience is supplied.
7. Confirm that 200% zoom and a 320px viewport with no horizontal scrolling are explicit requirements.
8. Confirm that date, number, currency and address formats are stated or left as `[FILL IN]` slots.
9. Check every store-specific fact, including brand, platform, payment method, tax, shipping and account rules, for addition beyond the input; replace unsupported additions with slots.
10. Check that no `[FILL IN]` slot—especially the store brand description, implementation environment or governing accessibility audience—has been filled with an arbitrary value.
11. Check that no component, state or design token claims a business capability that the input did not confirm.
12. Check that tables and lists follow the hybrid style and that the final structure contains only the requested UI specification sections.