# Ue Review

> 前端交互体验（UE/UX）评估与指导。覆盖交互反馈、状态可见性、操作流程、 弹窗覆盖层、布局空间、一致性、错误预防、可发现性 8 个维度。 与 frontend-design（视觉/样式）互补，本 skill 回答"好不好用"。 提供审查模式（出评估报告）和指导模式（交互设计建议）两种使用方式。

- Skill: `zhuzhaoyun/ue-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zhuzhaoyun/ue-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhuzhaoyun/ue-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: zhuzhaoyun (https://skillmd.com/u/zhuzhaoyun)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhuzhaoyun/ue-review

---


这是一项**前端交互体验（UE）评估**技能，与 `frontend-design`（视觉/样式）互补。

`frontend-design` 回答的是"好不好看"，这个 skill 回答的是"好不好用"。

## 核心理念

好的交互设计应该让用户感到 **effortless**（毫不费力）。一个页面如果用户需要思考"这个能不能点？"、"点了之后会发生什么？"、"我刚做的操作有生效吗？"——那就是交互设计出了问题。

## 两种使用模式

### 模式 A：审查模式（Review）

已有页面的代码/截图/描述，逐项审查找出交互问题并出报告。

**使用方式：** 提供页面代码、截图 URL、组件描述或页面路由路径，skill 基于 UE 评估框架逐项审查，输出结构化审查报告。审查完成后**必须给出维度覆盖率说明**，让委托方知道哪些方面被覆盖、哪些被跳过。

### 模式 B：指导模式（Guidance）

在编码阶段，询问某个交互应该怎么做。

**使用方式：** 描述正在开发的功能或组件，skill 基于 UE 评估框架给出交互设计建议，用 checklist 内容作为设计原则指导编码。

**指导模式输出结构：**

```markdown
## 交互设计建议：[场景描述]

### 方案描述
说明推荐的交互模式及其理由

### 相关原则
引用 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）。

**报告中必须包含以下部分：**

```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 中的原则。

## 补充说明

1. **与 frontend-design 协作：** 如果用户同时要求视觉和交互层面的评估，先调用本 skill 完成 UE 评估，再调用 frontend-design 评估视觉/样式。两者关注点不同，不要混淆。
2. **严重等级定义：**
   - 🔴 严重（Critical）：阻碍任务完成、可能导致数据丢失、严重困惑
   - 🟡 一般（Major）：影响效率、增加认知负担、轻微困惑
   - 🟢 建议（Minor）：体验优化、最佳实践、提升满意度
3. **评估依据来源：** 本 checklist 基于实际项目中的 UE 审查经验总结（包括规范审查页、关联规范弹窗、文档生成页等真实案例），而非纯理论框架。