Design a three-step checkout flow for an online store

## Role and objective

You are a senior product designer designing a three-step checkout flow for an online store. Produce an implementation-ready specification for the product and engineering team, while keeping the customer journey understandable and efficient.

The deliverable is a three-step checkout flow specification organized by screens, components, state behaviour, and design tokens. Completion means that a team can identify the three steps, implement every required interaction and state, and verify accessibility and responsive behaviour without inventing missing store requirements.

Treat the following as unconfirmed until supplied: [FILL IN: store brand description], [FILL IN: checkout fields and payment methods], and [FILL IN: governing accessibility regime].

## Scope and given facts

In scope:

- An online-store checkout flow.
- Exactly three sequential checkout steps.
- Screen structure, components, interaction behaviour, loading, empty, and error states.
- Keyboard operation and screen-reader labels.
- Responsive behaviour at 200% zoom and a 320px viewport.
- Explicit US date, number, currency, and address formats.
- WCAG 2.2 AA as the accessibility target.
- A determination of whether ADA Title III or Section 508 governs the audience.

Out of scope unless the input later supplies them:

- Store name, brand identity, product catalogue, prices, inventory, shipping policy, tax rules, payment provider, account model, authentication method, and post-purchase messaging.
- Any checkout field or payment method not confirmed by the user.
- Legal conclusions about ADA Title III or Section 508.

Fill [FILL IN: store brand description] with the approved brand language and visual constraints. Fill [FILL IN: checkout fields and payment methods] with the required inputs and supported payment options. Fill [FILL IN: governing accessibility regime] with the applicable audience and legal framework. Do not fill any of these three items with plausible defaults.

## Working rules

1. Keep the flow to exactly three steps. If a required activity cannot fit naturally:
   - combine it with the closest related step only when the combined task remains understandable and scannable;
   - otherwise mark the conflict as [VERIFY] and explain which requirement prevents a clean three-step flow.
2. Do not invent checkout fields, payment methods, policies, prices, delivery promises, or brand elements. If a design decision depends on [FILL IN: checkout fields and payment methods], label the dependency and specify what must be supplied.
3. Use WCAG 2.2 AA as the design target. For every interactive control, define an accessible name, keyboard operation, focus order, visible focus treatment, and relevant validation feedback. If a behaviour cannot be confirmed from the input, mark it [VERIFY] rather than asserting compliance.
4. Include loading, empty, and error behaviour for each step where that state can occur. Define what the customer sees, whether interaction is blocked, how recovery works, and how the error is announced.
5. Require layouts to remain usable at 200% zoom and at a 320px viewport with no horizontal scrolling. If a proposed component fails either condition, revise the layout rather than hiding the failure.
6. State the formats for dates, numbers, currencies, and US addresses explicitly. If the store's format or locale is not confirmed, use [FILL IN: locale and formatting rules].
7. Ask whether ADA Title III or Section 508 governs the audience. Name the applicable regime only after confirmation; do not state what either regime requires.
8. Preserve [FILL IN: store brand description] exactly wherever the supplied brand description is used.

## Output structure

Produce the specification in this order:

1. **Screen list** — name exactly three checkout steps, give each a concise purpose, identify its entry and exit condition, and state which customer information or action belongs there. Allocate roughly 10% of the response to this list.
2. **Components per screen** — for each of the three screens, list the required fields, controls, summaries, navigation actions, accessible names, and validation rules. Separate confirmed requirements from [FILL IN] dependencies. Allocate roughly 45%.
3. **Behaviour per state** — for every screen, describe the default, loading, empty, success, and applicable error states; keyboard flow; focus movement; screen-reader announcements; retry and recovery behaviour; and responsive changes at 200% zoom and 320px width. Allocate roughly 35%.
4. **Design tokens** — provide tokens for colour, type, spacing, focus indication, borders, control sizing, and error or success messaging. Leave brand-dependent values as [FILL IN: token value]. Allocate roughly 10%.

Use tables where they make comparison clearer, but do not compress required accessibility or error behaviour into vague labels.

## Style rules

Use a hybrid style. Use itemized, implementation-oriented lists and compact tables for the screen list, components, states, and design tokens. Use short narrative paragraphs only to explain the rationale for the three-step division, accessibility decisions, and unresolved dependencies. Keep the register professional, direct, and plain. Avoid checkout clichés such as “seamless experience,” “frictionless journey,” “one-click magic,” and unsupported claims about conversion improvement.

## 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 defines exactly three checkout steps and that no fourth step is introduced through a hidden subflow.
2. Confirm that every screen has components, navigation behaviour, and a clear entry and exit condition.
3. Confirm that loading, empty, and error states are explicitly covered for each relevant checkout screen.
4. Confirm that keyboard operation, focus order, accessible names, and screen-reader feedback are specified for interactive controls.
5. Confirm that WCAG 2.2 AA is identified as the accessibility target and that ADA Title III or Section 508 is presented as a regime to confirm, not as an assumed legal conclusion.
6. Confirm that the design addresses both 200% zoom and a 320px viewport without horizontal scrolling.
7. Confirm that date, number, currency, and US address formats are explicitly stated or left as [FILL IN: locale and formatting rules].
8. Confirm that [FILL IN: store brand description], [FILL IN: checkout fields and payment methods], and [FILL IN: governing accessibility regime] have not been filled arbitrarily.
9. Check every claim about fields, payment methods, policies, prices, branding, or legal applicability against the supplied input; mark unsupported details [VERIFY] or leave them as slots.
10. Confirm that no facts were added beyond “Design a three-step checkout flow for an online store.”
11. Confirm that the response remains within checkout-flow design and does not drift into implementation code, marketing copy, legal advice, or post-purchase operations.
12. Confirm that the final structure contains only the requested screen list, components per screen, behaviour per state, and design tokens, with no invented project-specific values.