メニュー
前端交互体验（UE/UX）评估与指导。覆盖交互反馈、状态可见性、操作流程、 弹窗覆盖层、布局空间、一致性、错误预防、可发现性 8 个维度。 与 frontend-design（视觉/样式）互补，本 skill 回答"好不好用"。 提供审查模式（出评估报告）和指导模式（交互设计建议）两种使用方式。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/zhuzhaoyun/ZZY-SKILLS --skill ue-reviewコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
SOC 職業分類に基づく
| name | ue-review |
| description | 前端交互体验（UE/UX）评估与指导。覆盖交互反馈、状态可见性、操作流程、 弹窗覆盖层、布局空间、一致性、错误预防、可发现性 8 个维度。 与 frontend-design（视觉/样式）互补，本 skill 回答"好不好用"。 提供审查模式（出评估报告）和指导模式（交互设计建议）两种使用方式。 |
这是一项前端交互体验（UE）评估技能，与 frontend-design（视觉/样式）互补。
frontend-design 回答的是"好不好看"，这个 skill 回答的是"好不好用"。
好的交互设计应该让用户感到 effortless（毫不费力）。一个页面如果用户需要思考"这个能不能点？"、"点了之后会发生什么？"、"我刚做的操作有生效吗？"——那就是交互设计出了问题。
已有页面的代码/截图/描述，逐项审查找出交互问题并出报告。
使用方式： 提供页面代码、截图 URL、组件描述或页面路由路径，skill 基于 UE 评估框架逐项审查，输出结构化审查报告。审查完成后必须给出维度覆盖率说明，让委托方知道哪些方面被覆盖、哪些被跳过。
在编码阶段，询问某个交互应该怎么做。
使用方式： 描述正在开发的功能或组件，skill 基于 UE 评估框架给出交互设计建议，用 checklist 内容作为设计原则指导编码。
指导模式输出结构：
## 交互设计建议：[场景描述]
### 方案描述
说明推荐的交互模式及其理由
### 相关原则
引用 checklist 中的具体条目作为设计依据
- D4.1: 弹窗不应遮挡用户需要参考的内容
- D3.2: 批量操作应支持全选
### 推荐方案 vs 备选方案
| 方案 | 优点 | 缺点 | 适用场景 |
|------|------|------|---------|
| 方案A: ... | ... | ... | ... |
| 方案B: ... | ... | ... | ... |
### 实现要点
编码时需要注意的关键细节
1. ...
2. ...
### 反模式提醒
避免以下常见错误
- ...
重要： 指导模式下同样要说明你的建议覆盖了哪些 UE 维度（如"本建议主要涉及 D4 弹窗与覆盖层、D3 操作流程两个维度"）。
评估覆盖 8 个维度，每个维度包含评价要点和常见反模式（来自真实项目经验）：
核心原则： 每次用户操作，系统必须在合理时间内给出明确反馈。没有反馈 = 用户焦虑。
| # | 检查项 | 严重等级 |
|---|---|---|
| 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 | 空状态（无数据）是否有引导性提示（不是白屏、不是"暂无数据"四个字无下文）？ | 🟡 一般 |
常见反模式：
核心原则： 系统状态必须对用户可见。用户需要随时知道"现在处于什么阶段"。
| # | 检查项 | 严重等级 |
|---|---|---|
| 2.1 | 流程性任务是否明确标示当前步骤 / 总步骤？ | 🔴 严重 |
| 2.2 | 互斥的状态是否互斥展示（例如：进度中不展示结果，出结果后不再展示进度）？ | 🔴 严重 |
| 2.3 | Tab / 视图切换时，当前选中状态是否明确标示？ | 🟡 一般 |
| 2.4 | 表单是否有自动保存指示（已保存/保存中/未保存更改）？ | 🟢 建议 |
| 2.5 | 列表/表格是否有选中状态视觉标示（多选时已选行与未选行明确区分）？ | 🟡 一般 |
| 2.6 | 页面是否有无网络/断连状态处理？ | 🟢 建议 |
常见反模式：
核心原则： 用最少的步骤完成任务。每个多余的点击都在消耗用户的耐心。
| # | 检查项 | 严重等级 |
|---|---|---|
| 3.1 | 核心任务需要几步才能完成？是否有不必要的中间步骤？ | 🔴 严重 |
| 3.2 | 批量操作是否支持全选 / 反选 / 批量编辑？ | 🟡 一般 |
| 3.3 | 常用操作是否有快捷键（键盘导航）支持？ | 🟢 建议 |
| 3.4 | 列表项的操作入口是否清晰合理（不是每项都显示全部操作按钮，而是 hover 展开或三点菜单）？ | 🟡 一般 |
| 3.5 | 页面是否提供默认值或智能预填来减少用户输入？ | 🟡 一般 |
| 3.6 | 高频操作是否可以一键完成（如模板、快捷入口、最近使用）？ | 🟢 建议 |
| 3.7 | 表单是否支持 Enter 键提交（而非必须点击按钮）？ | 🟢 建议 |
常见反模式：
核心原则： 弹窗应该增强而不是打断工作流。弹窗遮住的内容应该是当前操作不需要看到的。
| # | 检查项 | 严重等级 |
|---|---|---|
| 4.1 | 弹窗打开后，用户是否需要同时参考被遮挡的背景内容？如果是，不应该用弹窗。 | 🔴 严重 |
| 4.2 | 弹窗是否支持 ESC 关闭和点击蒙层关闭（非 destructive 操作）？ | 🟡 一般 |
| 4.3 | 弹窗关闭后，焦点是否合理返回（回到触发按钮 或 下一个合理位置）？ | 🟡 一般 |
| 4.4 | 内容过多的弹窗是否应该改用侧边栏/抽屉（drawer）或独立页面？ | 🟡 一般 |
| 4.5 | 弹窗打开时，背景是否应该有适当的遮罩（但不过暗）？ | 🟢 建议 |
| 4.6 | 多层级弹窗是否应该避免（弹窗里再弹窗）？ | 🟡 一般 |
常见反模式：
核心原则： 布局服务于操作流。空间应该被有效利用，内容密度随屏幕尺寸自适应。
| # | 检查项 | 严重等级 |
|---|---|---|
| 5.1 | 页面布局是否充分利用可用空间（宽屏下不显得松散空洞）？ | 🟡 一般 |
| 5.2 | 长内容区域是否限制高度并启用滚动？ | 🟡 一般 |
| 5.3 | 内容量大的页面是否采用左右布局而非上下布局来节省纵向空间？ | 🟡 一般 |
| 5.4 | 信息层级是否合理（相关内容是否就近放置，不相关内容是否视觉分离）？ | 🟡 一般 |
| 5.5 | 响应式断点下布局是否会断裂（元素重叠、溢出、消失）？ | 🔴 严重 |
| 5.6 | 移动端/触屏下点击目标尺寸是否足够大（≥ 44×44px 触控区域）？ | 🟡 一般 |
| 5.7 | 移动端是否避免hover 依赖型交互（如下拉菜单需 hover 才能展开，触屏无 hover）？ | 🔴 严重 |
常见反模式：
核心原则： 相同操作在页面不同位置应该表现一致。用户不需要重新学习。
| # | 检查项 | 严重等级 |
|---|---|---|
| 6.1 | 同类操作的按钮位置是否一致（如编辑/删除按钮在不同列表项中位置相同）？ | 🟡 一般 |
| 6.2 | 相同含义的文案/图标是否全站统一（如"删除"不出现"移除""清除")？ | 🟢 建议 |
| 6.3 | 表单控件的交互行为是否一致（如回车提交、Tab 切换字段）？ | 🟡 一般 |
| 6.4 | 列表页和详情页之间的术语/状态是否一致？ | 🟢 建议 |
| 6.5 | 空状态 / 加载态 / 错误态在不同页面是否使用统一模式？ | 🟡 一般 |
常见反模式：
核心原则： 最好的错误处理是防止错误发生。当错误发生时，让用户能轻松恢复。
| # | 检查项 | 严重等级 |
|---|---|---|
| 7.1 | 破坏性操作（删除、清空、提交后不可修改）是否有二次确认？ | 🔴 严重 |
| 7.2 | 表单输入是否即时校验（输入完成后立即提示格式错误，而非提交后统一报错）？ | 🟡 一般 |
| 7.3 | 错误提示是否明确说明问题并给出解决指引而非笼统的"操作失败"？ | 🔴 严重 |
| 7.4 | 是否支持 Undo / 撤销 操作（如删除后提供撤销按钮而非直接删除）？ | 🟢 建议 |
| 7.5 | 表单填写中途离开是否会保存草稿或给出提示？ | 🟢 建议 |
| 7.6 | 错误发生时，用户输入的内容是否不被清空？ | 🔴 严重 |
常见反模式：
核心原则： 用户应该能直观地知道哪些内容可操作、如何操作，不需要猜测或试探。
| # | 检查项 | 严重等级 |
|---|---|---|
| 8.1 | 可交互元素是否有正确的视觉提示（按钮样式、链接样式、光标变化）？ | 🟡 一般 |
| 8.2 | 不可交互元素是否没有误导性视觉提示（如非链接文字不下划线、非按钮不显示按钮样式）？ | 🟡 一般 |
| 8.3 | 隐藏操作（hover 出现操作菜单）是否有视觉暗示该区域可交互（如背景色变化）？ | 🟡 一般 |
| 8.4 | 页面是否有多余的视觉噪音（无实际功能指向性的图标、箭头、装饰性动效）？ | 🟢 建议 |
| 8.5 | 新手用户首次使用时是否有引导/提示（如 onboarding 引导、空状态指引）？ | 🟢 建议 |
常见反模式：
审查模式下，输出结构化 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 中的原则。