可用性测试

可用性测试是一种研究方法，它让真实用户或具有代表性的用户尝试使用产品、原型或网站完成特定任务，同时观察员记录用户成功之处、遇到的困难以及他们如何描述自己的体验，通常是通过让他们边操作边大声思考来记录。与事后报告用户行为或言论的调查或分析不同，可用性测试直接观察用户在实际情境中的行为，因此它是识别界面是否真正易于理解和使用（而非仅仅是开发团队的臆测）的最直接方法之一。

方法至关重要，因为设计者看不到的界面问题，对于初次使用者来说往往显而易见。这种认知差距通常可以用“知识诅咒”来解释：对产品非常熟悉的设计师和利益相关者难以注意到新用户立即遇到的模糊之处。广为引用的可用性研究表明，即使只有五名参与者，测试通常也能发现给定界面中绝大多数（通常约为 85%）的可用性问题。因此，可用性测试通常采用小规模、迭代式的参与者测试，而不是大规模研究。这样，团队就可以快速地进行测试、修复和重新测试，而无需等待收集到大量样本后再进行任何更改。

可用性测试有多种形式：引导式测试，即由一名引导员实时引导参与者完成任务（可以是现场指导或视频指导），并可提出后续问题以澄清疑难之处；非引导式远程测试，即参与者使用测试平台独立完成任务，屏幕和语音会被录制以供后续分析，这种方式数据收集速度更快、成本更低，但缺点是无法即时了解参与者的反应；以及游击式测试，这是一种非正式的低成本方法，可从同事或路人等可接触的参与者那里快速收集反馈，适用于尚不需要进行全面研究的早期验证阶段。测试环节通常围绕具体、实际的任务场景展开，而非开放式探索，其成功与否的评估指标包括任务完成率、任务耗时、错误数量以及参与者对易用性的主观评价，这些评价通常通过系统可用性量表等标准化工具收集。

人们常常误以为可用性测试和A/B测试的目的相同，但实际上它们在不同的阶段回答不同的问题：可用性测试旨在识别用户在使用界面时遇到的困难，通常是在原型或已上线但未经验证的设计上进行测试，而A/B测试则是在实际流量可用后，衡量多个已构建版本中哪个版本在大规模使用中表现更佳。可用性测试本身的一个常见陷阱是招募的参与者不能代表实际目标受众，例如，让不熟悉底层业务流程的参与者测试企业软件工作流程，这会导致测试结果出现误导性的摩擦点，而这些摩擦点在真正的目标用户身上并不会显现。另一个常见的错误是，在测试过程中通过提示或建议引导参与者，而不是让他们自行摸索并如实观察他们的困难，这会削弱测试结果的有效性。

在CRO和 UX 在咨询项目中，可用性测试经常被用于诊断问题，以了解现有流程为何表现不佳，以及在重新设计方案大规模发布前进行验证。可用性测试会邀请一小群具有代表性的用户测试新原型，以便在投入开发和测试资源进行全面的A/B测试之前，发现主要的可用性问题。可用性测试的结果通常会被汇总成一个优先级排序的问题列表，该列表通常按严重程度和遇到每个问题的参与者人数进行排名，然后直接用于设计变更或实验假设，从而构成客户更广泛的优化路线图。

一个具体的例子可以证明该方法的有效性：一个团队用五名参与者测试重新设计的账户设置页面，可能会发现其中四名参与者都找不到更改通知偏好设置的选项，而且每个人都独立地在界面中同一个错误位置寻找。这一单一且高度一致的发现，来自小规模且成本低廉的测试，通常足以作为在正式发布前重新定位该设置的理由，而无需进行更大规模、更耗时的研究来验证几乎每位受测者都反复出现的错误。