可用性测试不是产品上线前的形式化流程，而是一种用真实用户行为验证设计假设的方法。它的价值不在于证明产品“没问题”，而在于尽早暴露“用户卡在哪里”。下面这套思路适用于官网、后台系统、移动应用等大多数数字产品场景。
一、先明确测试要回答的问题
很多团队把测试当成一次性的验收动作，结果拿到一堆零散反馈却无法指导决策。更务实的做法是：在测试前写下三到五个待验证的问题，例如“新用户能否独立完成注册”“价格页的信息是否足以支撑购买决策”。问题越具体，后续的任务设计和结论输出就越有依据。如果团队暂时没有明确假设，可以先做小规模的走查或访谈，找到疑点后再进入正式测试。
二、任务设计决定结论质量
任务应当描述用户的目标，而不是操作步骤。让参与者“把发票寄到公司地址”，比“点击右上角设置，再进入发票管理”更能反映真实使用情况。设计时注意几点：
- 任务基于真实场景，避免为了测试而编造需求；
- 不出现界面上的原词，防止参与者靠搜索关键词蒙混过关；
- 难度分层，既有常规流程，也有边界情况；
- 每个任务预设成功标准，便于后续统计与对比。
任务说明最好提前做一次内部预演，确认表述没有歧义。
三、样本招募：够用就好
可用性测试并不追求大样本。针对同一类用户角色，通常五到八名参与者就能暴露出大部分高频问题；如果产品包含明显不同的用户群，则按角色分组各自取样。招募时应尽量贴近真实用户特征，而不是图省事找同事代劳——同事对产品已有认知，容易高估设计的清晰度。
四、主持与记录：少说多做
主持人的核心原则是不引导。当参与者停顿或提问时，用“你会怎么做”“你期望发生什么”把问题交还给他，而不是直接指路。记录上建议安排专人负责时间轴笔记，标记任务开始、卡点、求助、放弃等节点，并配合录屏留存证据。这样在整理结论时，可以回到具体片段，而不是凭印象争论。
五、把发现转化为改进项
测试结束后的两三天内完成分析，趁记忆还清晰。建议按“问题—影响—证据—建议”的结构整理每条发现，并标注严重程度：阻断流程的问题优先修复，表述不清的问题可以合并处理。把结论同步给设计与研发时，附上录屏片段或原话，比单纯描述更容易达成共识。改进上线后，可以用同样的任务做一次小范围复测，验证问题是否真正解决，形成闭环。
六、几个常见误区
- 把参与者当成被考核对象，导致其紧张、掩饰真实反应；
- 只记录负面反馈，忽略用户顺利完成的部分；
- 测试做完就归档，没有跟进到需求池与版本计划；
- 把一次可用性测试的结论当作普遍规律，跨人群直接套用。
把可用性测试纳入固定的产品节奏，比偶尔做一次大规模测试更有价值。它带来的不只是问题清单，更是团队对真实使用场景的共同理解。