Design a three-step checkout flow for an online store

## Role and objective

You are a product designer specifying a three-step checkout flow for an online store. Produce a handoff-ready UX specification for the product, design, and engineering teams who will build and review the flow. The deliverable must define the three screens, their components, behavior in normal and exceptional states, accessibility requirements, responsive rules, and shared design tokens. Completion means a reviewer can identify what the shopper sees, does, and receives at every step without needing to invent missing interaction rules.

## Scope and given facts

In scope is a checkout flow with exactly three steps for an online store:

- Step 1: [FILL IN: step-one purpose — the confirmed information collected first]
- Step 2: [FILL IN: step-two purpose — the confirmed information collected second]
- Step 3: [FILL IN: step-three purpose — the confirmed information reviewed or submitted third]

The request does not provide the store's brand system, product type, payment methods, fulfillment model, device priority, shopper account model, supported currencies, or governing accessibility regime. Do not guess these facts. Fill `[FILL IN: brandAnchor]` with the actual colour values, type family, and corner radius supplied by the store; do not replace them with fashionable defaults. Fill the product and checkout context with the real purchase, account, and payment conditions. If a value is genuinely absent, keep its named slot and explain what information belongs there.

Out of scope are post-purchase order management, warehouse operations, customer-support procedures, marketing copy, and implementation code unless a technical detail is necessary to define observable interface behavior.

## Working rules

Judge every screen by four criteria: task completion, error prevention, information clarity, and accessibility. For each interaction, state the trigger, the visible response, the data affected, and the recovery path. Do not describe a button as “easy” or “intuitive”; specify its label, position, enabled condition, focus behavior, and resulting state.

Keep the three-step sequence fixed while allowing the contents of each step to vary only according to the confirmed checkout context. If guest checkout is confirmed, show it without requiring account creation. If an account is required, state where authentication occurs and what happens after failure. If both are supported, make the branch explicit rather than blending the paths.

Use the same token names, validation order, progress indicator, primary-action placement, and error-message pattern across all three steps. A field may be optional only when the supplied business rules confirm that it is optional. Never infer tax, shipping, payment, inventory, or address requirements.

Describe behavior through cause and effect: a loading state appears because a server request is pending; an error message appears because a specific validation or service failure occurred. Distinguish client validation, server rejection, timeout, and unavailable service, and give each an actionable recovery path.

Design for the actual reading and operating conditions: a shopper may use a narrow phone viewport, keyboard navigation, zoom, touch input, or a screen reader. Use observable layout and interaction statements rather than adjectives.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience, naming the regime without asserting its legal applicability. Require keyboard operation, visible focus, logical focus order, programmatic labels, announced status changes, and error association.

Use US date, number, currency, and address formats only if the target market is confirmed as US; otherwise leave the market as a slot. Treat payment and personal-data handling as unconfirmed unless supplied. Do not claim conversion improvements or reduced abandonment without evidence.

## Output structure

Use these sections in order:

1. **Checkout overview** — state the three-step journey, shopper goal, fixed assumptions, and completion condition. Keep this concise.
2. **Screen list** — provide a table with step number, screen purpose, entry condition, primary action, secondary action, exit condition, and unresolved fact.
3. **Components per screen** — for each step, list the visible components, their content, states, validation, and interaction behavior. Give the most detail to the step containing payment or final submission because it carries the highest completion risk.
4. **Behavior per state** — cover default, loading, empty, validation error, server error, timeout, unavailable service, back navigation, refresh, and successful completion. Explain what persists and what the shopper can do next.
5. **Design tokens** — begin with a token table on the first screen. Include colour, type family, type scale, spacing unit, spacing values, corner radius, focus treatment, and control heights. Use `[FILL IN: ...]` for store-owned values. For spacing and type scale, use a recommendation tied to the checkout viewport and usage context when no value is supplied; later screens cite token names only.
6. **Responsive and accessibility behavior** — specify behavior at 320px width and 200% zoom, with no horizontal scrolling. Include keyboard sequence, focus return, screen-reader labels, live-region announcements, error summaries, and touch-target behavior.
7. **Open decisions and handoff** — gather remaining slots once, explain what each contains, and identify the owner who must confirm it.

Use tables for the screen list and token table; use numbered lists for component and state rules; use short narrative paragraphs only where a design decision needs its rationale. Do not include implementation code or unsupported business facts.

## Style rules

Use a hybrid style. Tables and numbered lists carry screen specifications, states, tokens, and acceptance conditions; short narrative paragraphs explain the reason behind major flow decisions. Write in a direct, calm product-design register. Avoid clichés such as “seamless experience,” “frictionless checkout,” “delightful journey,” “best-in-class,” and “intuitive design.” Replace them with visible interaction details, conditions, and recovery behavior.

## 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 output defines exactly three checkout steps and does not quietly add account creation, confirmation, or post-purchase screens as extra steps.
2. Confirm that each screen has a purpose, primary action, entry condition, exit condition, and recovery path.
3. Confirm that loading, empty, validation-error, server-error, timeout, unavailable-service, and success states appear where they can actually occur in this checkout.
4. Confirm that keyboard operation, visible focus, screen-reader labels, focus movement, error association, 320px width, and 200% zoom are explicit rather than implied.
5. Confirm that the first screen contains the complete token-table rows and that later screens refer to token names instead of redefining values.
6. Confirm that any `[FILL IN: ...]` slot names a real missing fact from this checkout request and has not been filled with an invented brand value, payment rule, date, currency, or legal assumption.
7. Confirm that no unsupported conversion claim, performance figure, compliance conclusion, product detail, or payment method has been added beyond the supplied material.
8. Confirm that the specification stays within checkout-flow design and does not drift into marketing, code, warehouse operations, or post-purchase management.
9. Confirm that each error message identifies the failed condition and gives the shopper a concrete next action.
10. Fix every failed check before delivery; show only the corrected three-step checkout specification, not this audit or its results.

## Render direction

This is a UI specification, so separate the material the user reads from any implementation-ready content.

**Content for the design handoff**

Three-step checkout flow, online-store purchase, clear progress indicator, one primary action per screen, persistent order context, responsive layout, keyboard navigation, screen-reader labels, loading state, empty state, validation error state, server error state, timeout recovery, visible focus, token-based spacing and typography, 320px viewport support, 200% zoom support, no horizontal scroll.

**What the reader needs to know**

Explain each screen's purpose and behavior in prose and lists. Keep all concrete values in the screen and token tables. Do not use tool-specific syntax or name a design engine.

## Exclusions

Unconfirmed payment methods, invented brand colours, invented product details, unsupported legal conclusions, hidden mandatory fields, horizontal scrolling, unlabeled controls, inaccessible error states, conversion claims, marketing slogans, post-purchase workflows, implementation code.

## Continuity procedure

The fixed points across all three screens are the step order, progress indicator, token names, primary-action position, focus treatment, and order-summary pattern. If a brand anchor is supplied, repeat its wording verbatim wherever the brand is described. If the work later expands to multiple checkout variants, record the first screen's settled spacing, type scale, layout, and summary treatment, then reuse those values. Where the design system supports shared tokens or references, reuse the first screen's token definitions rather than relying on wording alone; text by itself will not guarantee visual identity.

## Parameters and handoff

- Steps: 3
- Accessibility target: WCAG 2.2 AA
- Responsive minimum: 320px viewport width; 200% zoom; no horizontal scroll
- Brand anchor: `[FILL IN: brandAnchor — confirmed colours, type family, and corner radius]`
- Checkout context: `[FILL IN: product and checkout context — product, account model, fulfillment, and payment conditions]`
- Governing accessibility regime: `[FILL IN: ADA Title III or Section 508 applicability — identify the applicable regime or state that neither has been confirmed]`
- Spacing unit: `[RECOMMENDED: 4px base unit — supports compact form spacing while allowing 8px and 16px group increments in a checkout layout; change if the store uses another system]`
- Type scale: `[RECOMMENDED: 1.25 modular scale — creates clear hierarchy for labels, totals, and actions on narrow checkout screens; change if the store has a confirmed scale]`

Remaining fill-ins:

1. `[FILL IN: brandAnchor]` — enter the store's actual colours, type family, and corner radius.
2. `[FILL IN: product and checkout context]` — enter the purchase, account, fulfillment, and payment facts.
3. `[FILL IN: governing accessibility regime]` — identify the applicable legal or organisational regime.

Choose one next step: (1) provide these checkout details and I will revise the specification, (2) finish it using the recommended spacing and type values while leaving store-owned facts open, or (3) change the checkout structure first.