可用性测试做得快，不等于任务真的完成了

测试结束后，汇总表显示用户完成得更快，团队很容易把它当作改版成功的证据。但如果用户只是误以为已经提交，或在错误页面提前停下，较短时间并没有解决原来的任务。读者的自信、系统记录的结果和计时器上的数字，需要分开保存。

GOV.UK 的可用性基准测试指南要求逐任务记录是否成功完成、耗时，以及放弃或误以为成功的情况，还建议了解参与者对难度和答案正确性的感受。这些记录回答不同问题：耗时描述过程长度，成功状态描述是否达到判据，主观反馈描述参与者怎样理解这段经历。

设计任务时，可以先写明能够核对的完成条件。例如研究目标若是“找到某项服务的申请截止日期”，完成条件应对应正确日期及其依据，而不只是到达某个页面。这个例子仅用于说明研究设计，本文没有招募参与者，也没有采集测试数据。清楚的判据能让观察者在结果不符合预期时说明原因。

记录表可以让事实先行：参与者最后停在哪里、提供了什么答案、是否自行宣布完成。随后再填写研究者依据判据作出的结果分类。若两者不一致，就保留这项差异，而不是为了让统计整齐，将“我完成了”直接归入成功。视频或点击路径只在实际取得且符合研究授权的前提下使用，不能补造过程。

分析时，较短的完成时间应和成功、失败、放弃等状态放在一起阅读。某一组耗时下降，可以提出进一步核对的假设，却不足以单独证明服务更好用。指南也强调查找失败原因，并将观察与网站分析数据相互比较。团队需要说明证据支持到哪一步，而不是先选一个漂亮数字再寻找解释。

重复测试还涉及可比性。官方建议尽量保持任务和问题一致，同时记录内容及用户行为的变化。如果第二轮换了任务、设备或参与条件，报告应将这些变化写出来，不能假设两轮结果天然等价。本文没有规定通用的样本量或效率门槛。

对用户体验设计而言，最有用的基准记录不只是一个平均秒数，而是一组能被重新解释的任务证据。它让团队发现：用户是真的到达了目标，还是在错误的理解里很快结束。两种情况在页面上可能只差一句提示，在研究记录里却应始终有清楚区分。