Design a three-screen onboarding for a fitness app

## Role and objective

You are a product designer creating a three-screen onboarding design specification for a fitness app. Produce a practical blueprint for the people who will design, build, or review the onboarding flow. Treat “three-screen onboarding” as the fixed deliverable; do not expand it into additional screens or a complete app redesign.

Your output must follow the required screen-list structure below and describe each screen’s components, states, interactions, accessibility behaviour, and design tokens. Completion is achieved only when another designer or developer can understand the intended three-screen flow without needing invented product facts.

## Scope and given facts

In scope:

- A fitness app.
- An onboarding experience.
- Exactly three screens.
- Screen content, component placement, interaction behaviour, accessibility requirements, and visual tokens.

Out of scope:

- Features after onboarding.
- Workout programming, medical advice, subscription pricing, or marketing copy unless explicitly needed to explain an onboarding control.
- Unconfirmed brand, audience, platform, business, or regulatory details.

Use these confirmed facts only: the product is a fitness app, and the requested onboarding has three screens.

Leave the following as slots rather than deciding them:

- `[FILL IN: target users and their primary onboarding goal]` — insert the intended user group and the result onboarding should achieve.
- `[FILL IN: brandAnchor and visual identity]` — insert the fixed brand description, colours, typography, and imagery direction.
- `[FILL IN: platform and supported devices]` — insert the web, iOS, Android, or other target environment.
- `[FILL IN: jurisdictional accessibility authority]` — insert whether ADA Title III or Section 508 governs the audience, or state that neither has been confirmed.

Do not fill the fitness app’s target audience, brand identity, platform, or legal context with plausible guesses.

## Working rules

Select and describe the three screens according to the onboarding goal once `[FILL IN: target users and their primary onboarding goal]` is supplied. If the goal is confirmed, make every screen move the user toward that goal. If it remains unknown, label the proposed screen purpose as provisional and avoid asserting that it is optimal.

Keep any fixed `[FILL IN: brandAnchor and visual identity]` wording unchanged wherever the brand description is referenced. If no brand description is provided, use neutral design tokens marked `[FILL IN]` rather than inventing a brand system.

For every screen, specify:

1. The user’s immediate purpose.
2. Visible components and their order.
3. Primary and secondary actions.
4. Loading, empty, success, and error states where the screen can encounter them.
5. What happens after each meaningful action.
6. Keyboard operation, focus order, focus visibility, and screen-reader labels.
7. Whether the user can go back, skip, or recover without losing entered information.

Use WCAG 2.2 AA as the accessibility target. Require layouts to remain usable at 200% zoom and at a 320px viewport with no horizontal scrolling. State date, number, currency, and address formats explicitly only if those fields appear; otherwise state that they are not applicable to the three-screen flow.

If personal data, health information, or account credentials appear, mark the relevant handling details `[VERIFY]` and leave the governing regime, retention period, and deletion path as slots. Do not imply that a fitness app’s data is medical data without confirmation.

## Output structure

Produce the specification in this order:

1. **Screen list** — list exactly three screens, each with a short purpose and its position in the flow.
2. **Components per screen** — for Screen 1, Screen 2, and Screen 3, list the layout, text areas, controls, navigation, and any input fields. Assign `[FILL IN]` to unconfirmed content.
3. **Behaviour per state** — for each screen, describe default, loading, empty, error, success, back, skip, and completion behaviour when applicable. Include keyboard and screen-reader behaviour.
4. **Design tokens** — provide colour, typography, spacing, control sizing, borders, focus indicators, and motion guidance. Mark unconfirmed values as `[FILL IN: token value]`, and identify what must be supplied to complete them.
5. **Accessibility and responsive checks** — state how the three screens meet WCAG 2.2 AA, 200% zoom, and 320px viewport requirements, without claiming compliance that has not been tested.

Use tables for the screen list and design tokens. Use numbered lists for per-screen components and state behaviour. Do not add a fourth screen, alternative flow, implementation code, or unsupported product assumptions.

## Style rules

Use a hybrid style. Present screen inventories, component specifications, states, and tokens in concise itemized lists or tables. Use short narrative paragraphs only for the overall flow rationale, accessibility decisions, and conditional branches. Keep the register direct, precise, and suitable for a cross-functional product team. Avoid fitness clichés such as “crush your goals,” “no pain, no gain,” and “transform your life” unless supplied as confirmed product copy.

## 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 is an onboarding design for a fitness app, not a workout plan, advertisement, or full product redesign.
2. Count the screens and verify that the output contains exactly three—no fewer and no additional alternatives presented as screens.
3. Check that every screen includes its purpose, components, actions, navigation, and relevant states.
4. Check that loading, empty, error, and success behaviour is covered wherever the screen can encounter that state.
5. Check that keyboard operation, focus order, focus visibility, and screen-reader labels are explicitly addressed.
6. Check that WCAG 2.2 AA, 200% zoom, and the 320px no-horizontal-scroll requirement appear in the specification.
7. Check that the fitness app’s target users, brand identity, platform, and jurisdiction were not invented; any missing item remains a named slot.
8. Check that no `[FILL IN]` slot for the target audience, brandAnchor, platform, or jurisdiction was filled arbitrarily.
9. Check that the output has not drifted into post-onboarding features, workout advice, pricing, or marketing claims.
10. Check that tables contain design proposals or confirmed values only, never fabricated metrics, compliance results, or product facts.
11. Check that the final structure contains the screen list, components per screen, behaviour per state, design tokens, and accessibility/responsive checks in that order.
12. Check that the prose follows the hybrid format: tables and lists for specifications, short narrative passages only where the style rules permit.