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

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

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

第一，产品需求评审

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

举几个简单的例子：

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

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

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

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

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

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

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

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

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

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!