阿里PM的可用性测试秘籍：有理有据的用户体验优化

【文章摘要】今天介绍一种用户研究中广泛使用的“可用性测试”方法，可以用于在产品研发的全生命周期中发现产品的可用性问题，论证设计的合理性，从而避免由于对用户缺乏了解而产生的不合理设计。

周卿，现任阿里巴巴商家业务事业部，负责大数据业务相关商业产品。硕士毕业于清华大学，曾任有道词典产品经理。

对于产品经理而言，有几个场景怕是最难熬的：

第一，产品需求评审

面对你信心满满设计出来的方案，众产品和研发同事横挑鼻子竖挑眼，“这个功能为什么要这么设计”，“你看看某某产品，他们就是这么做的，不是挺好吗”，“这种方案实现起来难度太大，非得这么做吗” ，看起来大家本着对产品负责的态度精益求精是好事，但对于产品经理而言，倘若缺少思考和准备，这种感受就和过堂一样难熬。

第二，新功能上线引用户强烈不满

产品发布新版本，刚开完香槟庆功，来自客户和运营人员的反馈却让产品团队惊慌，不满的声音实在太多，骂声一片。倘若这是产品变革可预期的用户适应过程也就罢了，只怕产品的改进严重影响了用户的使用习惯，降低了用户的使用效率，得不偿失，而这样的事故，是有可能避免的吗？

第三，新功能上线却使用者寥寥

产品发布新版本，还有什么比用户强烈吐槽更糟糕吗？有的，那就是用户没有反应，就好像新功能并未上线一样。比如说，新功能打开的人很少，或者仅仅执行了简单的操作就退出了，完全没有触及到核心功能。是因为他们对功能不感兴趣吗，还是他们根本没有意识到新功能的存在？

当然，还有一种对话广泛出现在我们和用户的沟通过程当中：

“你们的这个产品真的很好，我还希望有个这样的功能。”

“恩？这个功能我们已经有了呀，你看，这么操作就可以……”

如此这般的问题，是否可以有一些方法去规避和优化呢？答案是肯定的， 今天介绍一种用户研究中广泛使用的“可用性测试”方法 ，可以用于在产品研发的全生命周期中发现产品的可用性问题，论证设计的合理性，从而避免由于对用户缺乏了解而产生的不合理设计。

1.什么是可用性测试

可用性测试，从名称上就可以看出，是研究产品是否“可用”，是否“易用”的方法。产品是否好用，断然是不能由产品设计人员说了算的，如果你深知产品的设计细节，自然再难用的产品都可如鱼得水。
简单来说，所谓可用性测试，即“观察用户使用产品”。

具体一点说，可用性测试是通过观察有代表性的用户，完成产品的典型任务，从而界定出可用性问题并解决的过程。可用性测试的终极目的是为了让我们的产品更好用。

根据定义可以发现，可用性测试的核心有三个：第一，典型的产品任务；第二，有代表性的用户；第三，观察。可用性测试的输出结果是产品的可用性问题，即阻碍用户通过使用产品达成用户目标的那些因素。

2.什么时间进行

可用性测试是可以贯穿产品全生命周期的，从需求探索到产品发布之后的更新迭代，都不可或缺。关于什么时间适合可用性测试，我们的观点是：越早开始越好！越早开始越好！越早开始越好！

在产品上市之前，如果有线框图，可以拿线框图去找用户测试，如果有低保真原型，可以拿低保真原型去找用户测试，如果有高保真原型，可以拿高保真原型去找用户测试，如果有Demo，可以拿Demo去找用户测试……

为什么需要这么早进行呢？因为，在产品设计阶段的可用性问题，如果不及早解决，它所能产生的影响会随着设计阶段的不断深入而被放大，导致无用功的产生。我们的重点不是为了惊艳用户，而是为了通过用户对产品的认知，定义可用性问题并及早解决。

有的时候，为了减少产品设计的弯路，甚至可以拿着竞争对手的产品去找用户做可用性测试，也是很有借鉴意义的。

3.典型的产品任务

所谓“典型的产品任务”，指的是你希望测试的那部分功能最常见的使用场景下用户需要完成的目标。注意，我们提供的信息只有两个：场景+目标，而不是先点什么按钮，再点击什么按钮的操作序列。我们测试的主体是，在特定的场景下，用户能否使用我们的产品，完成他的目标。

举几个简单的例子：

测试邮件系统的过滤器功能，我们提供给用户的任务可能是：最近，你的工作需要和来自A公司的合作伙伴频繁沟通，为了更好地管理邮件往来，你打算将来自A公司的邮件收入统一的文件夹内，A公司的邮件后缀统一为@A.com。

测试微信的雷达加好友功能，我们提供给用户的任务可能是：今天你刚刚参加完一场行业聚会，同组讨论的5个人聊得非常投机，打算互加微信好友并建群日后保持联系。（这个场景可能会遇到被试用传统的一对一扫码加好友的方式操作的情况，可以适当提醒使用雷达功能完成这个操作）。

测试词典软件的生词本功能，我们提供给用户的任务可能是：今天你刚拿到一篇英文论文，请在使用词典帮助的情况下完成阅读，并将不认识的词加入到生词本，以便日后复习。

有的时候，我们会为了单个功能点进行可用性测试，有的时候，我们会为了整个版本的产品进行可用性测试，根据我们测试目标的不同，为用户设计一系列的典型任务，确保覆盖产品各个功能点，是可用性测试顺利取得结果的基础。

4.有代表性的用户

可用性测试以用户为测试主体，所以在清楚地了解典型任务之后，我们就该通过不同的渠道筛选一些合适的用户来参与测试了。

研究表明，在测试方案和测试方法合适的情况下，只要需要５个用户，就可以发现产品80%的可用性问题。在实际操作中，我们也可以采用以下的方法：重复测试用户，当不能再发现更多新的可用性问题时停止，通常情况下5个用户就已经足够。

用户来源可以有很多，如果你有核心用户池并和他们保持了良好的关系，那真是太好了，如果没有，通过微博，微信公众号，邮件，论坛等方式给用户发可用性测试邀请，也是不错的选择。

在招募用户的时候，可以邀请用户提供一些产品使用经验的相关信息，可用性测试往往不适宜通过简单的人口统计学特征（如性别，年龄，地域等）进行用户筛选，而应该把关注点放在他们产品使用相关的经验上，比如：使用你的产品的频率和时间长度，相关技能和知识背景，使用相似产品的经验，互联网经验等等。一般来说，在用户招募广告上，加一个简单的用户信息筛选问卷，就可以做到。

搜集到有意愿的用户，根据他们提供的信息筛选出目标客户，约定好时间地点就万事俱备了。在正式测试之前，最好抓上身边的同事先预测试一下，这样可以保证真正面对用户的时候，对方案及可能出现的问题已经了然于胸。

5.可用性测试过程

当一切准备工作就绪，在约定的时间，可用性测试就可以正式开始了。在这个过程当中，产品经理需要同时扮演主持人和记录者的角色，一方面保证测试过程按流程进行，一方面对观察到的用户操作行为和可用性问题进行记录。

在测试正式进行之前，我们需要迎接用户，做简单的自我介绍，告知用户可用性测试的目的，最重要的是让用户知道，我们测试的对象是产品，而不是为了用各种任务来考察用户，缓解他们的紧张，让他们乐于表达测试过程中的疑问。

一些基本的问题用于开场是非常合适的，收集关于用户的基本信息，同时，因为这些问题简单，有利于用户慢慢静下来，进入产品的测试阶段。比如，职业是什么，使用产品的经验是什么，平时喜欢用哪些相关产品等等。也可以让用户随意操作一下用于测试的电脑或手机，让他们熟悉情况。

接下来，根据之前定义的每一个“典型”任务，引导用户操作。读出预先准备好的典型任务清单，确保用户理解了任务的意思，然后一个任务一个任务地进行，同时记录用户的操作和想法。

注意：所有用户迟疑、疑问、困惑的点都应当被关注并记录，那些可能就是可用性问题的所在。

另外，测试过程中有一些注意事项：

• 邀请用户在有想法产生的时候说出来。
• 不要以任何方式表现出用户正在犯错或操作太慢。
• 仔细的观察、并认真聆听用户的建议。
• 用户遇到困难时尽量不要提供帮助，可给予适当鼓励，比如“你可以再试试”。
• 在用户完成一个场景时可适当的问“为什么刚才这样操作”。
• 识别用户的情绪，必要的时候选择停止任务。
• 当所有典型任务测试完毕之后，可以问问用户，有没有什么问题是他们想问却没有问的，对产品功能的整体感觉怎样，有没有对产品的建议，最重要的，对用户的参与表示感谢。
• 在测试的间隙，抓紧时间整理和休息，只有在产品经理自己精力良好的情况下，才能及时捕捉到用户的细节反应哦。

6.测试结果的整理分析

当所有的测试环节都已经完毕，你手上大概已经有了五六个用户的可用性测试记录，将每个用户遇到的问题分别记录，归类，并和团队的其他职能人员一起研读讨论。

一次测试中可能收集整理多种数据，包括用户表现数据，如任务完成情况（成功人数，失败人数，成功有困难人数），任务完成时间，用户操作情况（点击，翻页，滑动），以及用户偏好数据，如用户的评价，建议，满意度问卷分数等。

最终输出的结果，应该是按优先级（问题出现的频率？对用户完成任务阻碍的严重程度？）排序的产品可用性问题，到底是产品的哪些设计影响了用户的使用呢？

挑出最重要的10个问题，制定修改方案，然后重新投入新一轮的用户研究过程中去吧！