Back to Details

ux-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Overview

概述

Validates UX design documents before they enter the implementation pipeline. Acts as the quality gate between UX Design and Visual Design/Implementation in the 
/team-ui
pipeline.
Run this skill:
  • After completing a UX spec with 
    /ux-design
  • Before handing off to 
    ui-programmer
    or 
    art-director
  • Before the Pre-Production to Production gate check (which requires key screens to have reviewed UX specs)
  • After major revisions to a UX spec
Verdict levels:
  • APPROVED — spec is complete, consistent, and implementation-ready
  • NEEDS REVISION — specific gaps found; fix before handoff but not a full redesign
  • MAJOR REVISION NEEDED — fundamental issues with scope, player need, or completeness; needs significant rework
在UX设计文档进入实施流程前对其进行验证。 在
/team-ui
流程中，充当UX设计与视觉设计/实施之间的质量关卡。
运行此skill：
  • 使用
    /ux-design
    完成UX规范后
  • 交付给
    ui-programmer
    或
    art-director
    之前
  • 进入预生产到生产的关卡检查之前（该检查要求关键界面需经过评审的UX规范）
  • 对UX规范进行重大修订之后
结论等级：
  • APPROVED — 规范完整、一致，已具备实施条件
  • NEEDS REVISION — 发现具体漏洞；交付前需修复，但无需重新设计
  • MAJOR REVISION NEEDED — 在范围、玩家需求或完整性方面存在根本性问题；需要大幅返工

Phase 1: Parse Arguments

阶段1：解析参数

  • Specific file path (e.g., 
    /ux-review design/ux/inventory.md
    ): validate that one document
  • all
    : find all files in 
    design/ux/
    and validate each
  • hud
    : validate 
    design/ux/hud.md
    specifically
  • patterns
    : validate 
    design/ux/interaction-patterns.md
    specifically
  • No argument: ask the user which spec to validate
For 
all
, output a summary table first (file | verdict | primary issue) then full detail for each.
  • 指定文件路径（例如：
    /ux-review design/ux/inventory.md
    ）：验证单个文档
  • all
    ：查找
    design/ux/
    下的所有文件并逐一验证
  • hud
    ：专门验证
    design/ux/hud.md
  • patterns
    ：专门验证
    design/ux/interaction-patterns.md
  • 无参数：询问用户要验证哪份规范
如果是
all
，先输出汇总表格（文件 | 结论 | 主要问题），再展示每份文件的详细信息。

Phase 2: Load Cross-Reference Context

阶段2：加载交叉引用上下文

Before validating any spec, load:
  1. Input & Platform config: Read 
    .claude/docs/technical-preferences.md
    and extract 
    ## Input & Platform
    . This is the authoritative source for which input methods the game supports — use it to drive the Input Method Coverage checks in Phase 3A, not the spec's own header. If unconfigured, fall back to the spec header.
  2. The accessibility tier committed to in 
    design/accessibility-requirements.md
    (if it exists)
  3. The interaction pattern library at 
    design/ux/interaction-patterns.md
    (if it exists)
  4. The GDDs referenced in the spec's header (read their UI Requirements sections)
  5. The player journey map at 
    design/player-journey.md
    (if it exists) for context-arrival validation
在验证任何规范之前，加载以下内容：
  1. 输入与平台配置：读取
    .claude/docs/technical-preferences.md
    并提取
    ## Input & Platform
    部分。这是游戏支持的输入方式的权威来源——用于驱动阶段3A中的输入方式覆盖检查，而非规范自身的头部信息。如果未配置，则回退到规范头部信息。
  2. design/accessibility-requirements.md
    中约定的无障碍等级（如果存在）
  3. design/ux/interaction-patterns.md
    中的交互模式库（如果存在）
  4. 规范头部引用的GDD（读取其UI要求章节）
  5. design/player-journey.md
    中的玩家旅程图（如果存在），用于验证场景到达上下文

Phase 3A: UX Spec Validation Checklist

阶段3A：UX规范验证检查表

Run all checks against a 
ux-spec.md
-based document.
针对基于
ux-spec.md
的文档运行所有检查。

Completeness (required sections)

完整性（必填章节）

  • Document header present with Status, Author, Platform Target
  • Purpose & Player Need — has a player-perspective need statement (not developer-perspective)
  • Player Context on Arrival — describes player's state and prior activity
  • Navigation Position — shows where screen sits in hierarchy
  • Entry & Exit Points — all entry sources and exit destinations documented
  • Layout Specification — zones defined, component inventory table present
  • States & Variants — at minimum: loading, empty/populated, and error states documented
  • Interaction Map — covers all target input methods (check platform target in header)
  • Data Requirements — every displayed data element has a source system and owner
  • Events Fired — every player action has a corresponding event or null explanation
  • Transitions & Animations — at least enter/exit transitions specified
  • Accessibility Requirements — screen-level requirements present
  • Localization Considerations — max character counts for text elements
  • Acceptance Criteria — at least 5 specific testable criteria
  • 文档头部存在状态、作者、目标平台信息
  • 目的与玩家需求——包含从玩家视角出发的需求说明（而非开发者视角）
  • 到达时的玩家上下文——描述玩家的状态和之前的操作
  • 导航位置——说明界面在层级结构中的位置
  • 进入与退出点——记录所有进入来源和退出目的地
  • 布局规范——定义区域，包含组件清单表格
  • 状态与变体——至少记录加载、空/已填充和错误状态
  • 交互图——覆盖所有目标输入方式（检查头部的目标平台）
  • 数据需求——每个显示的数据元素都有来源系统和负责人
  • 触发事件——每个玩家操作都有对应的事件或无事件说明
  • 过渡与动画——至少指定进入/退出过渡效果
  • 无障碍需求——包含界面级别的需求
  • 本地化考量——文本元素的最大字符数
  • 验收标准——至少包含5个具体可测试的标准

Quality Checks

质量检查

Player Need Clarity
  • Purpose is written from player perspective, not system/developer perspective
  • Player goal on arrival is unambiguous ("The player arrives wanting to ___")
  • The player context on arrival is specific (not just "they opened the inventory")
Completeness of States
  • Error state is documented (not just happy path)
  • Empty state is documented (no data scenario)
  • Loading state is documented if the screen fetches async data
  • Any state with a timer or auto-dismiss is documented with duration
Input Method Coverage
  • If platform includes PC: keyboard-only navigation is fully specified
  • If platform includes console/gamepad: d-pad navigation and face button mapping documented
  • No interaction requires mouse-like precision on gamepad
  • Focus order is defined (Tab order for keyboard, d-pad order for gamepad)
Data Architecture
  • No data element has "UI" listed as the owner (UI must not own game state)
  • Update frequency is specified for all real-time data (not just "realtime" — what triggers update?)
  • Null handling is specified for all data elements (what shows when data is unavailable?)
Accessibility
  • Accessibility tier from 
    accessibility-requirements.md
    is matched or exceeded
  • If Basic tier: no color-only information indicators
  • If Standard tier+: focus order documented, text contrast ratios specified
  • If Comprehensive tier+: screen reader announcements for key state changes
  • Colorblind check: any color-coded elements have non-color alternatives
GDD Alignment
  • Every GDD UI Requirement referenced in the header is addressed in this spec
  • No UI element displays or modifies game state without a corresponding GDD requirement
  • No GDD UI Requirement is missing from this spec (cross-check the referenced GDD sections)
Pattern Library Consistency
  • All interactive components reference the pattern library (or note they are new patterns)
  • No pattern behavior is re-specified from scratch if it already exists in the pattern library
  • Any new patterns invented in this spec are flagged for addition to the pattern library
Localization
  • Character limit warnings present for all text-heavy elements
  • Any layout-critical text has been flagged for 40% expansion accommodation
Acceptance Criteria Quality
  • Criteria are specific enough for a QA tester who hasn't seen the design docs
  • Performance criterion present (screen opens within Xms)
  • Resolution criterion present
  • No criterion requires reading another document to evaluate
玩家需求清晰度
  • 目的从玩家视角撰写，而非系统/开发者视角
  • 玩家到达时的目标明确（“玩家到达时想要___”）
  • 玩家到达时的上下文具体（不只是“他们打开了背包”）
状态完整性
  • 记录错误状态（不只是正常流程）
  • 记录空状态（无数据场景）
  • 如果界面获取异步数据，记录加载状态
  • 任何带计时器或自动关闭的状态都记录了时长
输入方式覆盖
  • 如果平台包含PC：完整指定纯键盘导航
  • 如果平台包含主机/手柄：记录方向键导航和按键映射
  • 没有交互需要手柄具备类似鼠标的精度
  • 定义了焦点顺序（键盘的Tab顺序，手柄的方向键顺序）
数据架构
  • 没有数据元素将“UI”列为负责人（UI不得拥有游戏状态）
  • 所有实时数据都指定了更新频率（不只是“实时”——要说明触发更新的条件）
  • 所有数据元素都指定了空值处理方式（数据不可用时显示什么？）
无障碍性
  • 达到或超过
    accessibility-requirements.md
    中的无障碍等级
  • 如果是基础等级：没有仅通过颜色传递信息的指示器
  • 如果是标准及以上等级：记录焦点顺序，指定文本对比度
  • 如果是全面等级：关键状态变化有屏幕阅读器播报
  • 色盲检查：任何颜色编码的元素都有非颜色替代方案
与GDD的一致性
  • 头部引用的每个GDD UI要求都在本规范中得到体现
  • 没有UI元素在没有对应GDD要求的情况下显示或修改游戏状态
  • 本规范没有遗漏任何GDD UI要求（交叉检查引用的GDD章节）
模式库一致性
  • 所有交互组件都引用了模式库（或注明是新模式）
  • 如果模式库中已存在对应模式，不会从头重新定义其行为
  • 本规范中发明的任何新模式都会标记为需添加到模式库
本地化
  • 所有文本密集型元素都有字符限制提示
  • 任何对布局至关重要的文本都标记为需预留40%的扩展空间
验收标准质量
  • 标准足够具体，供未看过设计文档的QA测试人员使用
  • 包含性能标准（界面在X毫秒内打开）
  • 包含分辨率标准
  • 没有标准需要参考其他文档才能评估

Phase 3B: HUD Validation Checklist

阶段3B：HUD验证检查表

Run all checks against a 
hud-design.md
-based document.
针对基于
hud-design.md
的文档运行所有检查。

Completeness

完整性

  • HUD Philosophy defined
  • Information Architecture table covers ALL systems with UI Requirements in GDDs
  • Layout Zones defined with safe zone margins for all target platforms
  • Every HUD element has a full specification (zone, visibility trigger, data source, priority)
  • HUD States by Gameplay Context covers at minimum: exploration, combat, dialogue/cutscene, paused
  • Visual Budget defined (max simultaneous elements, max screen %)
  • Platform Adaptation covers all target platforms
  • Tuning Knobs present for player-adjustable elements
  • 定义了HUD设计理念
  • 信息架构表格覆盖GDD中所有带有UI要求的系统
  • 定义了布局区域，并包含所有目标平台的安全区边距
  • 每个HUD元素都有完整规范（区域、可见性触发条件、数据源、优先级）
  • 按游戏场景划分的HUD状态至少包含：探索、战斗、对话/过场动画、暂停
  • 定义了视觉预算（最大同时显示元素数量、最大屏幕占比）
  • 覆盖所有目标平台的适配方案
  • 包含玩家可调整元素的调节选项

Quality Checks

质量检查

  • No HUD element covers the center play area without a visibility rule to hide it
  • Every information item that exists in any GDD is either in the HUD or explicitly categorized as "hidden/demand"
  • All color-coded HUD elements have colorblind variants
  • HUD elements in the Feedback & Notification section have queue/priority behavior defined
  • Visual Budget compliance: total simultaneous elements is within budget
  • 没有HUD元素在没有隐藏规则的情况下覆盖中央游戏区域
  • 任何GDD中存在的信息项要么在HUD中，要么明确归类为“隐藏/按需显示”
  • 所有颜色编码的HUD元素都有色盲变体
  • 反馈与通知区域的HUD元素定义了队列/优先级行为
  • 符合视觉预算：同时显示的元素总数在预算范围内

GDD Alignment

与GDD的一致性

  • All systems in 
    design/gdd/systems-index.md
    with UI category have representation in HUD (or justified absence)
  • design/gdd/systems-index.md
    中所有属于UI类别的系统都在HUD中有体现（或说明未体现的理由）

Phase 3C: Pattern Library Validation Checklist

阶段3C：模式库验证检查表

  • Pattern catalog index is current (matches actual patterns in document)
  • All standard control patterns are specified: button variants, toggle, slider, dropdown, list, grid, modal, dialog, toast, tooltip, progress bar, input field, tab bar, scroll
  • All game-specific patterns needed by current UX specs are present
  • Each pattern has: When to Use, When NOT to Use, full state specification, accessibility spec, implementation notes
  • Animation Standards table present
  • Sound Standards table present
  • No conflicting behaviors between patterns (e.g., "Back" behavior consistent across all navigation patterns)
  • 模式目录索引是最新的（与文档中的实际模式匹配）
  • 所有标准控件模式都已指定：按钮变体、切换、滑块、下拉菜单、列表、网格、模态框、对话框、提示框、工具提示、进度条、输入框、标签栏、滚动
  • 当前UX规范所需的所有游戏特定模式都已存在
  • 每个模式都包含：适用场景、不适用场景、完整状态规范、无障碍规范、实施说明
  • 存在动画标准表格
  • 存在音效标准表格
  • 模式之间没有行为冲突（例如，所有导航模式中的“返回”行为一致）

Phase 4: Output the Verdict

阶段4：输出结论

markdown
undefined
markdown
undefined

UX Review: [Document Name]

UX评审：[文档名称]

Date: [date] Reviewer: ux-review skill Document: [file path] Platform Target: [from header] Accessibility Tier: [from header or accessibility-requirements.md]
日期：[日期] 评审者：ux-review skill 文档：[文件路径] 目标平台：[来自头部] 无障碍等级：[来自头部或accessibility-requirements.md]

Completeness: [X/Y sections present]

完整性：[X/Y个章节已存在]

  • Purpose & Player Need
  • States & Variants — MISSING: error state not documented
  • 目的与玩家需求
  • 状态与变体 — 缺失：未记录错误状态

Quality Issues: [N found]

质量问题：[发现N个]

  1. [Issue title] [BLOCKING / ADVISORY]
    • What's wrong: [specific description]
    • Where: [section name]
    • Fix: [specific action to take]
  1. [问题标题] [阻塞 / 建议]
    • 问题描述：[具体说明]
    • 位置：[章节名称]
    • 修复方案：[具体操作]

GDD Alignment: [ALIGNED / GAPS FOUND]

与GDD的一致性：[一致 / 存在差距]

  • GDD [name] UI Requirements — [X/Y requirements covered]
  • Missing: [list any uncovered GDD requirements]
  • GDD [名称] UI要求 — [X/Y个要求已覆盖]
  • 缺失：[列出未覆盖的GDD要求]

Accessibility: [COMPLIANT / GAPS / NON-COMPLIANT]

无障碍性：[合规 / 存在差距 / 不合规]

  • Target tier: [tier]
  • [list specific accessibility findings]
  • 目标等级：[等级]
  • [列出具体的无障碍检查结果]

Pattern Library: [CONSISTENT / INCONSISTENCIES FOUND]

模式库：[一致 / 存在不一致]

  • [findings]
  • [检查结果]

Verdict: APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED

结论：APPROVED / NEEDS REVISION / MAJOR REVISION NEEDED

Blocking issues: [N] — must be resolved before implementation Advisory issues: [N] — recommended but not blocking
[For APPROVED]: This spec is ready for handoff to 
/team-ui
Phase 2 (Visual Design).
[For NEEDS REVISION]: Address the [N] blocking issues above, then re-run 
/ux-review
.
[For MAJOR REVISION NEEDED]: The spec has fundamental gaps in [areas]. Recommend returning to 
/ux-design
to rework [sections].

---
阻塞问题：[N个] — 实施前必须解决 建议问题：[N个] — 建议修复但不阻塞
[如果是APPROVED]：此规范已准备好交付给
/team-ui
阶段2 （视觉设计）。
[如果是NEEDS REVISION]：解决上述[N个]阻塞问题后，重新运行 
/ux-review
。
[如果是MAJOR REVISION NEEDED]：该规范在[领域]存在根本性漏洞。 建议回到
/ux-design
重新设计[章节]。

---

Phase 5: Collaborative Protocol

阶段5：协作协议

This skill is READ-ONLY — it never edits or writes files. It reports findings only.
After delivering the verdict:
  • For APPROVED: suggest running 
    /team-ui
    to begin implementation coordination
  • For NEEDS REVISION: offer to help fix specific gaps ("Would you like me to help draft the missing error state?") — but do not auto-fix; wait for user instruction
  • For MAJOR REVISION NEEDED: suggest returning to 
    /ux-design
    with the specific sections to rework
Never block the user from proceeding — the verdict is advisory. Document risks, present findings, let the user decide whether to proceed despite concerns. A user who chooses to proceed with a NEEDS REVISION spec takes on the documented risk.
此skill为只读——从不编辑或写入文件，仅报告检查结果。
给出结论后：
  • 对于APPROVED：建议运行
    /team-ui
    开始实施协调
  • 对于NEEDS REVISION：主动提出帮助修复具体漏洞（“是否需要我帮忙撰写缺失的错误状态？”）——但不要自动修复，等待用户指令
  • 对于MAJOR REVISION NEEDED：建议回到
    /ux-design
    重新设计指定章节
永远不要阻止用户推进——结论仅为建议。记录风险，展示检查结果，由用户决定是否忽略问题继续推进。选择带着NEEDS REVISION规范推进的用户需承担已记录的风险。