一名参与者点击“开始导出”，看到绿色提示后说“完成了”，还给任务难度打了最低分。后台却没有生成文件：他只保存了导出配置，没有执行最终任务。如果研究只在结束后问“是否顺利完成”，这次静默失败会被记录成一次轻松成功。
可用性测试后的问卷只能测参与者如何理解和评价刚才的经历，不能代替客观任务判定。一个可发布的结论应把四层证据分开：用户是否达到预设结果、过程中做了什么、本人认为发生了什么、本人感受如何。四层一致时结论较简单；互相冲突时，往往正是最值得修复的问题。
“好不好用”至少包含结果、投入和感受
NIST 将可用性测试描述为让代表性用户在代表性任务和现实条件下操作，并结合有效性、效率与满意度观察。三者不能互相替代：
| 层次 | 要回答的问题 | 常见证据 |
|---|---|---|
| 有效性 | 用户是否得到正确、完整的任务结果 | 系统状态、产物、成功/部分/失败 |
| 效率 | 为得到结果付出了多少资源 | 用时、步骤、回退、求助和错误恢复 |
| 主观体验 | 用户认为过程多难、对结果多有信心 | 任务后难度、信心和开放解释 |
视觉喜欢不等于任务可用，完成也不一定轻松。相反，一个人可能绕了很远却最终成功，也可能毫不费力地得到错误结果。总体满意度适合评价长期关系，具体任务可用性则应围绕明确目标；两者的边界可结合产品满意度调查指南理解。
先写任务判定表，再写给参与者的题目
“请探索数据页面并说说感受”无法判定成功。“请把上一季度已完成项目的答卷导出为 CSV，文件中不要包含姓名和手机号，并把文件保存到指定文件夹”才有可核验结果。研究者应在任务卡之外维护一张判定表：
- 起点：已登录项目首页，账户具有导出权限；
- 正确产物：指定日期范围的 CSV 已生成并实际下载；
- 隐私条件：姓名、手机号两列没有进入文件；
- 部分成功：文件生成，但时间范围或匿名字段错误；
- 失败：未生成文件、导错项目，或达到十分钟停止条件；
- 允许行为：可以使用页面内帮助，不可由主持人指出按钮。
参与者看到的任务文本说明目标和合理背景，不透露导航名称或正确路径。GOV.UK 的可用性测试指南同样要求任务和成功标准清楚，并让原型成熟度匹配研究问题。若测试低保真原型，就不能把后端未实现当界面失败；若要验证最终导出安全，则需要接近真实的数据和系统状态。
第一轮8人用于找机制，不用“75%成功”冒充人群比例
虚构案例的第一轮招募8名近期实际导出过调研数据的项目管理员，在其常用电脑上进行主持式测试。研究团队覆盖新手、熟练者，以及使用键盘和屏幕阅读器的参与者。8人中观察到三种机制：
- 有人把“保存导出方案”理解成已开始导出；
- 有人不知道匿名字段设置会沿用上次配置；
- 有人只看到页面视觉提示，没有收到文件生成失败的可访问状态通知。
这轮可以有力地说明“这些失败怎样发生”，却不能因为6人完成就宣布总体成功率为75%。参与者是为覆盖关键经验和设备而定向招募，样本小，主持、追问和任务顺序也可能改变行为。GOV.UK 明确区分以定性洞察为主的可用性研究与引入任务时间、点击等指标的量化测试。探索轮的交付物应是问题机制、证据片段和下一版假设，而不是精确百分比。
第二轮240人验证：新版提高了多少，而不是“大家更喜欢”
团队根据第一轮结果设计新版：把“保存配置”和“开始导出”分成明确步骤，导出前展示字段清单，完成后提供文件状态及错误恢复。随后从符合相同角色、近期有导出需求的人群中招募240人，随机各120人进入旧版 A 与新版 B；设备、任务、测试环境和停止条件保持一致。以下仍为说明性虚构数据：
| 结果 | 旧版 A | 新版 B |
|---|---|---|
| 完全成功 | 82/120（68.3%） | 96/120（80.0%） |
| 部分成功 | 15/120（12.5%） | 12/120（10.0%） |
| 失败 | 23/120（19.2%） | 12/120（10.0%） |
| 成功者完成用时中位数 | 146秒 | 111秒 |
完全成功提高11.7个百分点。用两独立比例的大样本近似计算，差异95%区间约为0.7到22.6个百分点：方向支持新版，但效果大小仍有较大不确定性。不能把上界22.6当承诺，也不能再切十几个小人群寻找显著结果。若样本按账户聚类、加权或重复测量，应采用与设计相符的模型和区间。
用时只在成功者中计算，必须与成功率一起展示。若旧版让许多慢用户直接失败，剩余成功者的时间会被选择机制扭曲；把失败者用时删掉后单看平均数，可能得出错误方向。任务有上限时，应保留达到停止条件的截尾记录，而不是当普通缺失。
新版的隐藏风险：88.3%的人以为成功，真实只有80%
完成任务后，先让参与者回答“你认为文件是否已按要求成功生成并保存”，再由研究记录与文件内容判定。新版 B 的交叉结果如下：
| 本人认为成功 | 本人认为未成功 | 合计 | |
|---|---|---|---|
| 客观成功 | 88 | 8 | 96 |
| 客观未成功 | 18 | 6 | 24 |
| 合计 | 106 | 14 | 120 |
若只用自报，成功率会是106÷120=88.3%，比客观80.0%高8.3个百分点。更严重的是，24名未成功者中18人相信自己成功，占75%。这不是普通“体验低分”，而是静默结果错误：参与者甚至不会主动求助。团队应优先修复结果确认、错误提示和产物核验，而不是因为难度评分不错就发布。
信心不是越高越好。正确且低信心说明反馈不足，错误且高信心则说明界面制造了错误确信。把客观结果与主观信心做交叉表，比把两者平均成可用性总分更能决定设计。
任务后问卷控制在能解释刚才经历的范围内
每个任务完成或停止后立即记录，建议顺序是：
- 研究系统先保存客观状态、用时、错误与求助，避免后续讨论覆盖原记录；
- 参与者自报是否认为完成，并评价完成信心；
- 用一条稳定量表询问这项任务的难易，不随版本改变锚点；
- 开放追问“哪一步最影响你的判断”，要求指出实际事件；
- 全部任务结束后，再问整体体验，避免整体题提前塑造每项评价。
不要在每一步都问“你为什么点击这里”，这会改变自然流程。主持测试可先观察，任务结束再回放关键节点；非主持测试则需要事件日志、页面状态和清晰的异常分类。Digital.gov 的测试模型把任务执行和后续追问作为不同阶段，也要求研究目的具体、任务覆盖研究目的，而不是把“测试整个产品”当计划。
问题严重度由后果和恢复决定，不由提及次数决定
| 等级 | 判断方式 | 案例处理 |
|---|---|---|
| 阻断/关键 | 目标无法完成，或错误结果可能造成重大损失且用户不知情 | 匿名失败却导出个人信息，应阻止发布并立即修复 |
| 严重 | 需要求助或大量回退才能恢复 | 导出停滞且没有恢复入口 |
| 中等 | 可以自行恢复，但增加明显时间或错误风险 | 字段清单需要来回切换确认 |
| 轻微 | 不改变结果，影响理解或流畅度较小 | 次要标签措辞不自然 |
频率仍重要，但一次隐私泄露型静默失败通常比多人提出的按钮颜色偏好优先。每个问题记录受影响任务、用户特征、设备/辅助技术、发生证据、自行恢复、后果和置信程度。迭代后应重跑同一关键任务，验证机制是否消失。
残障参与者测试与标准检查必须并行
W3C 指出，邀请残障用户能发现仅靠一致性检查不易暴露的真实障碍，但一两个人不能代表所有相似残障人群，用户测试也不能替代 WCAG 等标准检查。应根据目标用户覆盖不同辅助技术、熟练度和环境，并清楚报告范围。键盘用户未遇到问题，不等于屏幕阅读、放大、语音输入或认知无障碍全部通过。
研究环境本身也要可参与：任务材料、同意流程、问卷和会议工具都需适配。把辅助技术故障、浏览器问题、原型限制与产品缺陷分开编码，同时保留它们对真实完成的影响。
录屏不是默认权限，观察资料也不是宣传素材
屏幕、声音、面部、文件名和测试账户都可能包含个人或机密数据。GOV.UK 的研究记录指南要求在记录前获得知情同意，只按约定目的使用，安全保存并让团队理解访问边界。研究同意不能自动延伸为把片段用于市场宣传；观察者、转录供应商、保存期限和撤回方式都应提前说明。
问卷派可以承接参与者筛选、任务后的短量表、版本随机分配及开放回答整理；任务如果发生在外部原型或正式产品，研究团队仍需用稳定但最小化的标识连接事件，并核对未返回问卷者。跳转后没有回到问卷不等于任务失败，完成问卷也不证明外部任务成功。
最终发布判断应回到预设门槛：新版是否提高关键任务成功、是否消除静默失败、是否没有制造新的无障碍或隐私风险，以及差异的不确定性是否足以支持当前决策。可用性测试的价值不是收集一句“挺好用”，而是证明特定用户在特定条件下能得到正确结果，并知道自己得到了正确结果。