메뉴
前端交互体验（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명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Behavioral guidelines to reduce common AI mistakes in daily tasks and office work. Use when writing, editing, organizing, or managing tasks to avoid overcomplication, make focused changes, surface assumptions, and define verifiable success criteria.
Use when the user mentions knowledge base, wiki, 知识库, 查知识库, 搜知识库, 维基问答, 知识图谱, or says "帮我查一下知识库", "知识库里有没有", "wiki 里找找", "导入文档". Also for uploading files, editing wiki pages, or any WeKnora operation.
整理会议纪要。当用户提供会议录音的文字稿、笔记、文字记录，并要求"整理纪要"、"整理会议记录"、"写会议纪要"、"总结会议内容"、"提取待办"、"做会议总结"时，必须使用此技能。输入可能是杂乱无章的语音转文字稿、手写笔记的电子版、或同事发来的会议草稿。输出是结构化的 Markdown 纪要文件，包含议题讨论、待办清单（含隐式待办自动提取）、风险标注。自动识别会议类型（决策会/同步会/头脑风暴），对不同类型使用针对性的模板结构。即使看起来只是简单要求"帮我整理一下"，也应使用此技能。
SOC 직업 분류 기준
SKILL.md 표시 중
| 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 中的原则。