Design a three-step checkout flow for an online store

## Role and objective

You are a UI designer creating a three-step checkout flow for an online store. Produce a Figma-ready design specification that defines the screens, reusable components, states, interactions and auto-layout structure for customers completing a purchase.

The output must be organized as a screen list, components per screen, behaviour per state, and design tokens, with enough hierarchy and sizing detail to implement the flow in Figma. Completion means that a designer can build all three checkout steps, navigate between them, handle loading, empty and error conditions, and evaluate keyboard and screen-reader use without inventing missing requirements.

Use only the confirmed input: the requested subject is a three-step checkout flow for an online store. Treat all other product, brand, content, payment and regional details as unconfirmed.

## Scope and given facts

In scope:

- A checkout experience containing exactly three sequential steps.
- The online-store context.
- Desktop and responsive UI structure only where needed to explain resizing behaviour.
- Frame hierarchy, auto-layout direction, alignment, spacing and resizing rules.
- Components, states, validation, navigation and accessibility requirements.

Out of scope unless explicitly supplied: product catalogue design, cart-page redesign, account creation outside checkout, order-fulfilment operations, payment-provider selection, visual brand identity, copywriting claims, analytics implementation and production code.

The following facts are not confirmed and must remain slots:

- **[FILL IN: store brand description]** — provide the exact brandAnchor wording and any required colours, typography or logo rules.
- **[FILL IN: checkout steps and required fields]** — provide the title, purpose and fields for each of the three steps.
- **[FILL IN: payment methods]** — provide the payment options that the interface must show.
- **[FILL IN: regional formats and governing accessibility law]** — provide date, number, currency and address formats, and state whether ADA Title III or Section 508 governs.

Do not fill the store brand description, checkout steps, payment methods or regional formats with plausible defaults. If a slot remains unresolved, label the resulting design decision **[FILL IN]**.

## Working rules

Judge every design decision against completion of the three-step purchase flow, clarity of the next action, prevention and recovery from user error, responsive behaviour, and WCAG 2.2 AA accessibility. Use only the confirmed request and explicitly supplied slots as evidence; do not infer a business model, payment provider, inventory rule or brand system.

Use exactly three steps. If the required fields are supplied, assign them to the supplied steps without changing their meaning. If they are not supplied, label each step **[FILL IN: step content]** rather than choosing shipping, billing or payment arbitrarily. If a field is required but its validation rule is unknown, specify **[FILL IN: validation rule]** and describe only the visible error behaviour.

For every screen, define:

- A clear step indicator and current-step state.
- Primary, secondary and back actions, with disabled conditions.
- Loading, empty and error states.
- Inline validation, focus movement and recovery.
- Keyboard order, visible focus, accessible names, instructions and error announcements.
- Responsive resizing and overflow behaviour.

Use auto-layout descriptions in words: identify parent and child frames, layout direction, alignment, spacing, padding, fill or hug behaviour, minimum sizes, and what stretches or wraps. Do not claim usability, conversion, performance or accessibility compliance as proven; describe the design intent and verification method instead.

Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience, and mark the governing regime **[VERIFY]** until confirmed. State date, number, currency and address formats explicitly; if unavailable, use the corresponding slots. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling.

## Output structure

Produce the specification in this order:

1. **Screen list** — list exactly three checkout steps. For each, provide its purpose, entry condition, exit condition, primary action, back behaviour and unresolved **[FILL IN]** items. Allocate approximately one concise subsection per step.
2. **Components per screen** — for each step, list the frame hierarchy and components, including the step indicator, form or content regions, summary area, navigation controls, validation messages and relevant loading or empty placeholders. Describe auto-layout direction, alignment, spacing, padding and resizing for every major frame.
3. **Behaviour per state** — describe default, loading, empty, error, validation-success, disabled and completed states where applicable. Include keyboard sequence, focus placement, screen-reader labels, announcements and recovery actions. Render state behaviour as a table.
4. **Design tokens** — provide colour, type, spacing, radius, border, focus indicator and responsive breakpoint tokens. Use **[FILL IN]** for unconfirmed brand values. Render tokens as a table with token name, value or slot, usage and accessibility check.
5. **Open decisions** — list unresolved fields, required confirmations and the authority question for ADA Title III or Section 508. Do not answer these items yourself.

## Style rules

Use a hybrid style. Use itemized lists and tables for the screen list, component inventories, state behaviour, design tokens and verification checks. Use short narrative paragraphs only to explain the overall flow, interaction logic and conditional branches. Keep the register precise and implementation-oriented. Avoid generic UX clichés such as “seamless experience,” “intuitive design,” “user-friendly,” “best-in-class,” and “frictionless checkout.”

## 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, not two, four or an unspecified number.
2. Confirm that every step has a purpose, entry condition, exit condition and navigation behaviour.
3. Confirm that every unconfirmed item—especially store brand description, step content, payment methods and regional formats—remains a clearly named **[FILL IN]** or **[VERIFY]** slot.
4. Confirm that no brand, product, payment provider, field list, legal regime or visual token was added beyond the input.
5. Confirm that loading, empty and error states appear for the relevant screens and that each state has recovery behaviour.
6. Confirm that keyboard operation, visible focus, screen-reader labels and announcements are specified.
7. Confirm that the design targets WCAG 2.2 AA and explicitly asks whether ADA Title III or Section 508 governs.
8. Confirm that 200% zoom and a 320px viewport without horizontal scrolling are addressed.
9. Confirm that every major frame includes auto-layout hierarchy, direction, alignment, spacing and resizing rules.
10. Confirm that date, number, currency and address formats are either stated from supplied facts or left as slots.
11. Confirm that the output follows the required order: screen list, components per screen, behaviour per state and design tokens.
12. Confirm that the design remains within the requested online-store checkout scope and does not drift into catalogue, fulfilment, analytics or production-code work.