可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。
工作中在遇到大的产品改版，或者对某个设计拿捏不准的时候，经常会使用到可用性测试。在网上搜索可用性测试相关的文章，大多都描述的非常专业，很容易让初学者望而生畏，尤其是让很多初级产品经理或者小型初创公司觉得太专业没有资源，所以干脆不做。
而笔者的看法是这样的：
要做到完全符合流程和标准的可用性测试，确实有一定难度，需要的成本也很大，但是，需要注意的是：我们做可用性测试的目的不是“做可用性测试”，而是“发现用户真实使用情况中遇到的问题，来提升产品的可用性”，所以，目的最重要，只要能达到这个目的，流程完全不必如此复杂，有些可以省的步骤当然可以省，只要最重要的核心流程和注意点我们把握好即可。
另外，可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。可用性测试是一种定性研究方法，有研究称，只要5个人就可以发现大部分共性问题，而这大部分共性问题，在版本发布前发现并解决掉，是一种非常节省资源，规避风险的方法，甚至有时候可以救产品一命。脑补一下，某个产品进行了一次大的改版，产品经理们觉得这次改版非常棒，老板也觉得很满意，然后释放给用户，用户反馈和数据都非常糟糕，那么这个时候，想要再补救，需要投入的成本就会非常大，最重要的是，用户很容易产生晕轮效应，使得产品其他优秀的点也会被牵连，这对于导入期和成长期的产品来说非常不利，很可能会导致用户的流失。原因很简单，产品经理往往对自己的产品太熟悉了，就会发生太多的想当然。
怎么做
下面，笔者将会走一遍标准的可用性测试流程，阐述一下那些必须做到的点，和那些大可不必较真的流程。
第一步：资源准备
资源准备包括测试环境和工具，包括办公室、观察间、网络、测试设备（手机、电脑等）、麦克风、录屏软件、屏幕共享软件、摄像机、眼动仪等。
这些资源里：办公室可以用会议室代替；测试人员和用户可以坐在一起，所以观察间可以不要；只要测试的功能不牵扯到网络使用，网络可以没有；屏幕共享软件和麦克风主要用于测试人员在观察室进行观察，也可以不要；眼动仪主要用于跟踪眼球运动，可以省略；录屏软件用于将屏幕记录下来，也可以省略，但是免费的录屏软件非常多，建议还是安装一个。那么剩下的，就是测试设备，测试设备当然是不能省略的了，因为这是测试的基础，用户总得有可操作的东西才可以进行测试。
可以看到，资源准备的时候，在最简陋的情况下，我们只要准备测试设备，和一个会议室就可以了，当然，测试人员需要准备纸笔做好记录。
第二步：任务设计
任务设计就是准备你要用户去做的事情，这一步当然是不可避免，而且必须去做好准备的，这样才能将每一次测试的收益最大化。
准备任务的时候，产品经理首先要明确一个问题：此次测试的目的是什么？是测试整个改版后的产品？还是测试某个功能的可用性？或者只是测试某个功能的视觉效果？
目的很重要，目的不同，我们设计任务的时候，问题的维度和场景就会有区别。
接下来根据我们的目的，来设计测试任务，这里有几个需要注意的点：
（1）一定要站在真实的用户场景来描述问题
比如：使用下XX产品的录音功能，这样可能看起来没什么问题，但是笔者在以前做可用性测试的时候，发现这种问题会使得用户操作起来没有明确的目的性，那么他们面对这种问题的时候，大部分用户都是瞎点击，随便点点就返回。如果我们这么问：假设你想用XX录音软件，录制一段歌声给你的男/女朋友表白；假设之前开会的时候，你通过录音机记录了会议过程，你现在想找到它并听会议内容。这两个问题就是有明确的用户场景，那么用户在操作的时候，我们观察到的也就是用户在真实生活中的实际可能的操作步骤，发现的问题也就是用户实实在在会遇到的问题。
（2）在问题描述的时候，千万不能有任何引导性语言
比如刚才这个寻找录音文件的例子，如果我们这样提问：假设之前开会的时候，你通过录音机记录了会议过程，请你现在进入录音列表，通过快速滚动条滑动找到它，然后点击听会议内容。这个问题就明确地引导用户怎么去操作，但是用户真实使用中，一定会这么做吗？也许用户根本不会用到快速滚动条？如果这么描述的目的是为了看用户使用快速滚动条的情况，那么最应该的做法是，不告诉用户滚动条的事情，让用户自己操作，看用户是否会发现快速滚动条，发现后是怎么操作。笔直之前做的一个可用性测试即是想看到用户对快速滚动条的使用情况，结果非常吃惊，大部分用户没有发现这个滚动条的存在，而发现的用户居然不会使用，或者不知道是快速滚动条。我想如果在测试前告诉了用户滚动条的事情，那么也就无法发现这些问题了。
第三步：用户招募
一般情况下，需要寻找产品的目标用户做可用性测试，我们可能需要在网上公开招募，或者通过公司的资料库联系用户等方法来寻找测试用户，但是很多情况下，我们无法快速寻找到合适的测试用户，这个时候其实不用那么死板，可以稍微转下脑筋，就近考虑，是不是前台小妹或者楼下保安也可以做为测试用户呢？再简单一点，隔壁产品组里，对我们产品不怎么了解的工程师是不是也可以呢？用户招募只是其中一环，我看到有些同事为了招募用户耽误了大量的时间，其实是得不偿失的，尽快进行测试的重要性更高，因为项目排期和交付日期可不会因为用户招募需要时间就延迟的，而如果因为用户招募导致没来得及做可用性测试，那真的是非常可惜了。
有数据称一般情况下，只需要五个用户即可发现大部分共性问题，但是如果找不到，根据经验三个用户也是可以发现大部分的严重问题，所以在用户招募方面，不要太严格和死板很重要。
第四步：测试执行
执行测试过程的时候，有观察室、录像机、屏幕共享软件等完备的测试环境当然最好，不过这里只描述最简单的情况：不需要主持人，产品经理做测试人员，一个会议室和一个测试设备。
首先，我们要向用户说清楚此次测试的目的，并记录下用户的基本情况，尽量以聊天的方式进行，让用户尽量放松，不要感到压力。如果用户很紧张，那么测试结果可能会大打折扣。另外，不要用太专业的术语和用户沟通。接下来我们就可以让用户按照之前准备好的测试任务进行操作，这个时候，测试人员需要在一旁用纸笔做好记录。
（1）测试过程中，不要去打扰用户，也不要给用户任何提示，所有的问题都等到测试结束再进行询问和沟通
有时候在测试的时候，测试人员看见用户遇到了障碍便去进行提醒或者提问，这是不可取的方式，因为真实用户场景中，不会有人去提醒用户，而测试中所做的任何提示，都有可能导致问题无法暴露，这个时候应该做的事情是用纸笔记录下来，并在测试完成后，和用户进行沟通，询问用户当时在这里出现障碍是遇到了什么问题，当时自己是怎么想的。另外还存在一种情况，就是用户遇到问题的时候，会主动问测试人员，这个时候笔者给的建议是，直接回答用户：我也不知道。当然有一种极端的情况，用户实在是操作不下去了，那这个时候就必须给用户一点提示了，否则也许测试过程没法继续进行了，这个度需要测试人员自己做好权衡。
一般情况下，测试人员只会注意到用户操作过程中的操作手法，而不怎么注意用户表情。而很多情况下，用户可能遇到一些小的问题后，直接放弃操作去做其他事情，这个时候如果只看用户操作，可能会忽略掉这种问题，但是如果观察用户表情，可能会发现用户出现皱眉或者微笑等一些明显的表情变化，这个时候将用户表情和当时在进行的操作进行联系，测试完成后和用户进行询问沟通，往往可以发现一些问题或者一些惊喜。
很多时候，用户说的和做的是不一样的，而且在测试完成后，和用户再进行沟通，用户可能已经忘记了，那么他们这个时候的描述和当时的操作可能就会存在差异。而“发声思维”可以很大程度解决这个问题，即用户在操作的时候，让用户同时说出来，说出自己的思考过程，比如：自己要做什么事，先做什么，再做什么，为什么要这么做等。这个时候，一旁的测试人员只需要做好记录和观察即可。
第五步：报告呈现
报告尽量简短，形式不重要，重要的是内容和可读性，一般要包括测试对象的基本信息、测试的任务清单和测试结果、用户反馈以及问题整理整理和改进建议。
另外，笔者建议测试报告尽量包括测试过程的简单描述，对以后回顾问题的时候会有比较大的帮助，当然这部分可以不放到测试测试报告的正文里，如果用xls整理报告，可以在其他表单里记录。
最后一步：问题解决
这一步才是可用性测试最终实现它价值的地方。经过前面四步，我们已经得到了测试的结果，那么接下来就需要产品经理将这些问题进行归类，并进行需求分析和优先级评估，确定出需要修改的问题，进行排期，这就是产品经理的日常工作了。
最后的最后：其他需要注意的点
（1）针对某次发版的可用性测试一般建议不能做太晚，如果等到产品快上线了，才做可用性测试，并且发现了很严重的问题，那么这个时候就有点于事无补了。所以，在做可用性测试的时候，有产品就用产品测，有Demo就用Demo测，有原型就用原型测，什么都没有，也可用用竞品做测试，这样避免我们去 踩竞品的坑。
（2）可用性测试什么时候都可以做，要贯穿到整个产品的设计过程中，作为产品经理的一项基础日常工作，想想看，如果我们可以用上述的“简版”可用性测试方法，性价比还是很高的，比如笔者曾经做过一个可用性测试，用户招募就是简单的从公司里找了一些小白，测试的功能是通过带有时间的快速滚动条来快速定位图片（测试之前，快速滚动条的样式是半黑透明，上下端是两个小箭头，点击该滚动条出现时间，用户可以开始滑动，停止点击几秒后，时间消失）但是通过下面的测试结果看到，如果没有这次的可用性测试，那么这个功能释放给用户后的结果将是：无人使用。
而这整个测试过程，当时只花费了2个小时。所以“简版”的可用性测试的性价比真的非常的高。
（3）针对来测试的用户，在测试完成后，给用户一些实际的奖励，比如可以准备一些奖品或者纪念品给用户，也可以奖励用户一些产品的虚拟货币或者积分、虚拟宠物之类的，并且和用户进行友好的沟通，询问用户是否愿意接受以后的测试。这些都会更方便以后做可用性测试招募用户。
总结
如标题，可用性测试真的很难吗？我想看过这篇文章后，读者会有自己的见解。笔者在这里只需要强调一次前面已经说过的话：可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。
