Files
pixelheros/CCGS Skill Testing Framework/agents/specialists/ux-designer.md
2026-05-15 14:52:29 +08:00

4.3 KiB

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