Skip to content
user

experience-design

Walkable design method. Outcome to independently-reviewed screens.

20 skills3 human gates45–90 min/session
Install this pack Read the reference

The contract

Use it when
A product team needs a full design thread — from outcome to independently-reviewed screens — before build begins.
You type
Map the customer journey for this feature.
You provide
The feature, user, and intended outcome, plus any existing brand or design-system constraints.
You receive
A complete, independently-reviewed design set — journey map, screen inventory, interaction specs, and accessibility-clean designs.

Where you decide

The agent pauses at these points. You choose whether to continue, redirect, or stop.

Approve the journeyDecision 1 of 3Approve the aesthetic directionDecision 2 of 3Review the experience designsDecision 3 of 3

What changes when you install this

After installing experience-design, every design task runs a fixed thread: journey-mapping to anchor user outcomes, user-flow to derive the screen inventory, a craft sequence (creative-direction → design-system → information-architecture → interaction-design) to design each screen, and an independent experience-reviewer pass that reads design artifacts cold. The quality floor — handle-all-states, WCAG 2.2 AA, reduced-motion — is non-negotiable at every step. You decide at three gates: the journey and screen list, the aesthetic direction, and the post-review pass before design feeds the build loop. experience-status orients to the thread at the start of any session.

The journey

Say this What happens
experience-status Orient — where the design thread is, what’s next
journey-mapping Map the user’s outcome: stages, emotions, pains
content-design Set surface intent — what this screen says and for whom
tone-of-voice Set the brand-level copy register — cross-surface copy personality all per-surface goals reference
copy-direction Name per-surface copy goals — voice, register, arbitration rules for a specific marketing surface
user-flow Build the screen inventory with per-screen state briefs
creative-direction Anchor the aesthetic in persona and precedent
design-system Derive the token taxonomy from the aesthetic direction
interaction-design Design states, feedback, and animation per screen
experience-reviewer Independent cold review — forked context, read-only

1. Map the customer journey

Type journey-mapping and describe the outcome you’re designing for — the user, the goal, and where the current experience breaks down.

journey-mapping

  journey  docs/design/journeys/onboarding.md

  Stage 1  Aware          finds product, expectations vague
  Stage 2  First-session  blank state, no direction, high drop-off
  Stage 3  Value          first export, relief, converts

Approve the journey and screen list? ›
  • You decide: approve the journey map before screens are derived from it — a one-sentence redirect here saves a full design cycle.
  • Output: an approved journey map with key failure modes and a derived screen list.
  • State: draft

2. Derive the screen flow

Type user-flow. The agent sequences the screens implied by the journey and builds a per-screen brief for each, including the full state matrix.

user-flow

  screens  docs/design/screen-flows/onboarding.md

  /onboarding/welcome  →  /onboarding/connect  →  /onboarding/done
  States per screen: default · loading · error · success · empty
  • Output: a screen inventory with per-screen briefs, ready for the craft sequence.
  • State: draft

3. Establish design intent

Type creative-direction to anchor the visual direction in persona, precedent, and platform conventions. Type design-system to derive the token taxonomy from it.

creative-direction

  direction  docs/design/aesthetic/onboarding.md

  Goals   Calm confidence, platform-native trust
  Ref     Linear's focused workspace; Notion's quiet hierarchy

Approve the aesthetic direction? ›
  • You decide: approve the direction before screens are designed — a vague direction (“clean and modern”) is a rejection.
  • Output: a named aesthetic direction with a derived token taxonomy.
  • State: draft

4. Design each screen

Type information-architecture (or a genre-direct skill for dashboards, marketing, docs, or marketplace surfaces), then interaction-design per screen.

interaction-design [/onboarding/welcome]

  screen  docs/design/screens/welcome.md
  States: default · loading · error · success · empty ✓
  Motion: entrance · field-focus · submit-feedback ✓
  • Output: a designed screen set with all states handled and quality floor met.
  • State: draft

5. Review independently

Type experience-reviewer. It reads your design artifacts cold — no authoring context — and returns findings across handle-all-states, WCAG 2.2 AA, aesthetic fit, and cross-screen coherence.

experience-reviewer

  Blocker  Welcome screen: empty state not designed
  Concern  Connect screen: error text has no recovery action
  Nit      "Get started" → "Connect your first account"
  • You decide: act on Blockers before design feeds the build loop.
  • Output: a review-clean design set ready for build.
  • State: confirmed-write

Human gates

For each gate, everything you need to make a confident decision.

  • Approve the journey

    Trigger
    After journey-mapping and user-flow complete
    Time
    10–15 minutes
    What to check, good, bad, consequence

    What to check

    • Does the journey capture the outcome the user is trying to achieve — not just the tasks they perform in the current product?
    • Does the journey provide a clear basis for the derived screen list, rather than the existing implementation or a wish list?
    • Are the key failure modes named — the moments the current journey breaks down, and why?
    • Is every screen in the list implied by the journey? (Remove screens that aren't.)

    What good looks like

    A journey map that names the outcome, the failure modes, and a screen list with a clear derivation — each screen traceable to a moment in the journey.

    What bad looks like

    A screen list that maps to the current implementation screen-by-screen. This means the agent documented the status quo instead of designing for the outcome.

    Consequence of skipping

    The screen list is the contract for all design work that follows. A screen list derived from the wrong model means the design thread designs the wrong product — faithfully.

  • Approve the aesthetic direction

    Trigger
    After creative-direction and optionally design-system complete
    Time
    5–10 minutes
    What to check, good, bad, consequence

    What to check

    • Does the aesthetic direction name a specific visual character — not just 'clean and modern'?
    • Are the contrast ratios in the token set verified at WCAG 2.2 AA minimum?
    • Is the palette constrained to a small number of semantic roles — does adding a new color require a decision?
    • Are the tokens derived from the aesthetic direction, not borrowed from a generic design system?

    What good looks like

    A named aesthetic reference with a token set that derives directly from it, passes the contrast floor, and could be handed to a developer without ambiguity.

    What bad looks like

    An aesthetic direction that could apply to any product, or a token set that introduces hardcoded values outside the semantic token system.

    Consequence of skipping

    The aesthetic direction is the constraint every subsequent screen must satisfy. Approving a vague direction means screens drift with no shared reference to hold them together — and the experience-reviewer will flag every screen for the same missing constraint.

  • Review the experience designs

    Trigger
    After the experience-reviewer subagent returns findings on the completed screen designs
    Time
    15–25 minutes
    What to check, good, bad, consequence

    What to check

    • Did the reviewer flag any handle-all-states violations? (Missing empty, loading, error, or success states are the most common finding.)
    • Are all WCAG 2.2 AA requirements met — color contrast, label associations, focus order?
    • Is reduced-motion handled — are transitions guarded for users who have requested reduced animation?
    • Are the screens consistent with the approved aesthetic direction — or did any screen introduce its own visual language?

    What good looks like

    A design set that the independent reviewer marks clean — all states handled, accessibility floor met, aesthetic direction consistently applied across every screen.

    What bad looks like

    Screens that look good in the happy-path state but have no designed empty state, loading state, or error recovery. Or screens that pass visually but fail the accessibility audit.

    Consequence of skipping

    The experience-reviewer is the design analogue of adversarial-reviewer in the build loop. Its findings are the last check before design intent feeds the build. An unreviewed design is a set of unverified assumptions about how the product behaves when things go wrong.

Typical session

Agent turns
8–15
Human gates
3
Wall-clock time
45–90 min

Install

agentbundle install --pack experience-design --scope user

Skills in this pack

  • journey-mapping1 gate

    Maps the current and desired customer journey to derive the key touchpoints and failure modes a product must address.

  • content-design

    Produces a content brief for a surface — what it should say, for whom, in what form, and to what objective — before any wireframe or screen flow starts.

  • tone-of-voice

    Names the brand-level copy register — the cross-surface voice and copy personality that all per-surface copy decisions reference.

  • copy-direction

    Names the copy direction for a specific marketing or acquisition surface — ranked copy goals grounded in stable referents, plus arbitration rules for that surface.

  • user-flow1 gate

    Derives the screen inventory and flow from the customer journey — what screens exist, what state each handles, what the transitions are.

  • service-blueprint

    Maps front-stage screen flows to the back-stage processes and human actors that support them — the service blueprint.

  • process-mapping

    Documents the internal processes that run behind user-facing screens — the APQC/BPMN model of what people do.

  • design-principles

    Converts journey-map insights into 3–5 named design principles — decision rules that resolve disputes and persist across sprints, each grounded in a journey moment.

  • creative-direction1 gate

    Establishes the visual direction for a surface — named emotional and brand goals grounded in stable referents — as the aesthetic reference all subsequent screens must satisfy.

  • design-system

    Derives the design token set from the creative direction — the primitive and semantic tokens that carry the design into code.

  • information-architecture

    Designs the layout zones and information hierarchy for a screen, given its per-screen brief.

  • analytical-design

    Produces a structural specification for an analytical surface — dashboard IA, widget hierarchy, and role-based view architecture — from business questions and domain model.

  • conversion-design

    Produces a structural specification for a marketing surface — above-fold contract, scroll story, and social-proof architecture — from content brief and design principles.

  • documentation-design

    Produces a structural specification for a documentation surface — content hierarchy, navigation strategy, and TTFV architecture — from Diátaxis content typing and reading goal.

  • informational-design

    Produces a structural specification for an informational surface — typographic hierarchy, reading-pattern calibration, and editorial grid — from editorial structure and reading goal.

  • marketplace-design

    Produces a structural specification for a marketplace surface — listing card IA, filter and facet architecture, and transaction bridge — from buyer journey and listing object model.

  • workspace-design

    Produces a structural specification for a workspace surface — context-persistence architecture, attention zone layout, and interrupt design — from session arc and collaboration model.

  • interaction-design

    Designs the interactive behaviors for a screen — states, transitions, feedback patterns — against WCAG 2.2 AA.

  • design-review

    Reviews an existing screen design against the quality floor — handle-all-states, accessibility, reduced-motion — before the independent review.

  • experience-status

    Orients to the current design thread at a glance — reads design artifacts from the configured output directory and surfaces what exists, what's missing, and which skill to run next.

Technical reference & next steps