usability-testing

可用性测试

在用户于生产环境中遇到问题之前，规划并开展测试以发现可用性问题。与技术栈无关，与工具无关。

此技能用于测试现有设计或原型。如需开展更广泛的探索性研究，请使用 ux-research。如需在生产环境中进行转化测试，请使用 cro-optimization。

---

适用场景

• 发布新流程或重大改版之前
• 改版之后，验证是否引入了新问题
• 分析数据显示用户流失，但你不知道原因
• 客户支持工单集中反映某些特定 UI 区域的问题
• 发布前的用户验证
• 比较两个设计方向

不适用场景

• 探索性 / 生成式研究（使用 ux-research）
• 实时转化率优化（使用 cro-optimization）
• 梳理更广泛的体验（使用 journey-mapping）
• 纯定量测量（使用 analytics-strategy）

---

所需输入

• 要测试的设计或原型（可运行或接近可运行）
• 用户会执行的具体任务
• 目标受众（应测试哪些人）
• 测试基础设施（主持式工具、无主持式工具、现场设置）

---

框架：5 个阶段

1. 定义测试内容

不要测试整个产品。测试具体任务。

任务选择标准：

• 任务代表真实的用户目标（而不是“随便点击浏览”）
• 任务有明确的起点和终点
• 任务可在 2 到 10 分钟内完成
• 任务属于以下类型之一：最常见、最具战略意义或问题最多

可测试任务示例：

“你想找一位附近可以安装围栏的承包商。请演示你会如何在这个网站上完成这件事。”

“你是第一次访问此网站。你想了解这款产品是否符合你的需求。请带我看看你会如何评估它。”

“你的团队需要一款新的项目管理工具。请使用这个网站，判断哪种方案适合 12 人团队。”

任务描述规则：

• 描述用户目标，而不是系统操作（“找一个住宿地点”，而不是“点击搜索按钮”）
• 提供背景（你为什么要做这件事？）
• 不要透露操作路径
• 描述任务时不要使用产品术语

2. 选择主持式或无主持式测试

主持式（实时，由研究人员主持）：

• 研究人员实时观察并追问
• 最适合早期原型、复杂任务、新颖概念
• 成本较高，样本较小（通常为 5 到 8 名参与者）
• 能发现意外情况并深入追问

无主持式（录制、异步进行）：

• 参与者独立完成，通常借助工具（UserTesting、Maze、Lookback）
• 最适合稳定的设计、简单任务和较大样本
• 成本较低，样本较大（通常为 15 到 30 名参与者）
• 能大规模发现规律，但每次测试的深度较浅

对大多数团队而言：早期或关键决策采用主持式测试，持续验证采用无主持式测试。

3. 招募参与者

目标受众——不要只图方便。

招募标准：

• 符合真实用户特征（目标受众，而不是“任何人”）
• 覆盖不同的产品使用经验（适用时包括新用户和现有用户）
• 覆盖相关设备类型（适用时包括移动设备、桌面设备和平板电脑）
• 排除朋友、家人和员工

样本量：

• 主持式：5 到 8 名参与者（Nielsen 的“5 名用户能发现 85% 的可用性问题”适用于最常见的用户群体）
• 无主持式：15 到 30 名参与者（通过增加参与者来弥补追问机会较少）
• 多群体测试：每个群体 5 到 8 名参与者

4. 进行测试

测试前准备：

• 确认录制功能正常
• 向参与者简要说明（目的、匿名性、录制情况、“没有错误答案”）
• 获得口头同意
• 如果是远程测试，让参与者共享屏幕

主持式测试流程：

1. 热身（2 到 3 分钟）。提出简单的问题，让参与者放松下来。
2. 测试前问题（3 到 5 分钟）。了解背景情况，以及他们目前使用类似产品的方式。
3. 任务 1（5 到 10 分钟）。描述任务。让参与者边尝试边说出自己的想法。
4. 任务后问题（1 到 2 分钟）。哪些地方容易或困难？有没有令人困惑的地方？
5. 对任务 2、3、4 重复上述流程（每场 60 分钟的测试通常包含 3 到 5 个任务）。
6. 整体总结（5 到 10 分钟）。了解总体反应、与其他方案的比较，以及其他想法。
7. 结束（2 分钟）。

主持原则：

• 鼓励参与者边做边说（“你现在在想什么？”）
• 除非他们真的卡住，否则不要帮忙（即使要帮，也要等他们长时间停顿后再说）
• 不要引导（“你是在找菜单吗？”——这是不好的做法）
• 记录他们犹豫、滚动页面或返回上一步的地方
• 记录他们使用的说法与产品中的用语有何不同
• 记录他们的情绪反应

反模式：

• 说得太多（研究人员说话的时间可能应占 20%）
• 参与者遇到困难时为设计辩解
• 过早提供帮助
• 让参与者预测自己未来的行为
• 将参与者的建议直接当作功能（“用户想要 X”——应单独测试对 X 的需求）

5. 综合分析并撰写报告

多个参与者之间的共同模式是有效信号。单个参与者的抱怨说服力较弱（但值得调查）。

综合分析步骤：

1. 问题清单。 列出观察到的每个问题，以及涉及的参与者、任务和严重程度。
2. 归类。 将根源相同的问题归为一类。
3. 严重程度。
   • 严重： 阻碍任务完成。大多数用户都会遇到。
   • 重大： 显著拖慢任务。许多用户都会遇到。
   • 轻微： 造成不便。部分用户会遇到。存在变通方法。
   • 表面问题： 仅需润色。不影响任务。
4. 改进建议。 为每个问题提出具体的修复方案。
5. 确定优先级。 根据严重程度和工作量排序。

报告结构：

# Usability Test: [Design / flow]

## Summary
[2 to 3 paragraphs covering: what was tested, headline findings, top 3 priorities]

## Method
[Moderated/unmoderated, sample size, audience, dates, tasks]

## Critical findings
[Each with description, frequency, supporting evidence (quotes/clips), recommendation. Where evidence was not obtained, state the gap per the data-availability rule]

## Major findings
[Same structure]

## Minor findings
[Brief]

## Cosmetic findings
[Briefest]

## What worked well
[Calibration: capture successes too]

## Recommendations
[Prioritized list with effort estimates]

## Next steps
[Test re-run schedule, design iteration plan]

---

工作流程

1. 明确目标。 哪些决策取决于这项测试？哪些任务最重要？
2. 设计任务。 设计 3 到 5 个具体、真实且以目标为导向的任务。
3. 选择主持式或非主持式测试。 根据所处阶段和所需深度进行选择。
4. 招募参与者。 根据目标受众招募。
5. 试运行。 在正式测试前进行 1 到 2 场测试。如有需要，完善任务。
6. 开展测试。 遵循测试流程。严格执行。
7. 边测试边综合分析，而非只在结束后分析。 到第 4 或第 5 场时，模式就会逐渐显现。
8. 撰写报告。 提供多种形式——书面报告和重点片段。
9. 跟踪修复进度。 每个严重问题都应有负责人和日期。
10. 修复后重新测试。 确认修复有效，且没有引入新问题。

---

失败模式

• 测试整个产品，而不是具体任务。 结果模糊。
• 任务揭示了解决路径。（“点击菜单并找到……”）
• 让亲友担任参与者。 结果有偏差，也不具代表性。
• 研究人员引导参与者。 发现反映的是研究人员的想法。
• 参与者遇到困难时为设计辩解。 无法发现真正的问题。
• 过快提供帮助。 参与者无法体验到实际阻碍。
• 将参与者的建议直接当作功能。 用户负责解决自己的问题；产品团队负责设计解决方案。
• 把一位参与者当作一个数据点。 单个强烈观点不构成发现。
• 跳过严重程度评估。 所有发现都被同等对待，团队无法确定优先级。
• 没人看的报告。 与长达 80 页的幻灯片相比，重点片段和现场讲解效果更好。
• 只测试一次，从不复测。 修复引发的新问题会被忽略。

---

输出格式

默认输出：

1. 测试计划（测试前）- usability-test-plan-[topic].md
2. 任务脚本（每场测试）- usability-tasks-[topic].md
3. 发现报告（综合分析后）- usability-findings-[topic].md
4. 精彩片段（单独制作）

---

如果所需数据不可用

此技能的输出依赖于其无法自行生成的数据、测量结果或工具结果。如果所需的输入、工具或数据源不可用或无法验证，经认可的输出是说明缺口的交付内容：需要什么、实际获取或验证了什么，以及输出的哪些部分受到影响。绝不能通过编造、估算或插值来补全所需数值。说明缺口即为完整答复。

---

参考文件

• references/task-script-patterns.md - 常见产品类型的任务设计模式，包含正例和反例。