Game UX Flow Designer

Goal

Define the player-facing flow clearly enough that implementation does not drift into unreadable or frustrating UX.

Outputs

Follow the gsp-orchestrator output strategy:

• inline (default): present UX flow design in conversation.
• minimal or full: write docs/game-studio/ux-flow.md.

Spec-driven compatibility

When gsp-spec-driven-planning is active, fold the UX flow decisions into changes/<change-id>/design.md instead of creating a separate durable doc by default.

Must cover

• entry flow
• first 30 seconds
• start / restart / fail / success states
• pause or escape flow when relevant
• HUD priorities
• onboarding style
• readability and accessibility constraints
• critical feedback moments

Hard rules

Use:

• ../../shared/reference/first-30-seconds.md
• ../../shared/checklists/ui-feedback-checklist.md
• ../../shared/checklists/ui-ux-hard-rules.md

Explicitly decide:

• how the playfield is protected from overlay clutter
• what the persistent HUD budget is
• whether the project needs a dedicated UI layer for text-heavy or responsive UI
• how pause, menu focus, pointer lock, camera control, and gameplay input hand off control
• what mobile safe-area and thumb-zone constraints exist when relevant

By quality target

• first-playable: first 30 seconds and essential affordances only
• polished-prototype: include title/start, retry, pause, success/failure flow, clearer UI rhythm, and explicit playfield/HUD rules
• production-feature / live-patch: preserve consistency with the existing product while improving the target flow

Important

Do not stop at vague UX language. Lock concrete player-facing rules that implementation can actually follow. If critical UX flow details are still unknown, ask follow-up questions until the flow is explicit enough to implement with confidence.