Q3.06.1Prespecified task success criteria设计研究
成功标准需在测试前定义
别名: 任务成功标准 · 预先操作化 · completion criteria
概念解释
任务成功率要把每一次尝试判定为达到或未达到一个可观察的终点。判定规则必须在看到该次结果之前写死：终点状态是什么、允许多少提示、何时记为放弃或超时。事后根据“看起来差不多完成了”再打分，会让成功变成对偏好方案的圆场。成功率回答的是“在既定标准下有多少人到达”，不是“我们是否觉得他们大体上会了”。
机制
成功不是界面上的自然属性，而是研究者加在行为轨迹上的切割。若切割可以在看过录像后移动，评分者会把模糊案例推向自己已经相信的方向：对看好的设计放宽“提交成功”，对对照设计把同一状态算失败。预先写清可观察状态——例如账户已创建且邮箱已验证，而不是“用户理解了流程”——才能让不同评分者打同一批记录时落到同一侧。标准一旦随案例改写，前后场次的成功率就不再是同一指标。
怎么研究
在试点前写出每个任务的成功状态、失败状态、停止规则与是否允许外部帮助。用未参与设计的第二评分者按同一规则盲评若干场次，检查不一致集中在哪些状态。比较版本时锁定同一标准，不因新界面出现了新的“差不多完成”路径而改写旧定义。报告成功率时附上判定规则原文，使读者能判断该数字对应哪一种到达。
边界
探索性测试可以在过程中发现原先没想到的合法完成方式，但那是在修订操作定义，随后的验证场次必须改用新标准并与旧数字分开。安全关键任务的成功有时包含“未采取危险动作”，不能只看是否点到了目标。协作任务的终点可能跨人跨时段，单场测试只能操作化其中一段。无法观察的“理解”不应充当成功标准。
怎么落地
- 每个任务写成“到达哪个界面状态或外部结果算成功”，禁止使用“顺利”“基本完成”这类词。
- 把规则打印进主持人脚本；场中出现争议先按原规则记，会后再讨论是否修订下一轮。
- 改版对比必须沿用同一成功状态；若产品终点变了，新旧成功率分列，不拼成一条趋势。
- 抽查录像：若评分者无法只凭规则、不看方案标签就判定，说明标准仍不可观察。