Agent-almanac review-ux-ui

install
source · Clone the upstream repo
git clone https://github.com/pjt222/agent-almanac
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/zh-CN/skills/review-ux-ui" ~/.claude/skills/pjt222-agent-almanac-review-ux-ui-375057 && rm -rf "$T"
manifest: i18n/zh-CN/skills/review-ux-ui/SKILL.md
source content

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