可用性测试与迭代师
五个用户就能暴露大部分严重问题。真正贵的是不做测试就直接上线。
一、这个技能解决什么问题
上线后才发现用户找不到核心功能，改起来牵一发动全身。
测试做成演示，只让用户看顺利路径，问题被礼貌地掩盖过去。
测试结论停留在「用户觉得还行」，没有具体问题与频次数据。
二、触发条件
- 需要在开发前验证设计方案的可用性
- 需要在多个方案之间做选择
- 需要为迭代提供问题优先级依据
三、执行顺序
- 读取
references/methodology.md，取本环节的标准字段与常量表。 - 定义测试目标：明确要验证哪些假设与哪些任务，一次测试聚焦 3-5 个任务。
- 拟定任务脚本：用场景化描述而非操作指令，避免提示用户界面上的具体按钮。
- 招募代表性用户：覆盖主要画像与能力下限用户，样本量 5 人即可发现大部分严重问题。
- 执行与记录：观察用户行为而非询问意见，记录完成情况、耗时、求助次数与困惑点。
- 归类与排期：按问题频次与严重度归类，转成迭代清单并标注修复优先级。
四、输入闸门
| 输入项 | 说明 | 缺失处理 |
|---|---|---|
| 测试目标 | 必须明确要验证的假设 | 缺失 → 测试无结论价值 |
| 任务脚本 | 不得包含界面操作提示 | 含提示 → 测试结果无效 |
| 行为记录 | 必须记录行为指标而非仅意见 | 仅有意见 → 结论不可用于决策 |
五、核心方法
任务脚本写法
差：点击右上角设置按钮，找到通知开关。
好：你不想再收到这类提醒了，请处理一下。
场景化描述让用户自己寻找路径，才能真正暴露导航与命名问题。任务脚本一旦提到具体按钮名称，测试就变成了可用性演示。
每个任务都要准备成功判定标准，否则无法统计完成率。
行为指标
| 指标 | 记录方式 | 用途 |
|---|---|---|
| 任务完成率 | 完成人数 / 总人数 | 判断任务是否可用 |
| 完成耗时 | 从开始到完成秒数 | 判断效率，与预估步数对照 |
| 求助次数 | 需要主持人提示的次数 | 判断可发现性 |
| 错误次数 | 走错路径或误操作的次数 | 定位设计缺陷 |
| 困惑点 | 停顿超过 5 秒的位置 | 定位信息架构问题 |
问题归类与排期
按两轴分：出现频次（多数人遇到 / 少数人遇到）与严重度（阻碍完成 / 增加难度 / 仅困扰）。
高频繁且阻碍完成的立即修复；高频但仅困扰的排入近期迭代；低频且阻碍完成的分析是否与特定画像相关；低频低影响的记录观察。
每个问题要附证据（第几位用户在哪一步遇到），没有证据的问题不应进入排期。
六、交付物清单
- 测试目标与假设清单
- 任务脚本与成功判定标准
- 参与者画像与样本说明
- 行为指标记录表
- 问题归类与迭代排期清单
七、使用边界
- 不替代大规模定量调研，本技能聚焦小样本定性发现。
- 不诱导用户给出评价，只观察真实行为。
- 测试结论须有行为证据，无证据的推断不进入排期。
淘宝店：AI灵匣 — 全套 AI 工作流技能包供应商
