如何做可用性测试之我见

如果你想拥有一个优秀的产品，在上线之前做用户测试则是必不可少的一步了，它能帮助你检验证明产品是否如团队所想的达到预期、用户的交互方式是否和团队设计的一致、发现在产品中遗漏的问题、丢失的细节等重要因素。那什么叫可用性测试？我的理解是：针对产品所要达到的目标，让用户体验产品并观察整个过程当中用户的交互行为与思考；总结所发现的问题轻重程度，找到最为关键的核心问题。那如何做可用性测试呢？诸位莫急，待我来一一解答。  

首先，让我们来看看在测试过程当中有哪些环节是必不可少的，我给它做了如下的分类：环境、任务目标、用户、测试、总结。

环境

在测试之前，你得先准备一些东西：一间布置温馨独立没有干扰的办公室（营造一个轻松的环境吧，不要让用户觉得过于严肃压抑）；一个做产品测试的设备（务必确保设备和产品都可以正常的演示、访问、运行）；一杯咖啡或者温水（甚至可以准备一些零食和糖果，作为对愿意花时间来做测试的用户的感谢）。

任务目标

顾名思义，当有了明确的任务和目标之后，就能在测试中有针对性的让用户来操作，然后仔细观察他们是如何做的。这些任务应该是团队针对产品所精设计好的，有合理的动机和解释（我们可以赋予用户的一定的模拟情景，让用户在测试的过程中有更加真实的代入感）。并在任务数量和测试顺序上有很好的把控，以整个测试时间长度为基础（通常建议控制在1小时—1个半小时左右），分配好任务流程。

用户

在这里，按照针对性来区分，我将用户分为两个大类：普通用户（在DMMT一书中认为事实上并不存在所谓的普通用户，每一个人都是单独的个体都有着独一无二的个性和特征，所以不存在普通用户即{标准用户}这一说法，这里所说的普通用户实际上是指只要会操作电脑，任何职业和岗位的人都可以作为普通用户），和目标用户（一定会使用到产品的典型用户或者是为了某一类人群而独立开发的产品，针对这部分人群，因为有很强的目标性，所以我们称之为目标用户）。对于更加没有针对人群和针对目标为导向的产品，我们更加倾向于找普通人来做测试，可以是你的朋友、同事、同学等等。

测试

由于我们在测试之前已经搭建好了这样的一个测试环境，在这里我们就直接从测试中开始了。首先，在面对用户的时候一定不要过于拘谨，这样可能会造成你和用户都紧张，要试着去解除用户的这种防备心态。在测试产品的过程当中，做一些适当的引导用户和鼓励用户多去尝试操作。通过观察、询问、倾听，鼓励这四种 ‘心法’。必能进行一个顺利的测试。

观察，在测试的过程当中，可以留心观察用户在表情上的变化，邹眉、惊讶、思考，犹豫，我们都可以从中捕捉到用户对于当前产品产生的交互变化出现了一丝困惑和质疑，以至于他停下来，这时候我们就该记录这是哪个节点所产生的问题，然后在用户停止交互时合适的去开始询问。

关于询问，这个时候，我们就该在刚才出现产生问题节点的地方，再一次重现给用户，如果用户没有主动的说明是出于何种原因，那我们就可趁机询问用户：为什么（多问为什么，要知道这是我们是和用户 ‘一起’ 来完成产品开发的过程，用户在整个测试当中是很愿意提出自己的想法建议的）。通常用户在很肯定的情况下会很快的主动说原因，这类反应通常可以认为产品的这个问题在直觉层面就出现了问题以致很轻易的就被发现。如果难以即使的说出原因所在，就可以跳过。在这里切记不要去给用户过多的信息和主动的提示（笔者在做可用性测试的时候就犯过类似的错误，着急用户为什么不理解产品背后的逻辑急于给出自己的解释），其实这是非常不好的一个行为方式，它会直接对用户未能理解和完成任务而在心理上产生一定的挫败感，会在用户心中产生一种谨慎的心理防备状态，反而适得其反。

所以，倾听在这时候就显得尤为重要，为了让用户有一个更好的状态和做测试，学会倾听用户的说话，和用户保持一种友好的交流状态才是最为理想的。而在倾听之后随之可以给用户更多的鼓励，对于用户的意见和自己的想法，我们都可以鼓励用户大胆的说出来，这是一种很好互相认同的方式，同样也是能提升测试中的好感度和氛围。

另外，在测试中很重要的一点就是随时记录问题，这一点是和以上四点都有所不同的是它是一个贯穿始终的动作，你必须在适当的时候抛出问题、询问，然后用最清晰的文字记录下来在哪个位置上，用户出现了怎样的反应，为什么会让用户有这样的反应发生。这些都是之后在总结的时候所用到的重要依据。

总结

随着我们问题的结束，我们在整个测试环节也就告一段落。现在，我们得到了很多记录下来的问题，此时我们还可以和用户做一个对问题轻重的分类：问题最显而易见的、交互/设计最复杂的、逻辑结构不通的，用户质疑最多的，这些都是我们在测试中所分出的不同点。

通常测试的用户数量我们会选择在3~5位左右来进行一轮测试，在进行完全部用户的测试之后，我们会马上回顾测试结果，针对每一个用户都有已经分好类别的问题，汇总到一块大区域内，我们再把相似类型的问题区分开，不同类型的问题，一些常见的问题（比如在文案上面对一些动作按钮的称呼不准确）等。关系到核心功能并且面对这个问题的时候难以解决，不同用户对此都有类似的同感的时候，我们就知道该到底是哪些关键的地方成为了关键问题。

任何问题其实都不一定有一个完美的解决方案，我们在面对问题的时候孰轻孰重都要很好的把握其中的尺度，而方便快捷并且团队都达成一致，确定下一步怎么做，这才是最重要的。

P.s.  本文参考了《 DON'T MAKE ME THINK 》一书中的关于简单测试一块的内容和在自我实践的基础上的自我总结。在《 DON'T MAKE ME THINK 》一书中对这种被称作 “跳楼大减价的简易可用性测试” 更是做了详细讲解，如有感兴趣的读者可在书中一探究竟。