如何快速搞定一场小型可用性测试？来看实战案例！

设计师心中的用户和实际情况中的用户之间存在着很大的鸿沟，我们需要利用用户研究来解决这个问题。有时候设计师自认为比较好的方案，到了评审会上，会被各种似懂非懂的人提出各种问题。为什么说似懂非懂，因为评审人里面有产品、研发、业务方等，这些人在自己专业领域都很优秀，但大多数并不太了解交互（设计心理学、交互原则、设计系统等）是什么，都是凭自己的感觉去说，这个时候很多设计师就没招了，只能听着各种“我感觉”来给你提意见，为什么会这样？因为他们知道你也是“我感觉”，你能感觉，为什么他们不能感觉。

设计师觉得自己像个改图的机器，应该就是这么来的。感觉这个东西是不确定的，也许下次评审他们感觉又变了...

解决这个问题的方法之一就是去做用户研究，要知道是谁在使用你的产品。确定用户，了解他们的期望，调查他们的需求，这些都是设计任何一个产品的起点。

因为你的用户不是你，他们的思考方式和你不一样，做事情的方式不像你，也没有你有的期望和假设。如果他们和你一样，他们就不是你的用户，而是你的竞争对手。

这个时候做 B 端的小伙伴就要问了，我们都接触不到真实用户。确实，B 端相对 C 端比较难，但也不是不行，要看你所属行业。比如像钉钉（面向制造业），顺丰（仓储物流）这种 B 端产品还是相对比较容易的，只要公司支持，可以去企业工厂或者仓库看终端用户是怎么工作的。B 端重业务和提效，去实地考察就可以触达这两块。

不过也要看领导层对设计（用户体验）这个部门的认可度，如果领导层觉得设计就是美工，基本就真的只能这样了，这也是很多大佬说的环境和领导很重要的原因。

进入正题...

更多可用性测试干货：

一、用户研究的好处

基础的用户研究简单、快速而且高效，对任何产品都能进行实施，关键是你是否愿意动手去做。通过观看、聆听、记录，你就能更好地了解你的用户（客户），更清楚产品哪些地方不好用。

二、小型可用性测试

可用性测试能说明受众是否能使用产品。它有助于确定人们在使用产品时存在的问题，暴露出不好用的界面和容易混淆的语言。可用性测试通常作为大型研究系列的一部分，涉及准备和分析工作。

但从快速展示产品和经济的角度而言，邀请朋友、同事、家人进行小型可用性测试（以下简称：可用性测试）最合适。这样做，可以用最小预算获得产品的直接反馈。

如果你是第一次进行用户研究，还是先给自己一点时间准备一下。可用性测试过程可以分为四个主要步骤：

定义受众及其目标；创建达成目标的任务；寻找合适的人选；观察用户执行任务的过程。

1. 定义受众及其目标

评估总是始于“为什么要有这个东西?”---华盛顿大学 出于某种原因，你正在设计某个产品。你觉得你的想法能让世界上部分人过得更好。也许能帮他们买到更便宜的东西。也许能帮他们获得其他途径得不到的信息，也许能帮他们联系到其他人，也许能让他们感到开心。 不管什么原因，你都在设计自己觉得会给特定人群带来价值的东西。要能获得这些价值，他们必须做点事情。

因此，对于可用性测试，首先要搞清楚产品的使用对象。对于你预期的、使用产品最多的用户，如何描述他们？他们和其他人有什么区别？区别在于他们的年龄、兴趣和问题吗？实际可能包含前面所有情况，可能还有更多情况。

但这不够具体，年纪大的老人也会购买餐具，但不会从网上购买。所以受众定义范围要稍微广泛一点。目标用户受众如下:

接下来，要找出关键产品功能特性，把产品内容写下来。为什么人们要使用它？为什么它对用户有价值？

2. 创建达成目标的任务

现在把网站五个最重要功能写下来。在购物网站上，人们显然要能买东西。但不管是否准确清楚自己要买什么，他们都应该能买到东西。此外，也许他们还要能发现促销商品和超值商品。列份清单，用一两句话描述一下每个功能。

从使用者角度出发，用两三句话描述一下用户使用某项功能的情况，即所谓任务。如果“通过风格找到特定刀叉”属于功能之一，其任务描述如下:

最后，根据难易程度，按照从最简单到最困难的顺序排列任务。从执行简单任务入手，人们会对产品和任务过程有好感。

3. 寻找合适的人选

现在，找一些符合步骤 1 所创建的特征的人。

找五六个人，这些人要与你预期对产品有兴趣的人相似，像这样快速运用可用性测试，就可以更充分地认识真实用户使用产品时发生的问题和误解。从身边的人中物色合适人选是最快的方法。如果身处大公司，可以从与产品没有任何关系的部门找些同事。如果是在小公司，可以找朋友、家人以及同事的朋友和家人；可以找在办公室的人；可以找街头的行人。还可以找一些不熟悉产品的人、无论喜欢者或不喜欢，对产品都没有偏见的人，只要这些人和你期望访问网站的人有点相似就行。除非产品专为开发人员而设计，否则就不要找靠开发网站谋生的人，因为他们懂的东西太多。

4. 观察人们执行任务的过程

首先，写一个剧本（测试任务），受邀的用户会根据剧本进行。

例如：用户现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。 你也可以在测试任务上介绍一下产品是做什么的，让所有参与测试的人都知道这是一个什么产品。

接下来找一台电脑，一个安静的房间。一般情况下，找个小会议室即可。确保房间里没有任何与产品有关的东西，以免分散用户的注意力。

测试前需要告知用户，他们受邀到此，是为了帮助你了解产品哪些地方有用，哪些地方让他们感到困惑。

虽然称为测试，但不是要对他们进行测试，而是邀请他们来评估产品，谈谈他们对产品的看法，所以他们怎样做都没有对错。

要强调一点：如果不能完成任务，也不是他们的错；如果他们说出对产品的负面看法，也不会伤害到任何人。他们要大声说出所有想法，这一点很重要。建议他们详细叙述在做什么，以及为什么这么做。

你会留在同一房间里，一边倾听他们发言，一边做笔记。这个过程不要打扰到用户，要让用户专心执行任务和详细叙述。

如果测试过程中他们被问题卡住了，不要告诉他们应该单击哪里或者看什么。不管什么情况，都不要告诉他们应该怎么做。如果他们看上去特别沮丧，就告诉他们有些事情无法完成不是他们的错，请他们执行下一任务即可。

如果所有任务都完成了，或者半小时时间已到，就可以请他们停止。请用户向自己谈谈他们的总体印象，他们是否会“在现实生活中”使用该网站。 然后送份礼物谢谢他们为测试所花的时间（吉祥物、小礼品、餐饮券…只要适合受众就行）向他们表示谢意，并送他们离开。

最后，重启电脑（恢复初始状态），清除缓存和浏览历史，为下一位用户测试做好准备。

三、你学到了什么

可用性测试一结束，马上问自己下面几个问题。

1. 哪些功能起作用了?
2. 有没有用户总是误解的东西? 如果有，是什么?
3. 有没有错误总是发生?如果有，是什么错误?
4. 他们有没有按照你期望的方式执行任务？如果没有,他们又是怎么做的?
5. 他们执行的顺序是否与你期望的一样？如果不一样，又是什么顺序？
6. 你期望他们会发现有趣（创意点）的东西，但事与愿违，他们并不觉得有趣。
7. 他们完成了多少任务？哪些任务困难最大？
8. 他们在什么时候感到受挫？当时他们在做什么？
9. 产品符合用户的期望吗？如果没有，哪些地方让他们感到失望？

到这里，你应该知道产品哪些地方存在问题。

你可能看到有几件事情一而再，再而三地发生。也许用户并不理解你为某项功能指定的名称。也许他们没看到关键功能。也许他们对所提供的功能不感兴趣。也许，他们喜欢这个产品，它能满足他们想要的一切。知道所有这些情况是好事，因为能揭示问题出在哪里，而且同样重要的是能说明哪些地方没有问题。

四、实操案例

这里的案例是一个面向制造业的产品，解决制造业多系统中数据的统一、维护、共享。

1. 定义受众

产品面向的受众人群主要是业务与技术人员，对数据库等知识有一定的了解。

2. 设定典型任务

任务：现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。

3. 寻找合适人选

Nielsen 提出的一个法则：有 5 人参加的用户可用性测试，即可发现 85% 的产品可用性问题，而且通常最严重的问题都是前几名用户发现的，随着用户数量的增多， 发现的问题逐渐减少，被发现问题的数量与测试用户数量的关系如下图所示。

这次测试参与人员共 6 人，普通用户 3 名，技术人员 1 名，产品经理 1 名，项目经理 1 名，都是公司内部人员。

4. 观察执行任务过程

从执行任务可以发现，普通用户问题是最多的，但这个产品定位是技术人员，所以我们可以先不关注普通用户诉求，后面三类用户虽然都懂技术，还是存在很多使用上的问题。

原型如下：

5. 根据反馈进行优化

例如：第一条不知道新建规则流程，设计的人会认为大家和他一样会使用，其它并不是，上面的产品经理不负责这个产品，所以他也不知道怎么使用，这也是 b 端产品的特点，c 端玩玩就会了，但 b 端你不懂业务就真的无从下手。 基于这一点我们可以给一个功能引导页面，如下：

剩下问题的这里就不举例了，只想说明用户分析很重要。

谢谢大家观看！