Stage 1 — Map the customer journey
You describe the feature, user, and outcome. The agent runs journey-mapping to produce the customer journey map — the current state (what happens today), the desired state (what should happen after this feature), and the key moments where the current journey breaks down.
With the journey in hand, the agent can run content-design to produce a content brief — what the surface should say, for whom, and to what objective — and tone-of-voice to name the copy direction. These run before the screen flow is derived, so the surface’s content intent and register are set as constraints before screens are sequenced. The content brief and copy direction don’t require a separate gate; review them informally when you read the journey map.
You: Read the journey map and approve it at the G-journey gate. This is the most important gate in the experience thread — the screen list flows directly from it. If the map describes what the current product does rather than what the user is trying to achieve, redirect before the screen flow is derived. A one-sentence correction here saves a full design cycle.
Stage 2 — Derive the screen flow
With the journey approved, the agent runs user-flow to derive the screen inventory: what screens exist, what state each one handles (empty, loading, populated, error), and what the transitions between them are. Each screen gets a per-screen brief: the user’s goal, the information they need, the states to handle.
You: Check that the screen list feels right — that it doesn’t add screens not implied by the journey, and doesn’t miss screens the journey requires. If the agent adds a screen that looks useful but isn’t derived from the journey, remove it here.
Stage 3 — Establish design intent
Before designing any screen, the agent runs design-principles to convert journey-map insights into 3–5 named decision rules — the principles that resolve design disputes and hold screens to a shared standard across the sprint. The principles don’t require a separate gate; review them alongside the aesthetic direction below. The agent then runs creative-direction to establish the visual character of the surface — named emotional and brand goals grounded in stable referents — as a named aesthetic reference. design-system derives the design token set from that direction.
You: Approve the aesthetic direction at the G-aesthetic gate. An aesthetic direction that says “clean and professional” is not an aesthetic direction — it needs to name a specific visual character with enough specificity to say whether a given design decision is consistent or not. If the tokens introduce hardcoded values outside the semantic token system, reject them.
Stage 4 — Design each screen
The agent runs a structural IA skill on each screen before interaction-design. For general screens it uses information-architecture. When a screen has a specific surface genre, a genre-specific Direct skill produces a more targeted specification: analytical-design for dashboards and reporting views; conversion-design for marketing and acquisition surfaces; documentation-design for docs sites and help centres; informational-design for article and editorial pages; marketplace-design for catalogue and listing surfaces; workspace-design for productivity and agentic tool UIs. Once the IA is set, interaction-design designs the states, transitions, and feedback patterns, and design-review applies the quality floor as a self-check before the independent review.
You: Watch each screen take shape. If a screen is missing a state — no empty state for a list that could be empty, no loading state for an async action — name it. The agent will miss states not explicitly mentioned in the brief; that’s what the experience-reviewer catches, but catching it here is cheaper.
Stage 5 — Independent review
The agent runs the experience-reviewer subagent in a forked context — a reviewer that has not seen the authoring session. The reviewer returns findings on the full screen set: handle-all-states violations, accessibility failures, aesthetic inconsistencies.
You: Read the review findings at the G-experience-review gate. Handle-all-states violations are the most common finding — a screen that works for the happy path but has no designed error state. WCAG findings affect all users. Apply Blockers before the design intent feeds the build loop; they represent the floor the spec says all screens must clear.