一、可用性测试概述

说到可用性测试，我得先跟你聊聊我自己的经历。刚入行那会儿，我觉得设计嘛，自己觉得好用就行。结果呢？被用户骂得狗血淋头。后来我才明白——可用性测试，就是让真实用户来检验你的设计到底行不行。

1.1 什么是可用性测试

说白了，可用性测试就是找几个目标用户，让他们在受控环境下完成特定任务，然后观察他们怎么操作、遇到什么问题、有什么情绪反应。我习惯把它叫做「设计照妖镜」——你自以为完美的设计，一照就现原形。

你想想看，设计师和开发人员天天对着产品，早就「看习惯了」。但用户不一样，他们第一次接触，哪里该点、哪里该看，完全凭直觉。我记得有一次测试一个表单页面，我自己觉得流程很清晰，结果测试用户愣是花了3分钟才找到「提交」按钮——因为它被设计成了灰色，用户以为那是不可用的。

1.2 可用性测试的价值

为什么要做可用性测试？我总结了三个最核心的价值：

• 发现问题早，改造成本低——开发前发现一个问题，改改原型就行；上线后发现，得改代码、发版本、甚至要发公告道歉。我在项目中遇到过，一个按钮位置的问题，测试阶段发现只要拖拽一下，上线后发现就得改整个布局，前后差了十几倍工时。
• 用数据说话，说服力强——你说「我觉得这个设计不好」，产品经理可能不信。但你说「5个用户里有4个在这里卡住了，平均耗时45秒」，没人敢忽视。我经常用测试数据来跟团队battle，效果比吵架好多了。
• 提升用户满意度，降低流失率——这个不用我多说，用户用得顺手，自然愿意留下来。我曾经参与过一个电商App的改版，做了三轮可用性测试，把结账流程从7步砍到4步，转化率直接提升了23%。

1.3 可用性测试的类型

可用性测试主要分两大类：形成性测试和总结性测试。嗯，这两个名字听起来有点学术，但理解起来不难。

形成性测试（Formative Testing）

形成性测试，说白了就是「边做边测」。在产品设计或开发的早期阶段进行，目的是发现问题、改进设计。我习惯把它比作「做饭时尝味道」——盐放少了赶紧加，火大了赶紧调，不用等到出锅才发现没法吃。

• 时机：原型阶段、低保真设计阶段、开发早期
• 目标：发现可用性问题，指导设计迭代
• 样本量：通常5-8个用户即可（Jakob Nielsen的研究表明，5个用户就能发现85%的问题）
• 输出：问题列表、改进建议、设计修改方案

总结性测试（Summative Testing）

总结性测试，就是「做完再测」。在产品基本定型或上线前进行，目的是评估产品的可用性水平，看看是否达到了预设目标。我把它比作「出锅前的品鉴」——味道好不好，能不能端上桌，得有个说法。

• 时机：开发完成、上线前、版本发布后
• 目标：评估可用性水平，验证是否达标
• 样本量：通常需要20-30个用户（为了统计显著性）
• 输出：可用性指标数据（完成率、时间、满意度评分等）、对比报告

为什么会需要这么多用户？因为总结性测试要做统计分析，样本太少数据不可靠。我记得有一次帮一个金融App做总结性测试，客户说「测5个人就够了」，我坚持要了25个。结果数据出来，5个人的样本显示「完成率95%」，25个人的样本显示「完成率78%」——差了17个百分点。你想想看，要是按5个人的数据就上线，后果多严重。

两种测试的对比

维度	形成性测试	总结性测试
目的	发现问题，改进设计	评估水平，验证达标
阶段	设计/开发早期	开发完成/上线前
样本量	5-8人	20-30人
数据性质	定性为主	定量为主
输出形式	问题列表+改进建议	指标数据+对比报告
典型问题	「用户找不到搜索框」	「任务完成率仅72%，低于目标值85%」

1.4 什么时候该用哪种？

我个人的经验是：项目前期多用形成性，项目后期多用总结性。但这不是绝对的。你想想看，如果产品已经上线了，突然收到大量用户投诉，这时候做形成性测试也来得及——快速找问题，快速修复。

另外，我建议每个项目至少做一次形成性测试和一次总结性测试。形成性测试帮你「做对的事」，总结性测试帮你「证明事做对了」。两者缺一不可。

好了，关于可用性测试的概述就聊到这儿。下一章我会详细讲怎么设计测试任务、怎么招募用户、怎么主持测试——都是实战干货，到时候见。