---

name: review-ux-ui description: > 使用尼尔森启发式原则、WCAG 2.1 无障碍指南、键盘和屏幕阅读器审计、用户流程 分析、认知负荷评估和表单可用性评估来审查用户体验和界面设计。适用于在发布前 进行可用性审查、评估 WCAG 2.1 无障碍合规性、评估用户流程效率、审查表单设计， 或对现有界面进行启发式评估。 locale: zh-CN source_locale: en source_commit: 75ded7a1 fence_basis_commit: 75ded7a1 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Grep Glob WebFetch metadata: author: Philipp Thoss version: "1.0" domain: review complexity: advanced language: multi tags: ux, ui, accessibility, wcag, heuristics, usability, user-flows, cognitive-load

UX/UI 评审

评估用户体验和界面设计的可用性、无障碍性和有效性。

适用场景

• 在应用程序发布前进行可用性审查
• 评估无障碍合规性（WCAG 2.1 AA 或 AAA）
• 评估用户流程的效率和错误预防
• 审查表单设计的可用性和转化优化
• 对现有界面进行启发式评估
• 评估认知负荷和信息架构

输入

• 必填：待审查的应用程序（URL、原型或源代码）
• 必填：目标用户描述（角色、技术熟练度、使用场景）
• 可选：用户研究发现（访谈、调查、分析数据）
• 可选：WCAG 合规目标（A、AA 或 AAA）
• 可选：需要评估的特定用户流程或任务
• 可选：需要测试的辅助技术（屏幕阅读器、开关访问）

步骤

第 1 步：启发式评估（尼尔森十大启发式原则）

对照每条启发式原则评估界面：

#	启发式原则	关键问题	评级
1	系统状态可见性	系统是否始终告知用户正在发生的事情？
2	系统与现实世界的匹配	系统是否使用用户熟悉的语言和概念？
3	用户控制与自由	用户是否可以轻松撤销、重做或退出不想要的状态？
4	一致性与标准	相似的元素是否在整个产品中表现一致？
5	错误预防	设计是否在错误发生前预防错误？
6	识别而非回忆	选项、操作和信息是否可见或易于检索？
7	使用的灵活性与效率	是否为有经验的用户提供了快捷方式而不使新手困惑？
8	美观而极简的设计	每个元素是否都有其目的？是否存在不必要的杂乱？
9	帮助用户识别、诊断和从错误中恢复	错误信息是否清晰、具体且有建设性？
10	帮助与文档	需要时是否有帮助且易于找到？

对每条启发式原则，评定违规严重程度：

严重程度	描述
0	不是可用性问题
1	外观问题——有时间就修复
2	次要——低优先级修复
3	重大——重要，高优先级修复
4	灾难性——发布前必须修复

## 启发式评估发现
| # | 启发式原则 | 严重程度 | 发现 | 位置 |
|---|----------|---------|------|------|
| 1 | 系统状态 | 3 | 数据获取期间无加载指示器——用户多次点击 | 仪表板页面 |
| 3 | 用户控制 | 2 | 删除项目无撤销——只有确认对话框 | 项目列表 |
| 5 | 错误预防 | 3 | 日期字段接受无效日期（2 月 30 日） | 预订表单 |
| 9 | 错误恢复 | 4 | 表单提交错误清空所有字段 | 注册页面 |

预期结果： 全部 10 条启发式原则均已评估，附具体发现和严重程度评级。

失败处理： 若时间有限，重点评估第 1、3、5、9 条（对用户体验影响最大）。

第 2 步：无障碍审计（WCAG 2.1）

可感知性

• 1.1.1 非文本内容：所有图片均有替代文字（装饰性图片 alt=""）
• 1.3.1 信息与关系：使用语义化 HTML（标题、列表、表格、地标）
• 1.3.2 有意义的序列：DOM 顺序与视觉顺序一致
• 1.4.1 色彩的使用：颜色不是传达信息的唯一方式
• 1.4.3 对比度：文字对比度 ≥ 4.5:1（普通），≥ 3:1（大文字）
• 1.4.4 文字缩放：文字可缩放至 200% 且不丢失功能
• 1.4.11 非文本对比度：UI 组件和图形对比度 ≥ 3:1
• 1.4.12 文字间距：内容支持增加文字间距（行高 1.5 倍、字母间距 0.12em、字间距 0.16em）

可操作性

• 2.1.1 键盘：所有功能可通过键盘操作
• 2.1.2 无键盘陷阱：焦点永远不会被困在某个组件中
• 2.4.1 跳过块：键盘用户可使用跳转导航链接
• 2.4.3 焦点顺序：Tab 顺序遵循合理、可预测的序列
• 2.4.7 焦点可见：键盘焦点指示器清晰可见
• 2.4.11 焦点不遮挡：聚焦元素不被固定的标题/悬浮层隐藏
• 2.5.5 目标尺寸：交互目标至少为 24x24px（触控设备建议 44x44px）

可理解性

• 3.1.1 页面语言：<html> 上设置了 lang 属性
• 3.2.1 聚焦：焦点不触发意外变化
• 3.2.2 输入：输入不在没有警告的情况下触发意外变化
• 3.3.1 错误识别：错误以文字形式清晰描述
• 3.3.2 标签或说明：表单输入有可见标签
• 3.3.3 错误建议：错误信息建议如何修复问题

健壮性

• 4.1.1 解析：HTML 有效（无重复 ID，嵌套正确）
• 4.1.2 名称、角色、值：自定义组件有 ARIA 角色和属性
• 4.1.3 状态信息：动态内容变化已向屏幕阅读器宣告

预期结果： WCAG 2.1 AA 标准已系统性检查，每项标准有通过/未通过记录。

失败处理： 使用自动化工具（axe-core、Lighthouse）进行初步扫描，然后手动测试需要人工判断的标准。

第 3 步：键盘和屏幕阅读器审计

键盘导航测试

仅使用 Tab、Shift+Tab、Enter、Space、方向键和 Escape：

## 键盘导航审计
| 任务 | 可完成？ | 问题 |
|------|---------|------|
| 导航到主内容 | 是——跳转链接有效 | 无 |
| 打开下拉菜单 | 是 | 方向键在菜单内不起作用 |
| 提交表单 | 是 | Tab 顺序跳过提交按钮 |
| 关闭模态框 | 否 | Escape 不关闭，Tab 顺序中无可见关闭按钮 |
| 使用日期选择器 | 否 | 自定义日期选择器无法通过键盘访问 |

屏幕阅读器测试

使用 NVDA（Windows）、VoiceOver（macOS/iOS）或 TalkBack（Android）测试：

## 屏幕阅读器审计
| 元素 | 宣告内容 | 预期内容 | 问题 |
|------|---------|---------|------|
| Logo 链接 | "链接, 图片" | "首页, 链接" | Logo 缺少替代文字 |
| 搜索输入框 | "编辑, 搜索" | "搜索产品, 编辑" | 缺少标签关联 |
| 导航菜单 | "导航, 主" | 正确 | 无 |
| 错误信息 | （未宣告） | "错误：邮箱为必填" | 缺少实时区域 |
| 加载动画 | （未宣告） | "加载中，请稍候" | 缺少 aria-live 或 role="status" |

预期结果： 使用纯键盘和屏幕阅读器完成了完整的任务流程测试。

失败处理： 若屏幕阅读器不可用，检查 ARIA 属性和语义化 HTML 作为替代方案。

第 4 步：分析用户流程

映射并评估关键用户流程：

## 用户流程：完成购买

### 步骤
1. 浏览产品 → 2. 查看产品 → 3. 加入购物车 → 4. 查看购物车 →
5. 输入收货地址 → 6. 输入支付信息 → 7. 核对订单 → 8. 确认

### 评估
| 步骤 | 摩擦程度 | 严重程度 | 备注 |
|------|---------|---------|------|
| 1→2 | 低 | - | 产品卡片清晰 |
| 2→3 | 中 | 2 | "加入购物车"按钮在移动端折叠区以下 |
| 3→4 | 低 | - | 购物车图标数量更新 |
| 4→5 | 高 | 3 | 必须注册账户——无访客结账 |
| 5→6 | 低 | - | 地址自动填充效果良好 |
| 6→7 | 中 | 2 | 信用卡号字段不自动格式化 |
| 7→8 | 低 | - | 订单摘要清晰 |

### 流程效率
- **步骤数**：8（电商可接受）
- **必填字段**：14（地址自动填充 + 保存支付方式可减少）
- **决策点**：2（尺寸选择、配送方式）
- **潜在流失点**：步骤 4→5（强制注册）

预期结果： 关键用户流程已映射，摩擦点已识别并评级。

失败处理： 若用户分析数据不可用，根据任务复杂度和步骤数评估流程。

第 5 步：评估认知负荷

• 信息密度：每屏的信息量是否适当？
• 渐进式披露：复杂信息是否逐步展示？
• 分组：相关项目是否在视觉上分组（格式塔原则）？
• 识别而非回忆：用户是否能看到选项而非需要记住？
• 一致的模式：相似的任务是否使用相似的交互模式？
• 决策疲劳：用户是否一次面对过多选择？（席克定律）
• 工作记忆：用户是否需要在步骤间记住信息？

预期结果： 认知负荷已评估，已识别具体的过载或欠载区域。

失败处理： 若认知负荷难以客观评估，使用"眯眼测试"——眯起眼睛看屏幕，判断结构和层次是否仍然清晰。

第 6 步：审查表单可用性

对应用程序中的每个表单：

• 标签：每个输入框都有可见的关联标签
• 占位符文字：仅用于示例，不作为标签
• 输入类型：使用正确的 HTML 输入类型（email、tel、number、date）以适配移动端键盘
• 验证时机：错误在失焦或提交时显示（不是每次按键时）
• 错误信息：具体（"邮箱必须包含 @"）而非笼统（"无效输入"）
• 必填字段：清晰标注（若大多数为必填，则标注可选字段）
• 字段分组：相关字段在视觉上分组（姓名、地址、支付信息章节）
• 自动填充：为标准字段设置 autocomplete 属性（name、email、address、cc-number）
• Tab 顺序：逻辑流程与视觉布局一致
• 多步表单：进度指示器显示当前步骤和总步骤数
• 数据持久化：若用户离开并返回，表单数据保留

预期结果： 每个表单均已对照清单评估，具体问题已记录。

失败处理： 若表单很多，优先处理流量最高的表单（注册、结账、联系方式）。

第 7 步：撰写 UX/UI 评审报告

## UX/UI 评审报告

### 执行摘要
[2-3 句：整体可用性、最关键问题、最强方面]

### 启发式评估摘要
| 启发式原则 | 严重程度 | 关键发现 |
|----------|---------|---------|
[来自第 1 步的摘要表]

### 无障碍合规性
- **目标**：WCAG 2.1 AA
- **状态**：[Y 项中 X 项通过]
- **严重失败**：[列表]

### 用户流程分析
[关键摩擦点及其严重程度和建议]

### 前 5 项改进（按优先级）
1. **[问题]** — 严重程度：[N] — [具体建议]
2. ...

### 做得好的地方
1. [具体的积极观察]
2. ...

预期结果： 评审提供优先级明确、可操作的建议，附严重程度评级。

失败处理： 若评审发现了过多问题，分为"必须修复"（严重程度 3-4）和"应该修复"（严重程度 1-2）。

验证清单

• 全部 10 条尼尔森启发式原则均已评估，附严重程度评级
• WCAG 2.1 标准已检查（至少：1.1.1、1.4.3、2.1.1、2.4.7、3.3.1、4.1.2）
• 键盘导航已针对关键用户流程测试
• 屏幕阅读器已测试（或 ARIA/语义化 HTML 已作为替代方案审查）
• 至少一个关键用户流程已分析摩擦点
• 认知负荷已评估
• 表单可用性已评估
• 发现按严重程度排序，附可操作建议

常见问题

• 混淆 UX 与视觉设计：UX 关乎功能性；视觉设计关乎外观。美丽的界面可能有糟糕的 UX。两者都要评估，但要区分它们。
• 只测试正常路径：错误状态、空状态、加载状态和边缘情况是 UX 问题隐藏的地方。
• 忽视真实设备：浏览器开发者工具的响应式模式只是代替品。真实设备测试能发现触控、性能和视口问题。
• 将无障碍性作为事后考虑：晚期发现的无障碍性问题修复代价高昂。应尽早且持续地评估。
• 将个人偏好当作 UX 反馈："我更喜欢……"不是 UX 反馈。引用启发式原则、研究或已建立的模式。

相关技能

• review-web-design — 视觉设计审查（布局、排版、色彩——对 UX 的补充）
• scaffold-nextjs-app — Next.js 应用程序脚手架
• setup-tailwind-typescript — 设计系统实现的 Tailwind CSS