根据5W1H的顺序，说说关于可用性测试的那些事：
一 What?
什么是可用性测试？
可用性测试，就是通过观察用户使用，获得真实用户使用的第一手资料，根据实际用户的使用习惯，改进产品的可用性，减少用户在使用中的挫败感。
二 Why?
为什么要做可用性测试？
首先，当然是为了提高产品的可用性，让用户用起来更顺畅。
其次，我们会花很多时间讨论用户根本不关心的问题。比如有些时候我们花了很多实际讨论导航应该横着放还是竖着放，最后发现用户根本不知道网站是做什么的～
我觉得有必要把最小化可行产品和可用性测试两个概念放一起对比一下：
最小化可行产品－验证假设：每个产品的成功都基于某些假设，比如苹果的音乐播放器，是假设用户会花钱购买音乐；扫码抽奖活动，是假设用户愿意为抽奖机会，去进行扫码的行为。所以最小化可行产品的目的是尽快完成“产品上线－数据评估－验证假设，获得认知”的过程，以评判自己的对于用户和市场的假设是否正确。
可用性测试－真实用户流畅完成产品的操作和功能：比如扫码抽奖的活动，可用性测试的目的是观察用户在实际使用我们的用户是否能理解活动的意图，顺利的完成扫码，抽奖的操作。通过观察，修改给用户带来挫败感的地方，增加产品的易用性。
三 When?
什么时候开始做？产品上线前？上线后？
建议是：“越早越好，至少每个月测试一次”
那么问题来了，什么叫做早？
四 Who?
找谁来做可用性测试？一次找几个？
“会用该设备上网的人，一次三个即可”
一般的想法都是找目标用户或者符合一定人口统计学的入群，男性30岁左右，使用智能手机bulabula。当然这些想法是非常有道理的，比如不是目标用户的人群不会使用我们的产品，怎么会来参与测试？目标用户更能测出实际用户会发现的问题；目标用户更具备使用产品需要专业的知识，更容易理解我们产品。
但其实，我们的产品是希望没有相关产品使用经验，第一次使用的用户都可以理解，并且大部分严重的问题，正常的用户都会发现。
当然不是说不要找目标用户，这是一个权衡，如果是目标用户非常容易找到，那当然好。如果不那么容易，就不要把太多时间浪费在寻找目标用户上，尽早开始测试更加重要。
找几个用户来进行一次可用性测试？这个问题没有明确的答案。我们可以回归一下做可用性测试的目的：我们是希望发现严重的问题并尽快进行改进，而不是一次性发现所有的问题。一般来说，3个用户就会发现70%的问题。一次测试太多的用户，发现过多的问题，对于优先级和排期也会有很大的影响。并且越难做的事，越难以开始和坚持。每次找3名用户，测试并修改相关问题，下个月再次进行验证和发现新的问题，进入一个良性的循环。
五 Where?
可用性测试的场所？需要的设备？
一间办公室 网络 测试设备 麦克风
录屏软件 屏幕共享软件 报酬
这些东西都非常容易获得，参与测试的用户和主持人在一间办公室中，保证良好的网络。在测试设备上安装录屏软件和屏幕共享软件，录屏软件记录用户的在屏幕上操作以及主持人和参与者的对话，屏幕共享软件和麦克风是为了方便观察者在另一间办公室观察参与者的操作。
六 How?
如何进行可用性测试？
测试的流程如下：
资源准备－>任务设计－>用户招募－>测试执行－>报告呈现
1）资源准备：按照第五部分准备好相关的设备即可。
2）任务设计：
3）用户招募：按照第三部分招募即可
4）测试执行：
step1:测试前
step2:测试中
step3:测试后
在可用性测试中的给主持人的建议：
1.让参与测试的用户一直保持出声思维，不断的说出自己的想法，看到的，想到的，关注的内容等等。
2.主持要保持中立的态度，不要因为是自己做的产品就往好的方向引导，或者不看好产品就往不好的方向引导，这样就会失去做可用性测试的意义。
3.如果参与者有疑问，主持人可以考虑以问题来回答问题，尽量不影响用户的判断。
“我这么操作对吗？”
“您觉得呢？”
4.主持人要注意观察用户的表情和身体语言，随时知道用户在做什么，想什么，如果不知道，出声询问。
在可用性测试过程中，观察者要做些什么？
1.观看可用性测试过程，做记录
2.每场测试结束，记录最严重的3个问题
3.让主持人帮他们想参与者提问
4.参与总结
5）总结报告
尽量简短，以2分钟能读完，30分钟写完为佳
包括三个要点：
1）测试的对象
2）测试者执行的任务清单
3）下个月要修复的问题
那么问题来了，如何确定下个月要修复的问题？
step1:观察者和主持人每个人提出自己认为的3个最严重的问题
step2:汇集成10个最严重问题列表
step3:根据优先级和排期得到下个月要修复的问题清单
问题又来了，如何界定重要性？
根据下面的图，“可以根据问题出现的频率，影响大小以及持续性来判断”
一大波问题即将袭来，发现的可用性问题要如何修复？
有以下几个建议：
1.微调，而不是重新设计
当我们发现问题，直觉反应是重新设计整个页面或者功能，完美改进所有问题。但是“天下没有白吃的午餐”，完美意味着更长的排期和更多的设计开发量。我们可以通过找到修复问题最简单的修改，对产品进行微调，快速验证修改是否有效。
2.尽快，而不是等待大改版
我们遇到问题，经常会用一个说法，“等到xx改版的时候，一起做了”，xx改版往往是个比想象要漫长许多的时间，很多发现的问题就不了了之了。如果发现的问题都不能得到解决，还有多少人愿意坚持做这件事呢？
3.做减法，而不是加法
当我们发现用户不理解我们要表达的内容，最先想到的方法是添加更多的说明，来详细的解释这个内容，但是很多时候，用户在网站上跳跃式的浏览，可能是干扰信息太多，而不是说明信息太少。最好的设计不是加无可加，而是减无可减。
4.微调，但要验证
微调之后，调整的方式是否有用，需要再次验证。如果只是把按钮放大这类，可以随便找个人看一下是否能关注到你调整后需要他注意到的信息。如果是大的挑战或者多个微调，那就需要加入到下个月的可用性测试中，看看是否有效。如果有效，需要看看是否会影响到之前的功能，如果无效，那就尝试用过一个系的微调。
