usability-evaluation

name	usability-evaluation
description	评审界面可用性时使用。适用于设计稿评审、上线前检查、改版前诊断。优先使用 Nielsen 十大启发式 + 严重程度评分 + 行动项。

可用性评审（Usability Evaluation）

参考来源：Nielsen Norman Group - 10 Usability Heuristics

适用场景

• 设计稿评审
• 上线前最后检查
• 改版前的旧版诊断
• 竞品分析

不适用场景

• 早期探索（先做 user-flow）
• 未实现的概念（无东西可评）

Nielsen 十大启发式

1. 系统状态可见性（Visibility of System Status）

用户是否随时知道系统在做什么？

✅ 加载指示、进度条、状态标签
❌ 点击后无反馈、加载卡住、状态不明

2. 系统与现实世界匹配（Match between System and Real World）

用语是否是用户熟悉的？

✅ 用业务语言（"订单"、"客户"）
❌ 用技术术语（"实体"、"对象"）

3. 用户控制和自由（User Control and Freedom）

用户是否能撤销、返回、取消？

✅ 撤销按钮、确认对话框、明确的退出
❌ 无法撤销、强制完成、被困在流程里

4. 一致性和标准（Consistency and Standards）

同样的操作是否在所有页面表现一致？

✅ 按钮颜色 / 位置 / 命名一致
❌ 同功能不同页面表现不同

5. 错误预防（Error Prevention）

是否在用户犯错前就阻止？

✅ 禁用无效选项、确认危险操作、输入限制
❌ 让用户输入错误后才报错

6. 识别而非回忆（Recognition Rather than Recall）

用户是否需要记住信息？

✅ 选项可见、上下文提示、最近使用
❌ 让用户记住步骤 / 命令 / ID

7. 灵活性和效率（Flexibility and Efficiency）

是否同时满足新手和专家？

✅ 快捷键、批量操作、自定义
❌ 所有用户走同一个流程

8. 美学和极简设计（Aesthetic and Minimalist Design）

是否只展示必要信息？

✅ 信息层级清晰、留白充足
❌ 信息堆砌、视觉噪音

9. 帮助识别、诊断和恢复错误（Help Recognize, Diagnose, Recover）

错误信息是否说明了问题和解决方案？

✅ "邮箱格式不正确，应为 [e-mail]"
❌ "Error 500"、"操作失败"

10. 帮助和文档（Help and Documentation）

是否在需要时提供帮助？

✅ 工具提示、引导、FAQ 链接
❌ 没有帮助、文档难找

严重程度评分

0 - 不是问题（不影响用户）
1 - 表面问题（仅在等待时解决）
2 - 小问题（低优先级修复）
3 - 大问题（高优先级修复）
4 - 灾难性（必须修复才能上线）

评审报告模板

## 可用性评审报告：[页面/功能名]

### 评审基本信息

- 评审对象：[页面或功能]
- 评审方法：Nielsen 十大启发式
- 评审日期：YYYY-MM-DD
- 评审者：UI/UX 设计工作流

### 问题清单

| # | 启发式 | 问题描述 | 位置 | 严重度 | 建议修复 |
|---|--------|---------|------|--------|---------|
| 1 | 系统状态可见性 | 提交按钮点击后 5 秒无反馈，用户不知道是否成功 | 注册页 | 3 | 添加 Loading 状态 + 成功提示 |
| 2 | 错误预防 | 删除按钮直接执行，无二次确认 | 用户管理 | 4 | 添加确认对话框 + 输入"DELETE"确认 |
| 3 | 识别而非回忆 | 表单错误后清空已填字段 | 注册页 | 3 | 保留已填内容，仅高亮错误字段 |
| 4 | 一致性和标准 | "保存"按钮在不同页面颜色不一致 | 多页面 | 2 | 统一为 primary 色 |
| 5 | 错误诊断 | 报错只显示"Error"，无具体原因 | API 调用 | 3 | 显示具体错误码和恢复建议 |

### 严重度统计

- 灾难性（4）：1 个
- 大问题（3）：3 个
- 小问题（2）：1 个
- 表面问题（1）：0 个

### 优先修复

P0（必须修复才能上线）：
- 删除按钮缺少二次确认（#2）

P1（高优先级）：
- 提交按钮无加载反馈（#1）
- 错误后清空字段（#3）
- 错误信息不可诊断（#5）

P2（可后置）：
- 按钮颜色不一致（#4）

### 整体评估

整体可用性：⭐⭐⭐ / 5
主要问题领域：错误处理、一致性
推荐：修复 P0 后可上线，P1 在下个迭代修复

工作流程

1. 准备评审对象（设计稿 / 已上线页面）
2. 依次应用 10 条启发式
3. 记录每个问题（启发式 + 描述 + 位置）
4. 评严重程度（0~4）
5. 提建议修复
6. 整理 P0/P1/P2 优先级
7. 输出评审报告
8. 转交项目经理排修复任务

质量自检

□ 是否覆盖了所有 10 条启发式
□ 每个问题是否有具体位置（不是"整体感觉"）
□ 严重程度是否客观评估
□ 修复建议是否可执行（不是"加强体验"）
□ 是否有优先级分级
□ 整体评估是否给出

常见坑

1. 只评审视觉——忽略交互和流程
2. 严重程度过松——所有问题都是"小问题"
3. 只列问题不给方案——开发不知道怎么改
4. 评审后不跟进——报告写完就放着
5. 闭门评审——不结合用户实际数据
6. 个人偏好——把"我不喜欢"当成可用性问题
7. 不分优先级——20 个问题平铺，开发不知道先改哪个

配套模板

• templates/usability-review-template.md — 启发式评审表 + 严重度评分指南

与其他 skill 的协作

上游：
  完成的设计稿（来自其他 skills）

平行：
  accessibility → 可访问性是评审的一部分

下游：
  转交项目经理 → 排修复任务
  转交对应改进 skill（page-structure / component-states / ...）