| name | ue-review |
| description | 前端交互体验（UE/UX）评估与指导。覆盖交互反馈、状态可见性、操作流程、 弹窗覆盖层、布局空间、一致性、错误预防、可发现性 8 个维度。 与 frontend-design（视觉/样式）互补，本 skill 回答"好不好用"。 提供审查模式（出评估报告）和指导模式（交互设计建议）两种使用方式。 |
这是一项前端交互体验（UE）评估技能，与 frontend-design（视觉/样式）互补。
frontend-design 回答的是"好不好看"，这个 skill 回答的是"好不好用"。
核心理念
好的交互设计应该让用户感到 effortless（毫不费力）。一个页面如果用户需要思考"这个能不能点？"、"点了之后会发生什么？"、"我刚做的操作有生效吗？"——那就是交互设计出了问题。
两种使用模式
模式 A：审查模式（Review）
已有页面的代码/截图/描述，逐项审查找出交互问题并出报告。
使用方式： 提供页面代码、截图 URL、组件描述或页面路由路径，skill 基于 UE 评估框架逐项审查，输出结构化审查报告。审查完成后必须给出维度覆盖率说明，让委托方知道哪些方面被覆盖、哪些被跳过。
模式 B：指导模式（Guidance）
在编码阶段，询问某个交互应该怎么做。
使用方式： 描述正在开发的功能或组件，skill 基于 UE 评估框架给出交互设计建议，用 checklist 内容作为设计原则指导编码。
指导模式输出结构：
## 交互设计建议：[场景描述]
### 方案描述
说明推荐的交互模式及其理由
### 相关原则
引用 checklist 中的具体条目作为设计依据
- D4.1: 弹窗不应遮挡用户需要参考的内容
- D3.2: 批量操作应支持全选
### 推荐方案 vs 备选方案
| 方案 | 优点 | 缺点 | 适用场景 |
|------|------|------|---------|
| 方案A: ... | ... | ... | ... |
| 方案B: ... | ... | ... | ... |
### 实现要点
编码时需要注意的关键细节
1. ...
2. ...
### 反模式提醒
避免以下常见错误
- ...
重要： 指导模式下同样要说明你的建议覆盖了哪些 UE 维度（如"本建议主要涉及 D4 弹窗与覆盖层、D3 操作流程两个维度"）。
UE 评估框架
评估覆盖 8 个维度，每个维度包含评价要点和常见反模式（来自真实项目经验）：
D1. 交互反馈（Interaction Feedback）
核心原则： 每次用户操作，系统必须在合理时间内给出明确反馈。没有反馈 = 用户焦虑。
| # | 检查项 | 严重等级 |
|---|
| 1.1 | 按钮/可点击元素点击后是否有明确的视觉反馈（状态变化、微动效、颜色变化）？ | 🔴 严重 |
| 1.2 | 表单提交/保存操作后是否有成功/失败提示（toast / message / inline error）？ | 🔴 严重 |
| 1.3 | 加载/处理中是否有进度指示（spinner / skeleton / progress bar / 百分比）？ | 🔴 严重 |
| 1.4 | hover / focus / active / disabled 四种状态是否视觉可区分？ | 🟡 一般 |
| 1.5 | 操作反馈是否即时（< 100ms 即时反馈，> 1s 显示加载态）？ | 🟡 一般 |
| 1.6 | 触屏设备上的点击反馈是否通过视觉变化体现（因不支持 hover，需用 active/点击态替代）？ | 🟡 一般 |
| 1.7 | Toast / message 提示是否不遮挡关键内容且可手动关闭？ | 🟢 建议 |
| 1.8 | 空状态（无数据）是否有引导性提示（不是白屏、不是"暂无数据"四个字无下文）？ | 🟡 一般 |
常见反模式：
- 点击按钮后没有任何变化，3 秒后突然弹出结果 → 用户会反复点击
- 表单提交成功没有任何提示，用户以为没成功 → 重复提交
- Loading spinner 放在远处（如页面顶部），用户操作位置在底部 → 看不到反馈
- 空状态只有一行字，用户不知道下一步该做什么
D2. 状态可见性（State Visibility）
核心原则： 系统状态必须对用户可见。用户需要随时知道"现在处于什么阶段"。
| # | 检查项 | 严重等级 |
|---|
| 2.1 | 流程性任务是否明确标示当前步骤 / 总步骤？ | 🔴 严重 |
| 2.2 | 互斥的状态是否互斥展示（例如：进度中不展示结果，出结果后不再展示进度）？ | 🔴 严重 |
| 2.3 | Tab / 视图切换时，当前选中状态是否明确标示？ | 🟡 一般 |
| 2.4 | 表单是否有自动保存指示（已保存/保存中/未保存更改）？ | 🟢 建议 |
| 2.5 | 列表/表格是否有选中状态视觉标示（多选时已选行与未选行明确区分）？ | 🟡 一般 |
| 2.6 | 页面是否有无网络/断连状态处理？ | 🟢 建议 |
常见反模式：
- 识别/处理过程中突然完整展示结果区域（还没处理完就弹出空白结果框）→ 体验割裂
- 步骤 1 已完成但没有对勾/绿色标记，用户不确定能不能进行下一步
- 表格行点击后没有高亮，用户不记得选了哪一行
D3. 操作流程与效率（Task Flow & Efficiency）
核心原则： 用最少的步骤完成任务。每个多余的点击都在消耗用户的耐心。
| # | 检查项 | 严重等级 |
|---|
| 3.1 | 核心任务需要几步才能完成？是否有不必要的中间步骤？ | 🔴 严重 |
| 3.2 | 批量操作是否支持全选 / 反选 / 批量编辑？ | 🟡 一般 |
| 3.3 | 常用操作是否有快捷键（键盘导航）支持？ | 🟢 建议 |
| 3.4 | 列表项的操作入口是否清晰合理（不是每项都显示全部操作按钮，而是 hover 展开或三点菜单）？ | 🟡 一般 |
| 3.5 | 页面是否提供默认值或智能预填来减少用户输入？ | 🟡 一般 |
| 3.6 | 高频操作是否可以一键完成（如模板、快捷入口、最近使用）？ | 🟢 建议 |
| 3.7 | 表单是否支持 Enter 键提交（而非必须点击按钮）？ | 🟢 建议 |
常见反模式：
- 每行数据都显示删除/编辑/下载按钮 → 视觉杂乱，看不清数据
- 添加一条数据需要弹窗 → 填写 → 关闭弹窗 → 回到列表刷新看到结果，其实可以直接 inline 编辑
- 批量操作需要在每条数据上重复点击，没有全选功能
- 一个简单的筛选操作需要跳转到一个新的独立页面
D4. 弹窗与覆盖层（Modal / Overlay / Dialog）
核心原则： 弹窗应该增强而不是打断工作流。弹窗遮住的内容应该是当前操作不需要看到的。
| # | 检查项 | 严重等级 |
|---|
| 4.1 | 弹窗打开后，用户是否需要同时参考被遮挡的背景内容？如果是，不应该用弹窗。 | 🔴 严重 |
| 4.2 | 弹窗是否支持 ESC 关闭和点击蒙层关闭（非 destructive 操作）？ | 🟡 一般 |
| 4.3 | 弹窗关闭后，焦点是否合理返回（回到触发按钮 或 下一个合理位置）？ | 🟡 一般 |
| 4.4 | 内容过多的弹窗是否应该改用侧边栏/抽屉（drawer）或独立页面？ | 🟡 一般 |
| 4.5 | 弹窗打开时，背景是否应该有适当的遮罩（但不过暗）？ | 🟢 建议 |
| 4.6 | 多层级弹窗是否应该避免（弹窗里再弹窗）？ | 🟡 一般 |
常见反模式：
- 选择规范条文的弹窗遮住了右侧的关联区域 → 用户需要来回关闭/打开弹窗对照内容
- 弹窗内容太长出现滚动条 + 弹窗本身也有滚动条 → 嵌套滚动，体验极差
- 弹窗里再弹一个确认弹窗 → 用户迷失层级
D5. 布局与空间利用（Layout & Space Utilization）
核心原则： 布局服务于操作流。空间应该被有效利用，内容密度随屏幕尺寸自适应。
| # | 检查项 | 严重等级 |
|---|
| 5.1 | 页面布局是否充分利用可用空间（宽屏下不显得松散空洞）？ | 🟡 一般 |
| 5.2 | 长内容区域是否限制高度并启用滚动？ | 🟡 一般 |
| 5.3 | 内容量大的页面是否采用左右布局而非上下布局来节省纵向空间？ | 🟡 一般 |
| 5.4 | 信息层级是否合理（相关内容是否就近放置，不相关内容是否视觉分离）？ | 🟡 一般 |
| 5.5 | 响应式断点下布局是否会断裂（元素重叠、溢出、消失）？ | 🔴 严重 |
| 5.6 | 移动端/触屏下点击目标尺寸是否足够大（≥ 44×44px 触控区域）？ | 🟡 一般 |
| 5.7 | 移动端是否避免hover 依赖型交互（如下拉菜单需 hover 才能展开，触屏无 hover）？ | 🔴 严重 |
常见反模式：
- 上下两栏布局在宽屏下中间大片空白 → 上下太矮，左右太空
- 识别结果直接全部展开没有高度限制 → 内容过多撑满全屏
- 信息 A 在页面顶部操作，信息 B 在页面底部，但 A 和 B 是关联的 → 用户反复上下滚动
- 桌面端 hover 展开的操作菜单，在触屏上点一下展开又点一下消失 → 触屏无法使用
- 小按钮/图标点击区域过小（< 44px），手指点击经常误触相邻元素
D6. 一致性（Consistency）
核心原则： 相同操作在页面不同位置应该表现一致。用户不需要重新学习。
| # | 检查项 | 严重等级 |
|---|
| 6.1 | 同类操作的按钮位置是否一致（如编辑/删除按钮在不同列表项中位置相同）？ | 🟡 一般 |
| 6.2 | 相同含义的文案/图标是否全站统一（如"删除"不出现"移除""清除")？ | 🟢 建议 |
| 6.3 | 表单控件的交互行为是否一致（如回车提交、Tab 切换字段）？ | 🟡 一般 |
| 6.4 | 列表页和详情页之间的术语/状态是否一致？ | 🟢 建议 |
| 6.5 | 空状态 / 加载态 / 错误态在不同页面是否使用统一模式？ | 🟡 一般 |
常见反模式：
- 有的页面删除是图标按钮，有的页面是文字链接
- 列表页叫"审核中"，详情页叫"待审批" → 用户困惑是不是同一个状态
- 一个页面 hover 显示操作菜单，另一个页面操作按钮一直显示
D7. 错误预防与恢复（Error Prevention & Recovery）
核心原则： 最好的错误处理是防止错误发生。当错误发生时，让用户能轻松恢复。
| # | 检查项 | 严重等级 |
|---|
| 7.1 | 破坏性操作（删除、清空、提交后不可修改）是否有二次确认？ | 🔴 严重 |
| 7.2 | 表单输入是否即时校验（输入完成后立即提示格式错误，而非提交后统一报错）？ | 🟡 一般 |
| 7.3 | 错误提示是否明确说明问题并给出解决指引而非笼统的"操作失败"？ | 🔴 严重 |
| 7.4 | 是否支持 Undo / 撤销 操作（如删除后提供撤销按钮而非直接删除）？ | 🟢 建议 |
| 7.5 | 表单填写中途离开是否会保存草稿或给出提示？ | 🟢 建议 |
| 7.6 | 错误发生时，用户输入的内容是否不被清空？ | 🔴 严重 |
常见反模式：
- 点击删除直接删除没有确认 → 误删无法恢复
- 表单提交后报错，填写的内容全部清空 → 用户需要重新填写
- 提示"网络错误"但不告诉用户该怎么办 → 用户无助
- 校验在提交时才统一执行 → 用户填完一整页才发现第一个字段就错了
D8. 可发现性（Discoverability）
核心原则： 用户应该能直观地知道哪些内容可操作、如何操作，不需要猜测或试探。
| # | 检查项 | 严重等级 |
|---|
| 8.1 | 可交互元素是否有正确的视觉提示（按钮样式、链接样式、光标变化）？ | 🟡 一般 |
| 8.2 | 不可交互元素是否没有误导性视觉提示（如非链接文字不下划线、非按钮不显示按钮样式）？ | 🟡 一般 |
| 8.3 | 隐藏操作（hover 出现操作菜单）是否有视觉暗示该区域可交互（如背景色变化）？ | 🟡 一般 |
| 8.4 | 页面是否有多余的视觉噪音（无实际功能指向性的图标、箭头、装饰性动效）？ | 🟢 建议 |
| 8.5 | 新手用户首次使用时是否有引导/提示（如 onboarding 引导、空状态指引）？ | 🟢 建议 |
常见反模式：
- 整张卡片可点击跳转，但悬浮还显示一个箭头 → 箭头多余，应该删掉
- 文字看起来像链接（蓝色 + 下划线），点击却无反应 → 欺骗用户
- 操作菜单完全靠 hover 才显示，但没有视觉暗示该行可交互 → 用户不知道这里能操作
- 页面动效/装饰元素过多，干扰用户找到真正的操作入口
评估报告输出格式
审查模式下，输出结构化 UE 评估报告（Markdown）。
报告中必须包含以下部分：
# UE 评估报告：[页面/组件名称]
## 概览
- 评估维度覆盖：D1~D8 中的 X 个
- 🔴 严重问题：X 个 | 🟡 一般问题：X 个 | 🟢 建议：X 个
- 总体评估：优/良/中/差
## 评估覆盖说明
| 维度 | 已评估 | 说明 |
|------|--------|------|
| D1 交互反馈 | ✅/❌ | 如未评估，说明原因（如"该页面无表单/按钮，不适用"）|
| D2 状态可见性 | ✅/❌ | ... |
| D3 操作流程 | ✅/❌ | ... |
| D4 弹窗与覆盖层 | ✅/❌ | ... |
| D5 布局与空间 | ✅/❌ | ... |
| D6 一致性 | ✅/❌ | ... |
| D7 错误预防 | ✅/❌ | ... |
| D8 可发现性 | ✅/❌ | ... |
## 发现的问题
### [D1.交互反馈] 🔴 问题标题
**问题描述：** 具体描述问题现象
**位置：** 组件/代码位置
**影响：** 对用户体验的影响
**建议修改：** 具体的修改方案
**参考：** checklist D1.X
---
### [D3.操作流程] 🟡 问题标题
...以此类推
## 综合建议
按优先级列出 3-5 条最重要的改进建议。
## 改进对照表
| 维度 | 问题数 | 已解决 | 待解决 |
|------|--------|--------|--------|
| D1 交互反馈 | 2 | 0 | 2 |
| D2 状态可见性 | 1 | 0 | 1 |
| ... | ... | ... | ... |
为什么必须做评估覆盖说明？ 没有覆盖说明的报告会让委托方误以为"所有维度都检查过了没问题"。明确标注未覆盖的维度能：
- 让审查结果更诚实可信
- 提示委托方哪些方面需要自己额外关注
- 防止因评估框架不适用导致的误判
指导模式下，直接针对当前问题给出交互设计建议，引用 checklist 中的原则。
补充说明
- 与 frontend-design 协作： 如果用户同时要求视觉和交互层面的评估，先调用本 skill 完成 UE 评估，再调用 frontend-design 评估视觉/样式。两者关注点不同，不要混淆。
- 严重等级定义：
- 🔴 严重（Critical）：阻碍任务完成、可能导致数据丢失、严重困惑
- 🟡 一般（Major）：影响效率、增加认知负担、轻微困惑
- 🟢 建议（Minor）：体验优化、最佳实践、提升满意度
- 评估依据来源： 本 checklist 基于实际项目中的 UE 审查经验总结（包括规范审查页、关联规范弹窗、文档生成页等真实案例），而非纯理论框架。
