80 lines
4.3 KiB
Markdown
80 lines
4.3 KiB
Markdown
# Agent Test Spec: ux-designer
|
|
|
|
## Agent Summary
|
|
Domain: User experience flows, interaction design, information architecture, input handling design, and onboarding UX.
|
|
Does NOT own: visual art style (art-director), UI implementation code (ui-programmer).
|
|
Model tier: Sonnet (default).
|
|
No gate IDs assigned.
|
|
|
|
---
|
|
|
|
## Static Assertions (Structural)
|
|
|
|
- [ ] `description:` field is present and domain-specific (references UX flows / interaction design / information architecture)
|
|
- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep
|
|
- [ ] Model tier is Sonnet (default for specialists)
|
|
- [ ] Agent definition does not claim authority over visual art direction or UI implementation code
|
|
|
|
---
|
|
|
|
## Test Cases
|
|
|
|
### Case 1: In-domain request — appropriate output
|
|
**Input:** "Design the inventory management flow for a survival game."
|
|
**Expected behavior:**
|
|
- Produces a user flow diagram (states and transitions) for the inventory: open, browse, select item, sub-actions (equip/drop/combine), close
|
|
- Defines all interaction states (default, hover, selected, empty-slot, locked-slot)
|
|
- Specifies input mappings for each action (keyboard, gamepad if applicable)
|
|
- Notes cognitive load considerations (e.g., maximum items visible without scrolling)
|
|
- Does NOT produce visual design (colors, icons) or implementation code
|
|
|
|
### Case 2: Out-of-domain request — redirects correctly
|
|
**Input:** "Implement the inventory screen in GDScript with drag-and-drop support."
|
|
**Expected behavior:**
|
|
- Does NOT produce implementation code
|
|
- Explicitly states that UI code implementation belongs to `ui-programmer`
|
|
- Redirects the request to `ui-programmer`
|
|
- Notes that the UX flow spec should be provided to ui-programmer as the implementation reference
|
|
|
|
### Case 3: Flow depth conflict — simplification
|
|
**Input:** "The lead designer says the current 5-step crafting flow is too deep; maximum 3 steps allowed."
|
|
**Expected behavior:**
|
|
- Produces a revised 3-step flow that collapses the original 5-step sequence
|
|
- Shows clearly what was merged or removed and why each collapse is safe from a usability standpoint
|
|
- Does NOT simply remove steps without addressing the user's goal at each removed step
|
|
- Flags if the 3-step constraint makes any required use case impossible and proposes an alternative
|
|
|
|
### Case 4: Accessibility conflict
|
|
**Input:** "The onboarding flow uses a timed prompt (auto-advances after 3 seconds) to keep pace, but this conflicts with accessibility requirements for user-controlled timing."
|
|
**Expected behavior:**
|
|
- Identifies the conflict with WCAG 2.1 2.2.1 (Timing Adjustable)
|
|
- Does NOT override the accessibility requirement to preserve pace
|
|
- Coordinates with `accessibility-specialist` to agree on a compliant solution
|
|
- Proposes alternatives: pause-on-hover, skip button, settings option to disable auto-advance
|
|
|
|
### Case 5: Context pass — player mental model research
|
|
**Input:** Playtest research provided in context: "Players consistently expected the 'Crafting' option to be inside the Inventory screen, not in a separate top-level menu." Request: "Redesign the navigation IA for crafting."
|
|
**Expected behavior:**
|
|
- References the specific player expectation from the research (crafting expected inside inventory)
|
|
- Restructures the information architecture to place crafting as a tab or panel within the inventory screen
|
|
- Does NOT produce a design that contradicts the stated player mental model without explicit justification
|
|
- Notes the research source in the rationale for the design decision
|
|
|
|
---
|
|
|
|
## Protocol Compliance
|
|
|
|
- [ ] Stays within declared domain (UX flows, interaction design, IA, onboarding)
|
|
- [ ] Redirects code implementation to ui-programmer, visual style to art-director
|
|
- [ ] Returns structured findings (state diagrams, flow steps, input mappings) not freeform opinions
|
|
- [ ] Coordinates with accessibility-specialist when flows have timing or cognitive load constraints
|
|
- [ ] Designs flows based on provided user research, not assumed behavior
|
|
- [ ] Documents rationale for flow decisions against user goals
|
|
|
|
---
|
|
|
|
## Coverage Notes
|
|
- Inventory flow (Case 1) should be written to `design/ux/` as a spec for ui-programmer to implement against
|
|
- Mental model case (Case 5) verifies the agent applies research evidence, not intuition
|
|
- Accessibility coordination (Case 4) confirms the agent does not override accessibility requirements for UX aesthetics
|