用途
该技能用于规划并执行针对现有设计或原型的可用性测试，目标是在用户于生产环境中遇到问题之前发现可用性问题。它不绑定特定技术栈或工具。
该技能面向测试现有设计或原型。若需更广泛的探索性研究，应使用 ux-research；若需生产环境中的转化测试，应使用 cro-optimization。
适用时机
- 新流程或重大改版上线前
- 改版后验证是否引入新问题
- 分析显示流失但原因不明时
- 客服工单集中在特定界面区域时
- 上线前用户验证
- 比较两个设计方向
不适用时机
- 探索性/生成性研究（使用 ux-research）
- 实时转化优化（使用 cro-optimization）
- 绘制更广泛体验地图（使用 journey-mapping）
- 纯定量测量（使用 analytics-strategy）
所需输入
- 待测试的设计或原型（可用或接近可用）
- 用户会执行的具体任务
- 目标受众（应测试谁）
- 测试基础设施（有主持工具、无主持工具或线下设置）
五阶段框架
1. 定义测试内容
不要测试整个产品，而是测试具体任务。
任务选择标准：
- 任务代表真实用户目标（不是“随便点点看看”）
- 任务有明确起点和终点
- 任务可在 2 到 10 分钟内完成
- 任务属于：最常见、最具战略性或最有问题之一
可测试任务示例：
- “你想找一个附近能安装围栏的承包商。请在这个网站上演示你会怎么做。”
- “你是首次访问者。你想了解这个产品是否适合你的需求。请带我走一遍你会如何评估它。”
- “你的团队需要一个新的项目管理工具。请用这个网站判断哪个方案适合 12 人团队。”
任务表述规则：
- 陈述用户目标，而非系统操作（“找一个住处”而不是“点击搜索按钮”）
- 提供背景（你为什么做这件事？）
- 不要透露路径
- 任务表述中不要使用产品术语
2. 选择有主持或无主持
有主持（实时，有研究员）：
- 研究员实时观察并追问
- 最适合早期原型、复杂任务、新颖概念
- 成本较高，样本较小（通常 5 到 8 名参与者）
- 能捕捉意外并深入追问
无主持（录制，异步）：
- 参与者独自完成，通常通过工具（UserTesting、Maze、Lookback）
- 最适合稳定设计、简单任务、较大样本
- 成本较低，样本较大（通常 15 到 30 名参与者）
- 能在大规模上捕捉模式，但每次会话深度较浅
对多数团队：早期/关键决策用有主持，持续验证用无主持。
3. 招募
目标受众——不只是便利样本。
招募标准：
- 匹配真实用户（目标受众，而不只是“任何人”）
- 混合产品经验水平（如适用，包含新用户和现有用户）
- 混合相关设备类型（如相关，包含移动端、桌面端、平板）
- 排除朋友、家人、员工
样本量：
- 有主持：5 到 8 名参与者（Nielsen 的“5 名用户发现 85% 可用性问题”适用于最常见细分）
- 无主持：15 到 30 名参与者（更多参与者弥补追问不足）
- 多细分测试：每个细分 5 到 8 名
4. 执行测试
任务前准备：
- 确认录制正常
- 向参与者说明（目的、匿名、录制、“没有错误答案”）
- 获得口头同意
- 远程时让参与者共享屏幕
有主持会话结构：
- 暖场（2 到 3 分钟）。简单问题让参与者放松。
- 测试前问题（3 到 5 分钟）。背景信息、当前使用类似产品的行为。
- 任务 1（5 到 10 分钟）。描述任务。让参与者边尝试边出声思考。
- 任务后问题（1 到 2 分钟）。什么容易/困难？有什么困惑？
- 对任务 2、3、4 重复（60 分钟会话通常 3 到 5 个任务）。
- 总体复盘（5 到 10 分钟）。总体反应、与替代方案比较、其他内容。
- 结束（2 分钟）。
主持原则：
- 鼓励出声思考（“你脑子里在想什么？”）
- 除非真的卡住，否则不要帮忙（即使帮忙，也要在长时间停顿之后）
- 不要引导（“你在找菜单吗？”——不好）
- 记录他们犹豫、滚动或回退的地方
- 记录他们的语言与产品语言的差异
- 记录情绪反应
反模式：
- 说得太多（研究员大概只应占 20% 的说话时间）
- 参与者遇到困难时为设计辩护
- 过早帮忙
- 让参与者预测未来行为
- 把参与者建议当作功能（“用户想要 X”——应单独测试对 X 的需求）
5. 综合并报告
跨参与者的模式是信号。单个参与者的抱怨较弱（但值得调查）。
综合步骤：
- 问题清单。每个观察到的问题，记录哪位参与者、哪个任务、严重程度。
- 聚类。同一根因的问题归为一类。
- 严重程度。
- 严重：阻碍任务完成。多数用户遇到。
- 主要：显著拖慢任务。许多用户遇到。
- 次要：摩擦。部分用户遇到。存在变通方法。
- 外观：打磨。不影响任务。
- 建议。针对每个问题提出具体修复方案。
- 优先级。按严重程度和投入排序。
报告结构：
可用性测试：[设计/流程]
摘要
[2 到 3 段，涵盖：测试了什么、主要发现、前 3 项优先事项]
方法
[有主持/无主持、样本量、受众、日期、任务]
严重发现
[每项包含描述、频率、支持证据（引语/片段）、建议。未获得证据处，按数据可用性规则说明缺口]
主要发现
[相同结构]
次要发现
[简要]
外观发现
[最简要]
哪些做得好
[校准：也记录成功之处]
建议
[按优先级排序的列表，含投入估算]
下一步
[重测计划、设计迭代计划]
工作流
- 定义目标。哪些决策取决于此？哪些任务最重要？
- 设计任务。3 到 5 个具体、真实、以目标表述的任务。
- 选择有主持或无主持。匹配阶段和所需深度。
- 招募。针对特定受众。
- 试点。正式批次前 1 到 2 次会话。必要时优化任务。
- 执行。遵循协议。保持纪律。
- 边做边综合，而不只是事后。模式通常在第 4 或第 5 次会话时出现。
- 报告。多种形式——书面报告 + 亮点片段。
- 跟踪修复。每个严重问题都应有负责人和日期。
- 修复后重测。验证修复有效，未引入新问题。
失败模式
- 测试整个产品而非具体任务。结果模糊。
- 任务透露路径。（“点击菜单并找到……”）
- 朋友和家人作为参与者。有偏差，不具代表性。
- 研究员引导参与者。发现反映的是研究员。
- 参与者遇到困难时为设计辩护。错过真实问题。
- 帮忙太快。参与者没有体验到摩擦。
- 把参与者建议当作功能。用户解决自己的问题；产品团队设计解决方案。
- 一个参与者 = 一个数据点。单个强烈意见不是发现。
- 跳过严重程度评分。所有发现被同等对待；团队无法排优先级。
- 没人读的报告。亮点片段和现场走查比 80 页幻灯片更有效。
- 只测试一次，从不重测。引入新问题的修复未被发现。
输出格式
默认输出：
- 测试计划（测试前）——usability-test-plan-[topic].md
- 任务脚本（每次会话）——usability-tasks-[topic].md
- 发现报告（综合后）——usability-findings-[topic].md
- 亮点片段（单独制作）
如果所需数据不可用
该技能的输出依赖于它自身无法生成的数据、测量或工具结果。当所需输入、工具或数据源不可用或无法验证时，被认可的产出是说明缺口的交付物：需要什么、实际获得或验证了什么、输出的哪些部分受影响。为完成交付物而捏造、估算或插值所需数字绝不被认可。说明缺口本身就是完整答案。
参考文件
- references/task-script-patterns.md——按常见产品类型划分的任务表述模式，含好与坏的示例。