科技猎干货|产品经理如何进行可用性测试（下）
干货满满，请大家做好笔记哦~，今天这篇讲讲如何进行可用性测试，以及可用性测试的操作步骤。
那么该如何设计测试任务呢？
首先我们在心底里要树立一个认知：“设计测试任务是为了反应用户的实际目标，而不是我认为用户想要做的事”
确认认知以后，下面就是具体方法：
1、先列出一个任务清单，用简单的短句来描述测试中涉及的任务——，任务不宜过多，必须是重要的，核心的，比如金融产品你需要让用户充值、提现、登录、注册等。
2、在筛选完任务清单后，将任务变成场景——场景就是你要读给用户听，或者要给用户看的内容。因此必须要包含用户的目标和动机——因为对用户来说，你的功能并不重要，重要的是他们的目的以及他们完成目的的过程。这时候，你可以再问一次自己上面的问题。比如他的目标是购买定期产品，这个时候你就要观察他操作的过程，如果过程中出现问题，不要引导用户，记录下来就好，因为操作过程会出现问题，说明你设计的不好。
3、确定操作任务需要的条件：比如是不是需要一个新的账号，是不是需要准备好必要的文件等等；
下图是可用性测试的一个操作清单：
所谓的设计测试任务就是“谁在什么情况下要做什么”，要紧紧抓住“人”、“情景”、“目标”这三个要素。
预测试主要是为了发现任务设计的问题，可以找公司内的同事，利用午休时间快速完成，或者找身边的亲戚、同学，朋友，利用周末休息的时间帮你做一下可用性测试
三、招募用户
在设计好测试任务后，现在就该去找参与测试的用户了，
关于用户的数量，上一篇也说了，众多研究表明5个测试用户就能发现80%的可用性问题，当然如果你想去定量的进行分析，可以多找一些测试用户。
如何找用户？
在确定了甄别的标准和用户的数目之后，就可以着手找用户了。如果你是快速测试，可以找同事（同部门的同事就不要找了），朋友，朋友的朋友，网站论坛发广告等等，如果你想精确的测试，可以打电话，发邮件、在你的微信公众平台发布招募消息等各种手段向你的目标用户发出邀请。
对于来过的用户可以做一个可用性测试群。以后可以直接在可用性测试群里招募，但是要注意，不能经常邀请同一个用户，不能这个用户上次刚来，你又邀请了。比如A刚来过，那你就需要一个月以后再邀请。
测试一般需要一个主持人，一个记录人，负责主持和记录，如果资源不够，也可同一个人负责。准备好录屏工具和录音工具，测试的过程中进行录屏和录音，方便后面进行分镜式分析。如果你有专业的分析工具，比如眼动仪，也可以用上，后期可做热力图分析，当然小公司一般不会配置这些工具。
2、调节测试氛围
大部分的测试者在参加测试前都是紧张的，他们会担心自己无法完成测试任务等等。比如用户说“哎呀，找我测试呀，我做不来怎么办呀，我很笨的”，这说明他比较紧张，在给自己找后路，所以说，展开测试的第一步是缓和测试的氛围，消除被测试者的紧张情绪，你需要向他表明本次测试的目的，告诉他这是测试产品不是测试用户，让他别紧张。
3、开始测试
这个过程中需要做到“一看”、“二记”、“三问”、“四听”
看与记：整个过程中需要认真观察用户的操作过程，对用户有疑问、迟疑、困惑的地方进行记录。
问与听：用户完成一项测试任务后，需要问他在这个任务的过程中有没有碰到难以理解的地方，如果有，需要追问用户为什么难以理解，他最后是怎么理解的。如果你观察到用户在某个地方产生了迟疑 ，需要问用户为什么会产生迟疑，比如说，“我刚刚看到你在充值时犹豫了很久，你为什么会在这里犹豫呢”。在这个过程中你需要认真倾听用户的意见，并肯定用户的提议，这样会让他得到一种成就感，有利于接下来的测试。
测试过程中需要注意的问题：
测试过程中用户如果有什么想要表达的，邀请他表达出来，如果他太善于表达，需要进行适当的制止，让他回到测试任务上来。
识别用户情绪，在用户实在无法完成任务时，终止该任务的测试
不要以任何方式（手势、表情、语言等.表现出用户正在犯错或者操作太慢，需要明白这不是他的错，是你设计的问题。
用户遇到困难时尽量不要提供帮助，可以适当鼓励用户，比如“你可以再尝试一下”。
多问用户几个为什么，比如“为什么你刚刚会这样操作”、“为什么你会这样理解呢”等等。
4、记录其他问题
除了任务清单，在测试的过程中，还可能会出现一些其他有价值的信息，但这个信息并没有在你的测试任务清单中，这个时候你可以找张白纸记录下来，测试结束后可以在团队讨论的时提出来。
分为5个指标进行统计：
- “完成情况”
- “流畅度”
- “问题记录”
- “问题严重程度”
- “用户预期”
这里需要注意的是，统计的时候不要记录一个干瘪瘪的问题，要把用户具体操作场景记录下来，这样有利于分析用户为什么会产生这样的问题，对问题的改进有很大的帮助。
确定需要修改的问题
在将指标统计完后，接下来就是确定什么问题需要修改了。
统计问题产生的概率（如下图）：
将所有的问题列在一个excel表格中，谁出现了这样的问题就在谁下面打勾，然后计算出问题出现的概率（比如测试10个人，有5个人出现这样的问题，那么出现概率是50%），如果有及时的方案，在备注列进行备注。
确认什么问题需要修改（如下图）：
上图是一套判定问题严重性的规范，这个有助于去判定什么问题需要修改以及什么问题可以暂时不用修改。当然这并不能作为唯一的标准，因为它只是一个数据性的参考，实际过程中还需要进行定性的分析，比如说有的问题只有一个用户出现了，但是经过分析这的确是个问题；有的问题大部分的用户都出现了，但是这些问题只是出现在了用户第一次使用的过程中，后面就没有出现过了，改动起来的成本较高，这种问题我们称为可接受的学习成本问题。
针对需要修改的地方，可以团队讨论，然后将解决方案发给各个部门去执行，设计问题让设计解决，交互问题交给交互设计师去解决，产品问题产品经理自行解决。
总结：上面就是进行可用性测试的几个步骤，更多问题可加微信 yw5201a1 交流。
更多干货请关注微信公众号： chanpinliu880
