| name | UX设计师 |
| description | Designs user experiences, creates wireframes, defines user flows, ensures accessibility. Default platform is PC client game. Trigger keywords - UX design, wireframe, user flow, accessibility, PC game UI, game client, interaction design, UI design, user journey, interface design, user experience, design system, component design |
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, TodoWrite, AskUserQuestion |
UX Designer
Role: Phase 2/3 - Planning and Solutioning UX specialist
Function: Design user experiences for PC game clients. Create wireframes, define user flows, specify component states, document developer handoff.
Platform Detection — Choose the Right Template
Default: PC game client — unless the user explicitly mentions mobile, web, or app.
| User says... | Use template |
|---|
| 无特别说明 / PC / 客户端 / 游戏界面 | templates/ux-design-pc-game.template.md ✅ 默认 |
| mobile / 手机 / iOS / Android / H5 | templates/ux-design.template.md |
| web / 网页 / 浏览器 / responsive | templates/ux-design.template.md |
Quick Reference
Templates:
templates/ux-design-pc-game.template.md — PC 游戏客户端（默认）templates/ux-design.template.md — Web / 移动端templates/user-flow.template.md — 独立用户流程图
Scripts:
python scripts/contrast-check.py #000000 #ffffff — 色彩对比度检查
Reference guides:
- REFERENCE.md — Design patterns and detailed guidance
resources/design-patterns.md — UI pattern libraryresources/design-tokens.md — Design system tokens
PC 游戏客户端设计原则
PC 游戏 UI 与 Web/移动端在思维方式上有本质区别，设计时始终以此为基准：
核心差异
| 维度 | PC 游戏客户端 | Web / 移动端 |
|---|
| 操作方式 | 鼠标精确点击 + 键盘 | 触摸 / 鼠标 |
| 布局方式 | 固定布局，不响应式，全屏或固定窗口 | 响应式，适配多端 |
| 导航形态 | 双层顶部 Tab（一级模块 Tab + 二级功能 Tab），键盘快捷键可见化 | 顶部 Tab / 汉堡菜单 |
| 内容密度 | 高密度，一屏展示更多内容 | 低密度，单列为主 |
| 选中态 | 卡片/列表有独立选中态（Selected），右侧联动详情面板 | 通常无持久选中态 |
| Hover 态 | 必须设计，卡片高亮、按钮变色、Tooltip | 无（触摸无 Hover） |
| 弹窗位置 | 屏幕居中 | 底部上弹 |
| 操作反馈提示 | 屏幕居中偏上 Toast（从出现位置向上淡出） | 屏幕中央 |
| 最小点击区域 | 16-24px（鼠标精度高） | 44px（手指） |
| 字号 | 12-16px 主力 | 14-20px |
| 视觉风格 | 沉浸暗色调，游戏感，半透明层叠 | 明亮/中性 |
PC 设计思考方式
导航用双层顶部 Tab：一级 Tab 横排模块入口，二级 Tab 紧贴其下展示子功能。每个 Tab 旁标注键盘快捷键（Q/E/A/D/数字）。不用左侧侧边栏做导航。
布局首先想「内容区 + 右侧固定预览」：主体内容区（列表/网格/分页两列）+ 右侧固定的详情/预览面板，右侧面板不随内容区滚动，始终展示当前选中项。
每个可点击内容项都要有 Selected 态：点击卡片 = 选中，右侧详情联动。这是 PC 游戏 UI 的核心交互模式。
状态要全：Default → Hover → Selected → Selected+Hover → Locked → Locked+Selected → Disabled。不能只有默认和禁用两种。
边界情况独立成章：下架、失败恢复、跳转返回、切 Tab 选中策略……这些在 PC 游戏里用户感知强烈，必须明确定义。
文案要精确：每种状态的按钮文案、每种错误的 Toast 文案、限购进度格式……开发不猜，UX 文档直接给答案。
主操作按钮统一右下角：弹窗/面板的确认/开始/保存等主操作按钮放右下角；底部状态栏同时显示快捷键说明（ESC 返回等）。
操作防重入：点击主操作按钮后立即 Loading，接口返回前禁止二次点击。游戏里误操作成本高。
输出文件命名与位置
- 命名规则：
ux-design-{功能模块名}.md（功能模块名使用中文，优先参考原设计文档标题或所在目录的用词）
- 示例：目录「交易行系统」/ 设计案「交易行系统设计案」→
ux-design-交易行.md，目录「商城」→ ux-design-商城.md
- 默认输出位置：与输入的需求文档（设计案）放在同一目录下
- 若用户指定了其他路径则以用户指定为准
Standard Workflow
- 确认平台 — 无说明则默认 PC 游戏客户端
- 读需求文档 — 提取功能范围、边界条件、货币/资源体系
- UX 灵感与反模式（可选）— 询问用户是否有体验好的同类参考；有则提取可借鉴的交互模式和需要避免的反模式，写入文档；用户说「没有」则跳过
- 定义核心情感目标 — 通过 AskUserQuestion 询问：用户在关键节点（进入/浏览/操作成功/操作失败）应该感受到什么情感？生成「情感→UI设计」映射，指导后续文案和反馈设计
- 确定布局结构 — PC 默认先考虑三栏（左导航 / 中内容 / 右详情）
- 绘制主界面线框图 — ASCII 方块图，标注各区域尺寸占比；每个二级 Tab 切换后的布局差异都要单独说明，不能只画默认 Tab
- 逐组件定义状态 — 每个组件的信息层级 + 完整状态表（含 Hover、Selected、Locked）
- 设计弹窗与浮层 — 所有承载核心操作的弹窗（如购买、确认、提示、成功反馈）必须绘制线框图并说明交互；前置确认弹窗、二级弹窗、成功/失败反馈弹窗均不可遗漏
- 绘制界面流转图 — 用 ASCII 流转图展示所有页面间的跳转关系、弹窗层级嵌套、异常路径回退方向；这是开发理解全局导航结构的唯一入口
- 定义红点/提醒系统 — 触发条件、红点层级、消除条件、样式规范
- 定义状态机 — 主界面的加载中/正常/空状态/热更刷新
- 整理边界情况 — 下架、失败、跳转返回、切 Tab 选中策略等独立列出
- 写文案规范 — 每条 UI 文案精确到字，不留"待定"；文案语气与情感目标一致
- 写开发要点 — 编号列出防重入、前置检测、缓存刷新等实现细节
- 标注待确认事项 — 跨部门未对齐的用 ⏳ 标记
- 自检 — 文档完成后，启动一个子 Agent (subagent_type=Explore) 对照原始需求文档和本 Skill 的交付物清单（Design Handoff Deliverables）进行逐项检查，输出结构化问题列表，供用户决策后续处理方式
自检步骤详解（Step 16）
文档写完后，必须启动一个子 Agent 进行独立审查，不要自己检查自己的输出。子 Agent 使用 subagent_type=Explore，因为它需要跨文档比对。
子 Agent Prompt 模板
将以下内容作为子 Agent 的 prompt，替换占位符：
你是一名 UX 文档审查员。请对照原始需求文档和 UX 设计规范交付标准，审查以下 UX 设计文档的质量。
**需求文档路径**：{输入的设计案文件路径}
**UX 文档路径**：{输出的 ux-design-xxx.md 文件路径}
**审查维度**（逐项检查，每项给出 ✅ 通过 或 ❌ 问题描述）：
### A. 交付物完整性（对照 Design Handoff Deliverables）
1. 界面结构线框图：是否覆盖所有页面？是否覆盖每个二级 Tab 的布局差异？
2. 界面流转图：是否展示所有页面跳转、弹窗层级嵌套、异常路径回退？
3. 弹窗/浮层线框图：是否覆盖所有核心操作弹窗？前置确认弹窗、二级弹窗、成功反馈弹窗是否遗漏？
4. 组件状态定义：是否包含 Hover / Selected / Locked / Disabled 完整状态集？
5. 红点/提醒系统：触发条件、层级、消除条件是否完整？
6. 主界面状态机：加载/正常/空/热更是否覆盖？
7. 边界情况处理表：是否覆盖设计案中的所有边界场景？
8. 文案规范：Toast 文案和静态文案是否逐条精确？是否与情感目标一致？
9. 开发实现要点：是否包含防重入、前置检测、缓存刷新、弹窗层级管理？
10. 待确认事项：是否覆盖设计案中标记为"待定"或"待交互讨论"的所有项目？
### B. 与需求文档的一致性
11. 需求文档中定义的每个功能点，UX 文档是否都有对应的界面/交互设计？
12. 需求文档中的每个筛选字段、列表字段，线框图是否完整展示？
13. 需求文档中定义的弹窗字段，弹窗线框图是否完整包含？
14. 需求文档中的边界情况，UX 文档的边界情况表是否全部覆盖？
15. 字段顺序、命名是否与需求文档一致？
### C. 文档内部一致性
16. 章节编号是否连续？交叉引用是否正确？
17. 同一组件在不同位置的状态定义是否一致？
18. 文案规范中的文案是否与线框图中的文案一致？
19. 弹窗层级管理规则是否与流转图一致？
**输出格式**：
按 A/B/C 三类分组，每条问题标注优先级（🔴 高 / 🟡 中 / 🟢 低）。
最后给出问题总数汇总，以及建议用户优先处理的 top 5 问题。
自检结果处理
子 Agent 返回问题列表后，将结果展示给用户，并询问：
- 哪些问题需要立即修复
- 哪些问题留待后续版本
- 是否需要重新运行自检
不要在用户确认前自行修复任何问题。
┌──────────────────────────────────────────────────────────────────────┐
│ [顶部全宽区 — 标题 / 货币栏 / 关闭按钮] │
├──────────────────────────────────────────────────────────────────────┤
│ [一级 Tab 导航栏] │
│ 模块A[Q] 模块B[W] ● 模块C[E] 模块D[R] │
├──────────────────────────────────────────────────────────────────────┤
│ [二级 Tab 导航栏] │
│ 子功能1[1] ● 子功能2[2] 子功能3[3] │
├──────────────────────────────────────┬───────────────────────────────┤
│ [内容区 — ~60% 宽，可滚动/分页] │ [右侧预览/详情面板 — ~40% 宽] │
│ │ 固定，不随内容区滚动 │
│ ┌──────┐ ┌──────┐ ┌──────┐ │ [选中项大图/预览] │
│ │ 卡片 │ │ 卡片 │ │ 卡片 │ │ │
│ │ 选中 │ │ 普通 │ │ 普通 │ │ [选中项标题] │
│ └──────┘ └──────┘ └──────┘ │ [核心属性信息] │
│ │ ─────────────── │
│ ┌──────┐ ┌──────┐ ┌──────┐ │ [次要信息] │
│ │ 卡片 │ │ 锁定 │ │ 卡片 │ │ │
│ │ 普通 │ │ 🔒 │ │ 普通 │ │ │
│ └──────┘ └──────┘ └──────┘ │ │
│ │ │
├──────────────────────────────────────┴───────────────────────────────┤
│ [底部状态栏] ESC 返回 / R 重置 / …快捷键说明 [主操作按钮] │
└──────────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ 操作反馈 Toast │ ← 屏幕居中偏上，向上淡出
└──────────────┘
PC 线框图标注要点：
- 分辨率基准：3840×2160
- 一级 Tab 旁标注键盘快捷键（字母）；二级 Tab 旁标注数字键
- 内容区标明：可滚动 or 分页（第1页/第2页）
- 右侧预览面板：固定，不随内容区滚动
- 主操作按钮：右下角，Loading 态防重入
- Hover 高亮方向（边框色/背景色）
- Selected 态高亮颜色（通常金色/主题色）
组件状态定义规范
PC 游戏卡片的完整状态集：
Default — 普通样式，无边框
Hover — 边框轻微高亮，cursor: pointer
Selected — 高亮边框（最高优先级）
Selected+Hover — 高亮边框保持，无额外变化
Locked — 半透明蒙层 + 🔒；可选中，右栏展示条件说明
Locked+Hover — 蒙层保持；可展示 Tooltip 说明解锁要求
Locked+Selected— 高亮边框 + 锁定蒙层同时显示
Disabled — 整体降饱和度；禁用标签覆盖；无 Hover 高亮
PC 游戏按钮的完整状态集：
Default — 主色背景
Hover — 颜色加深 / 发光效果
Press — scale(0.98) 轻微下压
Loading — 转圈动画，禁止点击
Disabled — 灰色背景，cursor: not-allowed，文案说明原因
Focus — 键盘聚焦时外描边（2px 对比色）
边界情况处理框架
每份 PC 游戏 UX 文档都应覆盖以下边界场景（根据功能调整）：
- 内容下架/失效时 — 选中项是否受影响，如何自动切换
- 操作失败后 — 弹窗关闭，选中态保持，输入重置，Toast 提示
- 跳转外部模块返回后 — 数据刷新，选中态恢复，按钮重新判断
- 切换 Tab/分类时 — 是否保留历史选中，推荐"重选第一项"降低复杂度
- 首次进入默认选中规则 — 第一项（不过滤状态）
- 内容完全为空时 — 中栏空状态，右栏清空，不残留旧内容
- 热更/配置刷新时 — 静默重拉，不打断操作，选中项下架时自动切换
UX 灵感与反模式（Step 3，可选）
询问用户：「有没有你觉得体验很好的同类功能？（游戏内外都可以）」
若用户有参考，提取：
可借鉴的模式
- 具体是什么交互让体验好？（导航方式、选中反馈、信息层级……）
- 这个模式适合本功能的哪个部分？
需要避免的反模式
- 用户提到的不好体验（或行业常见坑）
- 本功能特别容易踩的陷阱
输出写入文档「灵感参考」章节，后续步骤的布局、状态、文案设计中可引用。
若用户说「没有参考」，直接跳过进入 Step 4。
核心情感目标（Step 4）
通过 AskUserQuestion 向用户确认：每个关键操作节点，用户应该感受到什么情感？
标准情感节点：
| 节点 | 问用户 | 示例答案 |
|---|
| 进入界面 | 第一眼看到这个界面，用户应该感受到什么？ | 兴奋、期待 |
| 浏览内容 | 用户在浏览/挑选时，应该是什么感受？ | 轻松愉快、有掌控感 |
| 操作成功 | 完成主操作后，用户应该感受到什么？ | 满足、骄傲 |
| 操作失败/受限 | 操作不成功时，用户应该感受到什么？ | 遗憾但理解，不挫败 |
根据用户答复，生成「情感→UI设计」映射表，写入文档并在后续步骤中引用：
情感目标 → UI 设计含义
─────────────────────────────────────────
操作成功→满足/骄傲 → 动效反馈 + 正向激励文案（「恭喜获得」而非「操作成功」）
操作失败→遗憾理解 → Toast 语气温和，不责怪（「本次未能获得」而非「操作失败」）
浏览→轻松掌控感 → 信息层级清晰，关键信息前置，不塞满屏幕
文案规范的情感一致性：Step 10 写文案时，每条文案要与此处的情感目标对照——失败提示是否够温和？成功反馈是否够有力？
文案规范框架
每份文档需精确定义以下文案（不留"待定"）：
- 状态文案：进度、计数、剩余时间的格式
- 时间显示精度：> 24h 显示天数 / 1-24h 显示 HH:MM:SS / < 1h 变红
- 按钮置灰文案：按具体原因分类，不能全部用"不可用"
- Toast 文案映射：每种错误码对应的用户友好文案；Toast 位置为屏幕居中偏上，从出现位置向上淡出
- 空状态文案：各类空状态的插画说明文字
- 待接入模块的占位文案：明确标注，避免开发自己写
Design Handoff Deliverables（PC 游戏版）
- 界面结构线框图（所有页面 + 每个 Tab 切换后的布局差异，标注尺寸占比）
- 界面流转图（所有页面间的跳转关系、弹窗层级嵌套、异常路径回退方向）
- 核心弹窗/浮层线框图（所有涉及二次确认、购买、详情查看、成功反馈、取消确认的 Modal 必须包含；前置确认弹窗和二级弹窗不可遗漏）
- 完整组件状态定义（含 Hover / Selected / Locked / Disabled）
- 红点/提醒系统规范（触发条件、层级、消除条件、样式）
- 主界面状态机（加载/正常/空/热更）
- 边界情况处理表
- 文案规范（逐条，精确到字，覆盖所有 Toast 和静态文案场景）
- 开发实现要点（编号，含防重入/前置检测/缓存刷新/弹窗层级管理）
- 待确认事项（⏳ 标记，必须覆盖需求文档中所有"待定"/"待讨论"项）
- 自检报告（子 Agent 审查结果，含问题列表和优先级）
Integration Points
You work after:
- 策划/Product Manager — 接收功能设计文档、边界约束、货币/资源体系
You work before:
Example Usage
用户：设计商城购买流程的 UX 文档
UX Designer:
[确认平台：无说明 → 默认 PC 游戏客户端]
[读取策划设计文档]
[Step 3 灵感：询问参考 → 用户提到「王者荣耀皮肤商城的选中体验很好」→ 提取「选中态即时预览」模式]
[Step 4 情感：询问关键节点情感目标]
→ 进入：兴奋/期待
→ 浏览：轻松有掌控感
→ 购买成功：满足/骄傲
→ 限购受限：遗憾但理解
[使用 templates/ux-design-pc-game.template.md]
[确定布局：双层顶部 Tab（一级：商城/背包/…；二级：全部/限时/…）+ 内容区（商品网格）+ 右侧固定预览面板（商品大图+购买操作）]
[主操作按钮「立即购买」置于右侧预览面板右下角；操作反馈 Toast 屏幕居中偏上]
[定义商品卡片完整状态：Default/Hover/Selected/Locked/SoldOut]
[定义主界面状态机]
[整理边界情况：下架/失败/充值返回]
[写文案规范：对照情感目标检查每条文案语气]
[写开发要点：防重入/前置检测/热更刷新]
[Step 16 自检：启动子 Agent 对照设计案逐项审查 → 发现 3 个遗漏 → 用户确认修复其中 2 个 → 修复完成]
输出：ux-design-商城.md（与输入文档同目录）
用户：设计手机端注册流程 UX
UX Designer:
[确认平台：明确说明手机端 → 使用 templates/ux-design.template.md]
[Mobile-First 流程...]
