一个新功能上线了。在上线前的内部评审中，围绕功能所做的一切评审都顺利通过，产品经理觉得逻辑清晰，开发觉得实现没有问题，设计师也觉得界面美观干净、体验佳。但上线两周后，客服那边陆续收到用户反馈，有用户反应不知道这个功能怎么用，还有用户直接问"这个是干什么的"。

这种情况，我想作为设计师的你，一定不会陌生——内部所有人都觉得没问题的功能，但真实用户使用中却遇到了障碍。这种问题反复出现，往往不是出在界面设计本身，更不是功能定义不好，而是出在设计流程之中，这里面缺少了一个必要的验证环节：在产品到达用户之前，有没有让真实用户实际使用过它。而这就是我们今天要讲的可用性测试。

一. 可用性测试在做什么

可用性测试就是让真实用户在接近真实的场景下完成真实的任务，观察他们的卡点在哪里、怎么卡住的、为什么会卡住。

这个描述里有几个词需要我们认真思考。

先说"真实用户"。 测试对象不能是设计师自己、团队同事或其他对产品已经很熟悉的内部人员。内部人员参与测试的问题不在于态度认不认真，而是他们对产品已经太熟了——他们知道功能藏在哪里，知道图标代表什么含义，知道下一步该点哪里。这种熟悉程度让他们无法遇到真实用户会遇到的困惑。可用性测试需要的是那些第一次使用产品、或者很少使用产品的人。只有这些人操作中遭遇的障碍，才反映出产品真实存在的问题。

再说"真实的任务"。 测试不是让用户随便逛逛、聊聊感受，而是给用户一个明确的任务目标——比如"找到并修改你的收货地址"——然后让用户自己去完成。用户能不能完成、用了多长时间、走了哪条路径、在哪一步停下来反复犹豫——这些行为数据才是测试要收集的信息。

最后说"观察"。 观察是整个测试最核心的动作。测试的重点不是问用户"你觉得这个功能好不好用"，而是看用户怎么用。用户说的和用户做的经常不一致：用户可能礼貌地回答"还不错"，但在同一个页面上连续点了四次错误的按钮。那四次点击比任何口头评价都更能说明问题。

还有一点容易被忽略：可用性测试检验的是设计方案有没有问题，不是用户的操作能力够不够。但在测试现场，测试人员看到用户卡住，下意识的反应往往是"这个用户不太会操作"。实际上，用户卡住说明设计在这个环节没有把用户引导到正确的路径上。找出这些让用户卡住的设计缺陷，正是可用性测试的目的。

二. 可用性测试和用户访谈的区别

不少初级设计师会把可用性测试和用户访谈混在一起，觉得"都是找用户聊"。但这两种用研方法研究的是完全不同类型的问题。

用户访谈问的是"你觉得"——你觉得这个功能有用吗？你平时在什么情况下会用它？你觉得哪里不好？访谈收集的是用户的态度和看法，是用户自己对行为的描述和解释。

可用性测试看的是"你做"——你实际上怎么操作？你在哪一步停下来了？你最终完成了没有？测试收集的数据的是行为本身，是用户在任务情境下真实发生的操作过程。

为什么行为比态度更可靠？不是因为用户在说谎，而是因为人对自己行为的解释往往是事后重建的，未必准确。比如一个用户可能会说"我平时找功能都挺快的"，但在测试中找了三分钟才找到目标入口。这个用户并不是故意表现差，而是高估了自己在不熟悉界面下的操作效率。测试中观察到的操作过程，比用户自己的描述更接近真实情况。