Design first-use flows and meaningful empty states

Guide users to their first real success with a minimal path, distinct empty/error states and dismissible contextual help. A compact direction to help the next screen feel deliberate, specific, and easy to remix.

Design first-use flows and empty states for a Web product so newcomers achieve one real valuable result. Deliver flow and UI-content specifications; do not replace the real task with a feature tour or write code by default.

INPUT
Required: [product/users: actual capabilities, audience, experience and motivation]
Required: [first success: user action, visible result and criterion for success]
Required: [current flow: entry, screens, actions and known obstacles; optional screenshots/code]
Optional: [real capabilities/constraints: examples/templates, import, permissions, network, cross-device use, required setup]
Optional: [states/voice: states to design, current copy, brand language and devices]
Optional: [deliverable: design specification; or explicitly requested minimal implementation in supplied code]

METHOD
1. Confirm users, real capabilities and the visible first-success result. Ask up to three blocking questions and wait; mark other unknowns [to supply]. Without screenshots/code, claim no inspection of real pages. Without drop-off data, label obstacles as hypotheses. Invent no imports, templates, help links or product features.
2. Map the shortest task path from entry to first success, one goal per step. Favor real functionality and contextual help; remove preliminary explanations that do not serve the task. Make optional guidance clearly skippable. Explain required permission/security/business setup rather than pretending it can be skipped. Use samples only where the product actually supports them, distinguishing sample from user data.
3. Distinguish applicable states: first-use emptiness, intentionally cleared content, no search results, no permission, loading and loading failure. Never disguise errors or access restrictions as no content. For each applicable state, write a title, short explanation, one primary action, a secondary recovery action only when necessary and the resulting outcome. Do not force illustrations, tutorials or multiple CTAs. Clearing filters preserves unrelated state; retries preserve inputs; access requests require a real supported flow.
4. Specify when contextual hints appear, how to dismiss/skip/replay them and completion status. Do not repeat completed onboarding for returning users; make replay discoverable. Define persisted state and account/device scope without claiming localStorage alone provides cross-device or secure account isolation. Cover keyboard access, visible focus, screen-reader names, overlay focus return, loading feedback and reduced motion. Do not obscure the main task or force a long tour.
5. Walk through existing flows for completion, skipping, returning, retrying failures, no results and no permission. Give verifiable expectations and retain unperformed checks as unverified. Without user research, invent no success rates, time improvements or conversion guarantees. Only provide implementation when explicitly requested with sufficient code; reuse components and business interfaces.

DELIVER IN ORDER
A. First-value definition/capability list: real feature / user action / visible success / known constraint or assumption.
B. Shortest-path table: step / screen or location / goal / action / feedback / next step / skippability and reason.
C. State-content table: type / actual trigger / title / explanation / primary action / recovery action / result; mark inapplicable states rather than inventing them.
D. Hint/return rules: display, dismissal, replay, completion, persistence scope and accessible interaction; minimal code/locations separately if requested.
E. Verification plan/evidence: scenario / action / expected / actual / unverified reason. Suggest completion rate, time to first value and obstacles as metrics to collect, without invented improvement targets or baselines.

BOUNDARIES
First-success flow and associated states only. No full navigation redesign, complete form validation or marketing page. Specifications do not establish implemented onboarding, storage, analytics or user testing; promise no unsupported capabilities.

Independent site adaptation of Paul Bakaus / Impeccable, onboard (Apache-2.0). Retains first value, contextual teaching and state classification; adds standalone delivery, actual-capability, required-step, recovery and evidence boundaries. Excludes command engine and tour-library installation: https://github.com/pbakaus/impeccable/blob/d631a8827f99414d2b6daba4ef08b7f8701751d7/skill/reference/onboard.md .

invented product features or links, forced long tours, skipped mandatory setup, errors disguised as emptiness, repeated completed hints, fake user data, localStorage claimed as cross-device account isolation, fabricated conversion or test results