211 lines
9.2 KiB
Markdown
211 lines
9.2 KiB
Markdown
# Example Session: UX Pipeline — /ux-design → /ux-review → /team-ui
|
||
|
||
**Context:** Solo indie dev, Pre-Production phase. The HUD and inventory screen are the first UI to design. The game has a player journey doc and GDDs for inventory and combat.
|
||
|
||
**Starting State:**
|
||
- `design/gdd/inventory-system.md` — complete
|
||
- `design/gdd/combat-system.md` — complete
|
||
- `design/player-journey.md` — complete (6-phase arc defined)
|
||
- No UX specs yet
|
||
- `design/ux/` directory does not exist
|
||
|
||
**Session Duration:** ~90 minutes across two sessions (HUD design, then inventory screen)
|
||
**Turns:** 16
|
||
**Outcome:** `design/ux/hud.md` and `design/ux/screens/inventory.md` created and reviewed; team-ui handed off for visual implementation
|
||
|
||
---
|
||
|
||
## Part 1: HUD Design with /ux-design
|
||
|
||
### Turn 1: User Starts HUD Design
|
||
|
||
**User:**
|
||
> /ux-design hud
|
||
|
||
### Turn 2: Agent Loads Context and Presents the Approach
|
||
|
||
**Agent (ux-designer, via /ux-design):**
|
||
> Starting HUD design. Loading context...
|
||
>
|
||
> - `design/player-journey.md` read — key states: Calm Exploration, Tension (threat detected), Crisis (low HP/stamina), Combat
|
||
> - `design/gdd/combat-system.md` — HUD needs: HP bar, stamina bar, active ability cooldowns (up to 3), damage numbers
|
||
> - `design/gdd/inventory-system.md` — HUD needs: quick slots (4 slots), active item indicator
|
||
>
|
||
> **HUD Philosophy question:** What is the player's primary attention focus during play?
|
||
>
|
||
> This determines how aggressive the HUD should be:
|
||
> - **Option A: Diegetic (low presence)** — HP shown only when damaged, stamina shown only when draining. World-first, HUD recedes unless urgent.
|
||
> - **Option B: Persistent minimal** — HP and stamina always visible, small and unobtrusive. Quick reference without mode-switching.
|
||
> - **Option C: Full tactical** — All info always visible (HP, stamina, cooldowns, map, inventory slots). Player always has full awareness.
|
||
>
|
||
> Given your survival game and "lone survivor" fantasy, A or B is most consistent with the genre.
|
||
|
||
**User:**
|
||
> B — I want it always there but minimal. The player is always managing resources.
|
||
|
||
### Turn 3: Agent Drafts HUD Philosophy Section
|
||
|
||
**Agent:**
|
||
> **HUD Philosophy draft:**
|
||
>
|
||
> > **Approach: Persistent Minimal**
|
||
> > The HUD is always visible but occupies minimal screen real estate. The player is a resource-managing survivor — denying HP/stamina visibility creates frustration, not tension. All critical stats are readable at a glance without interrupting exploration focus. Elements scale in visual weight when they become urgent (HP below 30% pulses, stamina at 0 flashes), then return to minimal state.
|
||
>
|
||
> May I write this to `design/ux/hud.md` as the Philosophy section?
|
||
|
||
**User:**
|
||
> Yes
|
||
|
||
**Agent creates `design/ux/hud.md` and writes Philosophy section.**
|
||
|
||
*(Turns 4–7 continue the section-by-section HUD authoring: Info Architecture, Zones, Element Specs, State Machine, Visual Budget, Platform Adaptation — each drafted, approved, and written to file.)*
|
||
|
||
---
|
||
|
||
**Final HUD structure after all sections:**
|
||
|
||
```
|
||
design/ux/hud.md
|
||
- Philosophy: Persistent Minimal
|
||
- Info Architecture: HP (top-left), Stamina (top-left below HP), Quick Slots (bottom-center),
|
||
Ability Cooldowns (bottom-right), Damage Numbers (world-space)
|
||
- Zones: 4 defined (top-left vitals, bottom-center interaction, bottom-right abilities, world-space)
|
||
- Element Specs: 6 elements with dimensions, font sizes, opacity rules
|
||
- State Machine: Calm / Tension / Crisis / Combat (4 states, transition triggers)
|
||
- Visual Budget: Max 8% screen coverage, 3 simultaneous animations
|
||
- Platform Adaptation: Controller (aim reticle added), Mobile (out of scope v1)
|
||
```
|
||
|
||
---
|
||
|
||
## Part 2: Inventory Screen with /ux-design
|
||
|
||
### Turn 8: User Starts Inventory Screen
|
||
|
||
**User:**
|
||
> /ux-design screen inventory
|
||
|
||
### Turn 9: Agent Scans GDD and Player Journey
|
||
|
||
**Agent:**
|
||
> Loading context for inventory screen...
|
||
>
|
||
> From `design/gdd/inventory-system.md`:
|
||
> - Grid inventory, 6×8 slots
|
||
> - Items have weight (affects movement) and stack size
|
||
> - Player can equip, drop, inspect, split stacks
|
||
>
|
||
> From `design/player-journey.md`:
|
||
> - Inventory opens frequently during Calm Exploration
|
||
> - Players should feel "organized and in control" when opening inventory
|
||
> - Anxiety moment: "I need to decide what to drop" — should be clear, not panicked
|
||
>
|
||
> **Player Need (from journey):** *I need to quickly assess what I'm carrying, decide what to keep or drop, and get back into the world.*
|
||
>
|
||
> **Key design question:** How do players navigate to inventory actions?
|
||
> - **Option A: Right-click context menu** — hover item → right-click → menu appears (Escape/common)
|
||
> - **Option B: Drag-based** — drag to drop zone to drop; drag to equipment slot to equip (Stardew Valley)
|
||
> - **Option C: Inspect panel** — click item → details panel appears on right with action buttons
|
||
|
||
**User:**
|
||
> B — drag-based. I want it tactile.
|
||
|
||
*(Turns 10–12 continue section-by-section for the inventory screen spec: Player Need, Layout Zones, States, Interaction Map, Data Requirements, Events Fired, Accessibility, Localization.)*
|
||
|
||
---
|
||
|
||
## Part 3: /ux-review
|
||
|
||
### Turn 13: User Runs Review
|
||
|
||
**User:**
|
||
> /ux-review design/ux/
|
||
|
||
### Turn 14: Agent Reviews Both Documents
|
||
|
||
**Agent (via /ux-review):**
|
||
> Reviewing all UX specs in `design/ux/`...
|
||
>
|
||
> ---
|
||
> **HUD Review (`hud.md`):**
|
||
>
|
||
> | Check | Status | Notes |
|
||
> |-------|--------|-------|
|
||
> | GDD alignment — all required elements present | ✅ | HP, stamina, quick slots, cooldowns all specced |
|
||
> | State machine coverage | ✅ | All 4 gameplay states covered |
|
||
> | Accessibility tier | ⚠️ | No colorblind mode specified for HP/stamina bars (red/yellow convention) |
|
||
> | Visual budget | ✅ | 8% screen coverage, within budget |
|
||
> | Platform notes | ✅ | Controller variant documented |
|
||
>
|
||
> **Inventory Screen Review (`screens/inventory.md`):**
|
||
>
|
||
> | Check | Status | Notes |
|
||
> |-------|--------|-------|
|
||
> | Player Need stated | ✅ | |
|
||
> | All GDD actions covered | ✅ | Equip, drop, inspect, split all in interaction map |
|
||
> | Drag-drop interaction fully specified | ⚠️ | Drop target behavior when inventory is full not defined — what happens? |
|
||
> | Accessibility: keyboard alternative for drag | ❌ | MISSING — drag-only with no keyboard path fails motor accessibility |
|
||
> | Localization: all strings tagged | ✅ | |
|
||
> | Data events fired | ✅ | `item_equipped`, `item_dropped`, `stack_split` all mapped |
|
||
>
|
||
> ---
|
||
> **Verdict: NEEDS REVISION**
|
||
>
|
||
> Two issues must be resolved before handoff to /team-ui:
|
||
>
|
||
> 1. **BLOCKING (Accessibility):** Inventory screen has no keyboard alternative to drag-drop. Motor accessibility requires a non-drag interaction path. Add a "press X to pick up / press X again to place" toggle, or a details panel with keyboard-accessible action buttons.
|
||
>
|
||
> 2. **ADVISORY (HUD):** HP/stamina bars use color alone to convey state. Add a secondary indicator (shape, icon, or pattern) for colorblind users. Can be resolved in visual pass.
|
||
> 3. **ADVISORY (Inventory):** Full-inventory drop behavior is unspecified. Resolve in GDD before implementation, or document as out-of-scope.
|
||
|
||
### Turn 15: User Resolves Blocking Issue
|
||
|
||
**User:**
|
||
> For keyboard: press F to pick up item at cursor, press F again on target slot to place it. Add this to the inventory spec.
|
||
|
||
**Agent:**
|
||
> Adding to Interaction Map under "Keyboard / Controller Path":
|
||
>
|
||
> > Press F (or South button) to pick up item at cursor. Item enters "held" state with visual indicator. Press F again on target slot to place. Press Escape to cancel and return item.
|
||
>
|
||
> May I write this to `design/ux/screens/inventory.md` and re-run the accessibility check?
|
||
|
||
**User:**
|
||
> Yes
|
||
|
||
**Agent writes update. Re-checks accessibility — now passes.**
|
||
|
||
---
|
||
|
||
## Part 4: Handoff to /team-ui
|
||
|
||
### Turn 16: User Kicks Off Team UI
|
||
|
||
**User:**
|
||
> /team-ui
|
||
|
||
**Agent (via /team-ui):**
|
||
> Running UX pipeline context check...
|
||
>
|
||
> - `design/ux/hud.md` — reviewed ✅
|
||
> - `design/ux/screens/inventory.md` — reviewed ✅
|
||
> - `/ux-review` verdict: NEEDS REVISION was resolved — current state: APPROVED ✅
|
||
>
|
||
> Proceeding to **Phase 2: Visual Design**
|
||
>
|
||
> Handing off to `art-director` for visual spec (color palette, typography, iconography aligned to art bible)...
|
||
>
|
||
> *(team-ui continues through visual design → layout implementation → accessibility audit → final review)*
|
||
|
||
---
|
||
|
||
## What This Example Demonstrates
|
||
|
||
- **Context-driven design**: agent reads player-journey.md to ground HUD decisions in player emotional state, not just feature lists
|
||
- **UX review is a hard gate**: `/team-ui` checks for a passing `/ux-review` before proceeding to visual design
|
||
- **Accessibility caught early**: the missing keyboard alternative was flagged by review, not discovered by a QA tester in the final week
|
||
- **Blocking vs. advisory**: the missing keyboard path was BLOCKING (stops handoff); the colorblind colors were ADVISORY (can be fixed in visual pass)
|
||
- **Section-by-section UX authoring**: same incremental pattern as `/design-system` — each section written to file before moving on
|
||
- **Separate HUD and screen files**: `design/ux/hud.md` is the whole-game HUD; per-screen specs live in `design/ux/screens/`
|
||
- **Pattern library enforced by /team-ui**: after this session, inventory drag-drop becomes a documented pattern in `design/ux/interaction-patterns.md` for all future screens to reference
|