2、测试目标设定：如何定义测试目标、从用户需求出发设定目标、目标与KPI的关联
好，咱们直接进入正题。测试目标这事儿，看着简单，其实特别容易翻车。我见过太多团队，一上来就急着找用户、搭设备、录屏幕，结果测完了一堆数据，回头一看——咦？我们到底想验证什么来着？
说白了，没有目标的测试，就像没有地图的旅行。你走得再远，也不知道自己到没到。
2.1 为什么测试目标这么重要？
我个人的习惯是，在启动任何一轮可用性测试之前，先花半小时把目标写下来。别小看这半小时，它能帮你省下后面好几天的返工时间。
测试目标决定了三件事：
- 测什么——是测首页的转化路径，还是测设置页面的可发现性？
- 怎么测——是用任务式测试，还是自由探索？
- 结果怎么用——是拿来改Bug，还是用来说服老板改方向？
我在项目中遇到过一种情况：产品经理说“我们测一下这个新功能好不好用”。结果测完之后，有人觉得“好用”是指操作快，有人觉得是“第一次用就能找到”，还有人觉得是“不出错”。你看，同一个词，大家的理解完全不一样。
2.2 如何定义测试目标？
定义测试目标，我一般用三个维度来拆解。你想想看，一个目标如果说不清楚这三个问题，那它大概率还不够清晰。
| 维度 | 问题 | 示例 |
|---|---|---|
| 行为维度 | 用户应该能完成什么操作？ | 用户能在3步内完成注册 |
| 认知维度 | 用户应该理解什么信息？ | 用户能理解“高级设置”的含义 |
| 情感维度 | 用户应该有什么感受？ | 用户觉得操作过程是轻松的 |
举个例子。假设我们要测试一个“在线文档协作功能”。一个模糊的目标是：“看看协作用户体验好不好”。
但如果我们用三个维度来拆解，就会变成：
- 行为维度：用户能否在5秒内找到“邀请协作者”按钮？
- 认知维度：用户是否理解“只读”和“可编辑”权限的区别？
- 情感维度：用户在多人同时编辑时，是否感到焦虑或困惑？
你看，这样一拆，测试任务就变得可执行了。每个维度都能对应到具体的测试任务和观察指标。
2.3 从用户需求出发设定目标
这一点特别关键。很多团队定目标时，是从“我们想验证什么”出发，而不是从“用户需要什么”出发。说白了，就是自嗨。
我记得有一次，一个团队想测试他们的“智能推荐算法”。他们的目标是“看看推荐准确率能不能达到80%”。但实际测试时，用户根本不关心准确率，他们关心的是“推荐的内容是不是我感兴趣的”。这两个目标看起来很像，但测试方法完全不同。
从用户需求出发设定目标，我建议分三步走：
- 先搞清楚用户的核心任务——用户打开这个页面，到底想干什么？
- 再找到任务的痛点——用户在这个任务中，最容易在哪里卡住？
- 最后把痛点转化为测试目标——比如“用户能否在10秒内找到搜索入口”。
举个例子。假设我们做一个“在线课程购买”的页面。用户的核心任务是“找到想学的课并完成购买”。那痛点可能是什么？
- 课程太多，筛选功能不好用
- 支付流程太复杂
- 购买后找不到课程入口
那我们的测试目标就可以设定为：
- 用户能否在30秒内通过筛选找到目标课程？
- 用户能否在2分钟内完成支付？
- 用户购买后，能否在10秒内找到“开始学习”的入口？
你看，每个目标都直接对应了用户的真实痛点。这样的测试结果，产品经理看了也会觉得“嗯，确实该改”。
2.4 目标与KPI的关联
好，目标定好了，怎么跟KPI挂钩？这个问题很多初级设计师会忽略。但说实话，如果你想让测试结果真正影响产品决策，就必须把测试目标翻译成业务语言。
我个人的做法是，把测试目标映射到三个层级的KPI上：
| 层级 | KPI类型 | 示例 | 对应的测试目标 |
|---|---|---|---|
| 行为层 | 任务完成率、任务时间 | 注册转化率提升10% | 用户能否在3步内完成注册 |
| 认知层 | 首次点击正确率、错误率 | 用户操作错误率降低20% | 用户是否理解“确认支付”按钮的位置 |
| 情感层 | 满意度评分、NPS | 用户满意度提升15% | 用户是否觉得操作过程是轻松的 |
为什么会这样？因为业务方关心的永远是“这个改动能不能带来数据提升”。如果你只告诉他们“用户觉得按钮不好找”，他们可能不会重视。但如果你说“这个按钮的首次点击正确率只有40%，预计优化后能提升到70%，对应注册转化率能提升8%”，那他们就会认真对待。
举个例子。有一次我们测试一个“购物车页面”，发现很多用户在“修改数量”这个操作上卡住了。测试目标是“用户能否在5秒内完成数量修改”。测试结果是：只有30%的用户能在5秒内完成，平均耗时12秒。
我们把这个结果跟业务KPI关联起来：
- 当前购物车放弃率是45%
- 我们估算，如果修改数量的操作时间从12秒降到5秒，放弃率能降低5-8%
- 对应的GMV（商品交易总额）提升大约是每月XX万
你看，这样一关联，产品经理和老板都坐不住了。第二天就排期改了。
2.5 一个完整的例子
好，说了这么多，咱们看一个完整的例子。假设我们要测试一个“在线预约挂号”的小程序。
第一步：从用户需求出发
用户的核心任务是“快速找到合适的医生并完成预约”。痛点可能是：
- 科室分类太复杂，找不到对应的科室
- 医生排班信息不清晰
- 预约确认流程太繁琐
第二步：定义测试目标
- 行为目标：用户能否在1分钟内完成从“打开小程序”到“提交预约”的全流程？
- 认知目标：用户是否理解“专家号”和“普通号”的区别？
- 情感目标：用户在预约过程中是否感到焦虑（比如担心约错时间）？
第三步：关联KPI
| 测试目标 | 测试指标 | 关联KPI |
|---|---|---|
| 1分钟内完成预约 | 任务完成率、平均耗时 | 预约转化率 |
| 理解号源区别 | 选择正确率 | 退号率、投诉率 |
| 预约过程不焦虑 | 满意度评分、面部表情分析 | 用户留存率、NPS |
你看，这样一套下来，测试目标清晰、可执行、可量化，而且跟业务方也能对上话。我个人觉得，这才是可用性测试该有的样子——不是自娱自乐，而是真正推动产品优化。