Design a three-screen onboarding for a fitness app

## Role and objective

You are a product designer creating a three-screen onboarding flow for a fitness app. Produce a Figma-ready UI specification for people entering the app for the first time, using only the confirmed facts and clearly marked slots below. Your output must describe exactly three screens, their components, states, interactions, accessibility behaviour and design tokens in a form that can be translated into frames and components. Completion means every screen has a defined hierarchy, auto-layout behaviour, primary action, loading/empty/error treatment where applicable, keyboard path, screen-reader labels and responsive behaviour, with no invented product facts.

## Scope and given facts

In scope:
- A fitness app onboarding flow.
- Exactly three screens.
- Screen structure, components, behaviour, accessibility and responsive layout.
- Figma-oriented frame hierarchy and auto-layout descriptions.

Confirmed input:
- Product type: fitness app.
- Deliverable: three-screen onboarding design.

Use these slots where the design depends on missing information:
- App name and brand description: [FILL IN: app name and brand description]. Fill this with the supplied product name, brand attributes, logo treatment and brand colours.
- Target user profile and onboarding goal: [FILL IN: target user profile and onboarding goal]. Fill this with the intended users and the action onboarding should prepare them to take.
- Content, exercise categories and feature list: [FILL IN: approved onboarding content]. Fill this with verified product copy and available features.
- Accessibility jurisdiction: [FILL IN: ADA Title III or Section 508 applicability]. Fill this with the governing accessibility context, or mark it [VERIFY].
- Date, number, currency and address formats: [FILL IN: required US formats]. Fill these with the formats required by the product and audience; do not invent them.

Do not add a programme name, user outcome, health claim, metric, subscription detail or feature unless it is supplied or marked as a slot.

## Working rules

Treat the three screens as one progressive flow. Assign each screen one distinct onboarding job; if the goal is not supplied, use [FILL IN: onboarding goal] rather than choosing a product strategy. Keep navigation and primary actions consistent unless a supplied requirement justifies a change.

For every screen, define:
1. Frame hierarchy from page frame to sections, controls and content.
2. Auto-layout direction, alignment, spacing, padding and resizing rules in words.
3. Component states, including default, focused, pressed, disabled, loading, empty and error states wherever the component or data can produce them.
4. Keyboard order, visible focus treatment and screen-reader name, role and state.
5. Responsive behaviour at 320px width and 200% zoom, with no horizontal scrolling.
6. The primary action, its destination and its disabled condition.

If a screen is static and cannot load or contain data, state that loading, empty and error states are not applicable and explain why. If content is unknown, use a slot; do not write plausible fitness copy. If a visual treatment depends on an unconfirmed brand, use [FILL IN: brand direction] and specify what must be supplied.

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs this audience and label the answer [VERIFY] if it is not confirmed. Keep touch targets, contrast, focus order, labels and error communication explicit. State date, number, currency and address formats explicitly if any such fields appear; otherwise state that they are absent from these screens.

## Output structure

Produce the following sections in order:

1. **Screen list** — name Screen 1, Screen 2 and Screen 3, and give each a one-sentence purpose. Do not create a fourth screen or combine two screens under one number.
2. **Components per screen** — for each screen, list the frame hierarchy, component names, content slots, auto-layout direction, alignment, spacing, padding, resizing rules and responsive changes. Allocate roughly one-third of the design detail to each screen.
3. **Behaviour per state** — for each screen, document default, focused, pressed, disabled, loading, empty and error states as applicable; identify inapplicable states rather than silently omitting them. Include transitions, back behaviour and validation.
4. **Accessibility and responsive requirements** — state the keyboard sequence, screen-reader labels, focus management, contrast and zoom/viewport handling for all three screens. Include the [FILL IN: ADA Title III or Section 508 applicability] slot.
5. **Design tokens** — list colour, typography, spacing, corner radius, borders, elevation, icon treatment and motion tokens. Use [FILL IN: token value] for every unconfirmed value.
6. **Figma build notes** — describe the component and variant structure, naming convention, constraints and prototype links without claiming that a file was created.

Represent repeated properties as concise bullets or tables in prose. Do not fill proposed tables with invented values.

## Style rules

Use a hybrid style. Use concise, itemized lists for screen inventories, component properties, states, tokens and acceptance checks. Use short narrative paragraphs only to explain the flow rationale, responsive decisions and accessibility consequences. Keep the register practical and design-specific. Avoid generic fitness slogans, exaggerated wellness language, empty claims about simplicity, and placeholder marketing copy presented as final text.

## 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 contains exactly three onboarding screens for a fitness app, not a dashboard, workout plan or marketing landing page.
2. Confirm that every screen includes a frame hierarchy and verbal auto-layout rules for direction, alignment, spacing and resizing.
3. Confirm that loading, empty and error states are either specified or explicitly marked not applicable for each relevant screen.
4. Confirm that keyboard operation, focus order and screen-reader labels are stated for every interactive element.
5. Confirm that WCAG 2.2 AA, 200% zoom and the 320px viewport with no horizontal scrolling are addressed.
6. Confirm that brand, user profile, onboarding goal, product content and token values remain slots when absent from the input.
7. Check specifically that no app name, feature, health outcome, measurement, subscription detail or other fact was added beyond “fitness app” and “three-screen onboarding.”
8. Check specifically that no slot for the app name, target user profile or accessibility jurisdiction was filled arbitrarily.
9. Check that the response stays within onboarding UI design and does not drift into implementation code, user research, exercise advice or a completed Figma file.
10. Confirm that every date, number, currency or address field is either assigned an explicit supplied format or stated to be absent.
11. Confirm that the output follows the required order: screen list, components per screen, behaviour per state and design tokens, with Figma build notes included.
12. Confirm that all uncertain accessibility-jurisdiction claims are marked [VERIFY] rather than assumed.