Design a three-step checkout flow for an online store

## Role and objective

<instructions>
You are a senior product designer designing a checkout experience for an online store. Produce a specification for exactly three checkout steps, written for the product, UX, and engineering teams responsible for implementing it. Define the purpose, content, interactions, validation, and transitions for each step without inventing store-specific facts.

The output is complete when it describes three distinct steps, their required states, the movement between them, and the information needed to implement and evaluate the flow. Before presenting the final flow, show concise reasoning that explains how the three steps divide the checkout work and why each required field or interaction belongs where it is placed.
</instructions>

## Scope and given facts

<context>
The confirmed request is: “Design a three-step checkout flow for an online store.”

In scope:
- The sequence and purpose of exactly three checkout steps.
- Information architecture, fields, controls, validation, navigation, order review, and payment completion.
- Loading, empty, error, and recovery behaviour where relevant.
- Accessibility and responsive interaction requirements.

Out of scope unless explicitly provided:
- Visual brand styling, copywriting, implementation code, analytics results, pricing, inventory, shipping rates, tax calculations, or legal conclusions.
- A specific store category, customer segment, payment provider, platform, or business rule.

Use these unresolved slots only when the design depends on them:
- [FILL IN: product and store context] — supply the store type, products, and target customers.
- [FILL IN: checkout requirements] — supply payment methods, shipping options, account policy, and applicable business rules.
- [FILL IN: accessibility and jurisdiction requirements] — supply the applicable audience, standards, or jurisdiction.

Do not arbitrarily fill the slots for this request: in particular, do not assume a product category, payment method, shipping promise, tax rule, account requirement, or return policy.
</context>

## Working rules

<instructions>
Use exactly three steps. Assign each step a single dominant customer task, and place a field in a step only when it is necessary for that task or for a later decision. Prefer progressive disclosure: do not expose optional information before it is needed.

Use this decision logic:
1. If the store requires shipping, include address and delivery selection in the step responsible for fulfillment. If the purchase is digital or pickup-only, mark shipping as conditional rather than assuming an address is required.
2. If guest checkout is permitted, make it available without forcing account creation. If account policy is unknown, label the choice [FILL IN: account policy].
3. If multiple payment methods exist, design a method-selection state and describe the fields shown for the selected method. If the payment method is unknown, do not name a provider.
4. If a field is required for order completion, state its validation rule and error recovery. If it is optional, state why it is collected and allow the customer to skip it.
5. Keep order review separate from editable data entry: customers must be able to inspect the final items, quantities, totals, fulfillment choice, and payment summary before submission, subject to [FILL IN: store requirements].

For every step, specify:
- Entry condition and completion condition.
- Required and optional information.
- Field-level validation, inline error placement, and recovery.
- Back, continue, edit, and save behaviour.
- Loading, unavailable, and failed-request states.
- Keyboard order, visible focus, labels, and screen-reader announcements.
- Mobile behaviour at a 320px viewport and at 200% zoom without horizontal scrolling.

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience; do not assume either applies. State explicit US date, number, currency, and address formats only after they are confirmed; otherwise use [FILL IN: format rules].
</instructions>

## Output structure

<output_format>
Present the response in this order:

1. **Reasoning before conclusion** — briefly explain the three-task decomposition, the placement of customer information, fulfillment, payment, and review, and every conditional decision caused by an unresolved slot.
2. **Flow overview** — provide a compact table with exactly three rows. Include step number, step name, customer goal, primary action, and completion condition.
3. **Step specifications** — provide one subsection for each of the three steps. For each, include:
   - Purpose and entry condition.
   - Required fields and optional fields.
   - Validation and error recovery.
   - Navigation and data persistence.
   - Loading, empty, and failure states.
   - Keyboard, screen-reader, responsive, and zoom behaviour.
4. **Cross-flow behaviour** — describe the progress indicator, cart persistence, session interruption, back navigation, duplicate-submission prevention, and order-confirmation transition. Mark unknown business rules with [FILL IN: item].
5. **Design tokens** — list only tokens needed to make the flow implementable: colour roles, typography roles, spacing scale, control sizing, focus treatment, and breakpoint assumptions. Leave unconfirmed values as [FILL IN: token].
6. **Conclusion** — state how the three-step flow satisfies the completion test and list the unresolved inputs required before implementation.

Render the overview and any comparison of step states as tables. Use prose only for rationale and conditional behaviour. Do not add a fourth checkout step or combine multiple numbered steps under one label.
</output_format>

## Style rules

Use a hybrid style: use tables and numbered lists for the flow overview, field inventories, states, and acceptance checks; use short narrative paragraphs for reasoning, conditional branches, and the conclusion. Keep the register professional and implementation-ready. Avoid checkout clichés such as “seamless experience,” “frictionless journey,” “one-click magic,” and “delightful checkout” unless the phrase is explicitly defined by measurable behaviour.

## 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 describes an online-store checkout rather than a general purchase journey.
2. Count the checkout steps and verify that the flow contains exactly three, with no hidden fourth step.
3. Check that each step has one dominant customer task, an entry condition, and a completion condition.
4. Verify that shipping is conditional on the unresolved store context and is not assumed for digital or pickup-only purchases.
5. Verify that payment methods, account policy, shipping options, tax, currency, and address rules are not invented; unresolved items remain marked with the correct slots.
6. Check that required fields have validation, error placement, recovery behaviour, and a reason for being collected.
7. Check that loading, empty, unavailable, failed-request, and duplicate-submission states are covered where they apply to the three-step flow.
8. Check keyboard operation, screen-reader labels and announcements, 320px behaviour, 200% zoom, and WCAG 2.2 AA coverage.
9. Check that the reasoning appears before the conclusion and explains conditional design decisions.
10. Check that facts added beyond “Design a three-step checkout flow for an online store” are either explicitly marked as assumptions, confirmed inputs, or [FILL IN] slots.
11. Check that no slot for product context, checkout requirements, accessibility or jurisdiction requirements, payment, shipping, or formatting has been filled arbitrarily.
12. Check that the response stays within the requested checkout-flow scope and does not drift into implementation code, marketing copy, analytics claims, or legal conclusions.
13. Confirm that the output uses the required XML regions: <instructions>, <context>, and <output_format>, with instructions appearing before context.
14. Confirm that the hybrid style boundary is followed: structured checkout details are itemized, while rationale and conclusion are narrative.
15. Count this checklist: fifteen checks are present. Do not deliver until all fifteen pass.