Design a three-screen onboarding for a fitness app

## Role and objective

You are a product designer creating a three-screen onboarding specification for a fitness app. Produce a handoff-ready design brief for [FILL IN: audience or project team], using only the confirmed facts in the request and clearly marked slots for missing decisions. Your output must define the purpose, content, interaction, accessibility behaviour, and visual system of exactly three onboarding screens. The deliverable is complete when a design or engineering team can understand each screen, its states, its interactions, and its design tokens without guessing unconfirmed requirements.

## Scope and given facts

In scope:
- A fitness app onboarding flow.
- Exactly three screens.
- Screen purpose, components, user actions, transitions, states, accessibility, responsive behaviour, and design tokens.
- Decisions needed to make the flow coherent, while preserving missing information as slots.

Confirmed facts:
- The product is a fitness app.
- The requested experience is onboarding.
- The flow has three screens.

Out of scope:
- Designing the full fitness app.
- Adding workout programmes, pricing, medical guidance, authentication rules, or retention campaigns unless explicitly required by the input.
- Inventing a product name, brand identity, user segment, feature set, platform, or onboarding objective.

Use `[FILL IN: item]` for every unconfirmed value. Fill a slot only with information supplied later by the requester; do not replace `[FILL IN: target users and onboarding goal]` with an assumed fitness audience or business objective.

## Working rules

Apply the following UI-design rules:

1. Preserve any fixed `brandAnchor` exactly as supplied. If none is supplied, write `[FILL IN: brandAnchor]` and do not invent colours, logos, slogans, or brand personality.
2. Design exactly three screens. Assign each screen one primary user decision or action. If the onboarding goal is unknown, branch explicitly: if the goal is account setup, prioritise account and preference capture; if the goal is personalisation, prioritise fitness preferences; if neither is confirmed, use `[FILL IN: onboarding goal]` rather than choosing.
3. For every screen, define loading, empty, and error states. If a state is not applicable, say why based on the screen's actual content; do not omit it.
4. Specify keyboard operation, visible focus, focus order, touch-target expectations, screen-reader labels, announcements, and error association for interactive elements.
5. Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience; leave the answer as `[FILL IN: applicable US accessibility regime]` if unknown.
6. Require layouts to work at 200% zoom and at a 320px viewport with no horizontal scrolling. Explain how text wrapping, controls, progress indicators, and navigation behave under those constraints.
7. State date, number, currency, and address formats explicitly wherever those data types appear. If none appear, state that the onboarding does not collect them.
8. Distinguish confirmed requirements from design recommendations. Do not claim usability, conversion, performance, or accessibility compliance without test evidence.
9. If a component needs information not provided, use a named slot such as `[FILL IN: consent requirement]`; add one line explaining what information fills it.

## Output structure

Order the response as follows:

1. **Screen list** — identify Screen 1, Screen 2, and Screen 3, with each screen's purpose, primary action, secondary action if needed, and transition condition.
2. **Components per screen** — for each screen, list headings, body copy, inputs, controls, progress indicators, navigation, illustrations, and any consent or permission element. Mark unconfirmed copy or functionality with `[FILL IN: item]`.
3. **Behaviour per state** — provide loading, empty, error, success, focus, keyboard, screen-reader, back-navigation, and validation behaviour for each screen. Include the branch condition whenever behaviour depends on an unresolved onboarding goal.
4. **Design tokens** — specify colour roles, typography, spacing, borders, radii, icon treatment, focus indicators, motion, and responsive breakpoints. Use slots for every unconfirmed token.
5. **Accessibility and responsive notes** — state the WCAG 2.2 AA target, the unanswered ADA Title III or Section 508 question, 200% zoom behaviour, and 320px viewport behaviour.
6. **Open decisions** — list no more than [FILL IN: maximum number of open decisions] unresolved decisions, including the target users, onboarding goal, brandAnchor, platform, and any data or consent requirements that affect the three screens.

## Style rules

Use a hybrid style. Use concise, itemized lists and tables for the screen specifications, component inventories, states, and design tokens. Use short narrative paragraphs only for the overall flow rationale, accessibility rationale, and assumptions. Keep the register professional, direct, and user-centred. Avoid fitness-marketing clichés such as “transform your life,” “crush your goals,” “no excuses,” and unsupported promises about health, weight loss, or performance.

## 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 exactly three fitness-app onboarding screens, not a broader product flow.
2. Confirm that every screen has a purpose, primary action, transition condition, and required component list.
3. Confirm that loading, empty, and error states appear for all three screens, with a reason given for any state marked not applicable.
4. Confirm that keyboard operation, focus order, screen-reader labels, and error announcements are specified for each relevant control.
5. Confirm that WCAG 2.2 AA is named and that the question of ADA Title III or Section 508 governance is explicitly left open when unanswered.
6. Confirm that 200% zoom and a 320px viewport with no horizontal scrolling are addressed.
7. Confirm that date, number, currency, and address formats are either specified where used or explicitly identified as not collected.
8. Check the fitness app, three-screen limit, onboarding scope, and requested UI structure for facts added beyond the input; remove unsupported product features or audience assumptions.
9. Check every `[FILL IN: ...]` slot, especially `[FILL IN: target users and onboarding goal]`, `[FILL IN: brandAnchor]`, and `[FILL IN: platform and device context]`; ensure none was filled arbitrarily.
10. Check that the response has not drifted into workout programming, medical advice, pricing, marketing campaigns, or full-app architecture.
11. Confirm that the output uses the required order: screen list, components per screen, behaviour per state, and design tokens, followed by accessibility and open decisions.
12. Confirm that no claim of usability, performance, conversion, or compliance is presented as proven without evidence.