usability-testing

可用性测试

范围

涵盖

• 设计与特定产品决策相关的基于任务的可用性研究
• 测试线上流程、原型和“伪装”实现（假门、Wizard of Oz）
• 开展主持式测试（远程或线下），并收集高质量证据
• 将发现转化为按优先级排序的修复清单（包括高投资回报率的微文案／CTA 改进）

适用场景

• “为 创建可用性测试计划和脚本。”
• “我们下周要用 5–8 位用户测试一个原型。”
• “在开发前验证价值主张（假门／Wizard of Oz）。”
• “帮我将可用性测试发现整理成按优先级排序的待办事项。”

不适用场景

• 你需要统计上可靠的估算或因果影响（请使用分析／实验）
• 你需要开放式探索（“用户有哪些问题？”）→ 请使用 conducting-user-interviews
• 你正在与高风险人群或敏感主题（医疗、法律、未成年人）打交道，但没有获得适当批准／培训
• 你没有具体的待评估场景／流程（请先明确决策）

输入

最低要求

• 产品 + 目标用户群体（用户是谁、使用情境）
• 本次测试要支持的决策（会有哪些改变）+ 时间线
• 测试内容（流程／功能）+ 原型／构建版本链接（或“推荐测试材料”）
• 平台 + 环境（Web／移动端／桌面端；远程／线下）
• 限制条件：测试形式、参与人数、激励、录制政策、隐私限制

缺失信息处理策略

• 从 references/INTAKE.md 中最多提出 5 个问题。
• 如果仍有未知项，请明确说明假设，并列出会影响计划的待确认问题。

输出（交付物）

以 Markdown 格式提供可用性测试包（在聊天中提供；或按要求提供文件）：

1. 背景概览（决策、用户、测试内容、限制条件）
2. 测试计划（方法、原型策略、假设／风险、成功标准）
3. 参与者计划（筛选标准、招募渠道、日程 + 备用方案）
4. 主持人指南 + 任务脚本（中立的任务、追问、总结）
5. 笔记模板 + 问题日志（严重程度／影响、证据）
6. 综合报告（发现、按优先级排序的问题、建议、快速见效项）
7. 风险／待确认问题／后续步骤（始终包含）

模板：references/TEMPLATES.md
扩展版启发式指南：references/WORKFLOW.md

工作流（8 个步骤）

1) 明确决策及“为何现在进行”

• 输入： 用户背景；references/INTAKE.md。
• 操作： 明确决策、主要未知项，以及做出决策所需掌握的最少信息。
• 输出： 背景概览 + 研究问题／假设。
• 检查： 你能回答：“完成这次测试后，我们会采取哪些不同做法吗？”

2) 选择合适的测试材料（真实产品 vs 原型 vs 伪装实现）

• 输入： 测试内容；限制条件。
• 操作： 选择成本最低且有效的方案：线上产品、可交互原型、假门、Wizard of Oz 或礼宾式流程。
• 输出： 原型策略 + 真实部分与模拟部分的说明。
• 检查： 该方案能够测试核心价值／行为（而非像素级完美度）。

3) 定义任务和成功标准（保持中立）

• 输入： 用户目标 + 场景。
• 操作： 编写 5–8 个真实任务（每个任务都包含一个起始状态）、成功标准和关键观察点（犹豫、错误、变通方式）。
• 输出： 任务清单（草稿）+ 观察计划。
• 检查： 任务不会透露 UI 标签（“点击 X 按钮”）；任务应体现真实意图。

4) 挑选参与者 + 招募计划（包含缓冲）

• 输入： 目标细分群体、接触用户的渠道。
• 操作： 设定纳入／排除标准；选择渠道；制定包含备用安排和缓冲时间的日程，以应对缺席和参与者日程繁忙的情况。
• 输出： 参与者计划 + 招募文案／筛选问卷（视需要提供）。
• 检查： 参与者应符合使用场景（行为／背景），而不只是人口统计特征。

5) 编写主持人指南 + 配置记录工具

• 输入： 任务清单 + 原型。
• 操作： 编写脚本（介绍／同意、热身、任务、追问、总结）。分配记录员职责；确定要记录的内容。
• 输出： 主持人指南 + 笔记模板 + 问题日志。
• 检查： 指南应避免诱导性问题，并包含“接下来你会怎么做？”这类追问。

6) 开展测试并收集证据（可选：“现实情况”核查）

• 输入： 指南、后勤安排、参与者。
• 操作： 开展测试；记录原话、错误、粗略的任务耗时和困惑时刻。也可在实际环境中观察类似流程。
• 输出： 每场测试的完整笔记 + 已填写的问题日志。
• 检查： 每个问题都附有至少一个具体示例（引述／截图／时间／步骤）。

7) 综合分析并确定修复优先级（微小改进也有价值）

• 输入： 笔记 + 问题日志。
• 操作： 将问题归类；标注严重程度和出现频率；关联转化漏斗／业务影响；提出修复方案（包括微文案／CTA 调整）。
• 输出： 综合分析报告 + 排定优先级的建议／待办事项。
• 检查： 每项建议都应关联证据，并说明预期影响（方向性）。

8) 分享、决策并进行质量检查

• 输入： 草稿包。
• 操作： 编写可分享的分析报告，提出后续步骤（设计迭代、后续测试、实验）。运行 references/CHECKLISTS.md 并依据 references/RUBRIC.md 评分。
• 输出： 最终版可用性测试包 + 风险／待解决问题／后续步骤。
• 检查： 利益相关者无需同步沟通，也能做出“发布／修复／重新测试”的决定。

质量检查（必需）

• 使用 references/CHECKLISTS.md 和 references/RUBRIC.md。
• 始终包含：风险、待解决问题、后续步骤。

示例

示例 1（原型测试）：“为我们的全新网页引导流程制定可用性测试计划 + 主持人指南，下周邀请 6 位首次使用的用户参与。”
预期：完整的可用性测试包，包含中立的任务、招募标准、测试安排和综合分析框架。

示例 2（绿野仙踪测试）：“我们想在构建‘AI 自动分流’功能之前先测试一下。请设计一份针对 5 场测试的绿野仙踪可用性测试计划和脚本。”
预期：说明模拟内容的刺激材料计划、聚焦价值的任务，以及问题日志 + 分析报告。

边界示例：“开展可用性测试，证明重新设计会使留存率提高 10%。”
回应：说明小样本可用性测试的局限；建议结合埋点／实验来验证因果关系，并利用可用性测试诊断使用障碍。