可用性测试观察
从测试过程记录里提炼卡点、误解与情绪反应
用这个方法分析
上传录音或转写文本即可，未登录会先引导登录
产出长什么样
示例下面是一段虚构场景的示例产出，用来说明形态。真实分析会锚定你自己录音里的原话。
可用性测试观察：某在线协作工具针对新团队管理者的可用性测试 测试场景：3位新管理者在模拟环境中尝试创建项目并邀请团队成员，单次时长约40分钟。
任务卡点清单（示例）
| 事项 | 责任人 | 时限 | 状态 | 备注 |
|---|---|---|---|---|
| “创建项目”按钮位置不直观，测试者普遍在二级菜单中寻找。 | UI设计师 | 2024-05-30 | 待优化 | 原话：“我以为会在‘团队设置’里，没想到在‘工作台’右上角。” |
| 邀请成员时，对“项目成员”与“团队成员”角色区分混淆。 | 产品经理 | 2024-05-30 | 待优化 | 原话：“加了人进来，但不知道谁能改文件。” |
| 协作文档的“分享”按钮点击后，对分享对象的权限设置过程缺乏明确指引。 | 交互设计师 | 2024-06-07 | 待评审 | 原话：“点分享就弹窗了，但没告诉我生成的链接谁能看到、能干嘛。” |
| 导出文件按钮点击后，无明确的成功反馈或下载提示。 | 测试/开发 | 2024-05-23 | 已修复 | 原文无依据/推断：测试者B长时间凝视页面后尝试二次点击，可推断其感到困惑，但缺乏用户口头明确表达其“不确定是否成功”的负面情绪确认。 |
观察分析（覆盖输出模块）
心智模型与产品模型冲突：测试者预期团队权限管理是一个“自上而下”的统一分配过程（心智模型），但产品将其拆散在“创建项目”、“邀请成员”等独立流程中（产品模型），导致用户反复确认与误操作。
情绪反应点：在“权限混淆”与“导出无反馈”处，可观察到明显挫败感（叹气、重复操作）。测试者A在权限设置失败后表示：“这里步骤太多了，我只是想加个人进来一起写东西。”
修复优先级结论：基于“多人遇阻”和“中断核心任务流”原则，建议将“角色区分指引”与“操作反馈”列为高优先级修复项。支撑原话：“这里没有看到‘保存成功’的提示，我不确定刚才的操作到底生效没有。”（测试者C）
什么时候用它
用在访谈这类录音上。当内容里出现下面这些信号时，它最派得上用场：
可用性测试试用陪跑
输出的 4 个模块
产出形态是清单台账，不是一段分析文字——有形态才能沉淀、才能被下游用。
- 1任务卡点清单
- 2用户的心智模型与产品模型冲突
- 3情绪反应点
- 4修复优先级
它怎么保证不瞎说
亲证锚定
证据不足时它会说「本场没有可供分析的对象，缺的是什么」，而不是编一个结论—— 这是硬要求，不是客套话。
常见问题
- 可用性测试观察适合分析什么样的录音？
- 适用于访谈。典型触发信号：可用性测试、试用陪跑。一场录音即可。
- 用可用性测试观察会拿到什么？
- 产出形态是清单台账，包含 4 个模块：任务卡点清单、用户的心智模型与产品模型冲突、情绪反应点、修复优先级。
- 可用性测试观察不做什么？
- 不得把单一用户的说法当成群体结论