教你如何进行可用性测试
最近在公司也主导了一次可用性测试，有一些实质性的收获，赶紧给大家来分享下可用性测试的整个过程。
我把整个测试流程分成前、中、后、三个部分，对大家理解整个流程会清晰一些。
一、可用性测试是什么
1. 国际标准ISO
可用性的概念是指：“特定的用户在特定的使用场景下，为了达到特定的目的而使用某些产品时，所感受到的有效性、效率及满意度。”
根据ISO的定义，同时满足了以上三个要素，才能称得上是实现了产品的可用性。
然而，在实际操作中往往因为开发周期紧张而无法全部满足，这时的解决方法是，首先解决有效性问题，然后在时间和成本都允许的情况下，尽量解决效率和满意度的问题。
二、可用性测试的目的
可用性测试的目的一般就是这三个有效性+效率+用户满意度。
但是我们通常开发周期紧张的时候无法完全满足这些需求，那这时候首先考虑的就是有效性问题。在时间和成本都允许的情况下再解决效率和满意度。
而在这三点的基础上我们当时还会有这三个问题：
- 预知风险、对抗风险
- 获得一手信息
- 发现问题、甄别问题
因为因为工期紧，对接方多，经验少，投入大 ，需要提前预知风险，而且我们设计师其实一直是对接处于后面一点的角色，想要看下用户的真实反馈来验收自己的产出，所以整个过程就是一个发现问题解决问题的过程。
三、可用性测试方式的选择
一般可用性测试有两种方案，我们团队采取的是形成性的可用性测试方式。
1. 形成性
我们基于当前的资源很显然选择形成性的会方便很多。
为什么要用形成性的可用性测试的方式呢？
首先它只需要 3 到 5 名的用户参与测试。然后测试的时间大概为两个小时，当天其实就可以汇总出结果。而且我可以根据产品的迭代进行一个可用性测试的，整个的一个空间和资源的要求都比较宽泛。
2. 总结性（这种可以委托给乙方做）
了解一下总结性的可用性测试。这个主要是针对于比如说第三方或者是乙方公司，益普索、普华永道专门做市场调研的公司，针对你的这个用户进行大量的投放，那这个成本就会很高了。
所以说咱们在工作当中，如果说设计师自发的话，还是建议这个形成性的可用性测试。
四、可用性测试的原则
可用性测试其实是我们请用户来，然后观察他们使用我们的产品。这里的使用不是指漫无目的的打开产品浏览，而是有针对性的对某一个或是某几个流程进行使用。
所有开始可用性测试的第一步就是“给用户找点事情做”。
那给用户怎么找点事做也是有讲究的。
1. 剧本化任务
因此，我们需要把任务润色成用户一个实际的使用场景。例如，周末你在b站看直播，逛到这个直播间，觉得主播的直播内容很有趣，你的账户里有8000金瓜子，于是你决定给这个主播投喂礼物，预算大概是3000金瓜子左右。
如果像这样以创造一个实际场景的方式告诉用户任务，用户就可以通过自己以往的经验，带着生活实感，更主动的使用产品。只有用户更主动的使用，更主动的思考，可用性测试的流程才能进展的更加顺利。而不是机械化的，布置任务完成任务的循环。
2. 明确任务起点与目标
什么叫明确任务的起点和目标。
比如说这三个页面。进了这个房间完之后他觉得这个剧本还不错，想找一些朋友过来玩。任务目标唤起分享，分享好友。只要分享成功就可以。
3. 锁定任务
- 任务二：房主“进入房间后，一个人太过无聊，于是你决定分享房间以邀请一些好友进来。”
- 任务起点：剧本杀房间页
- 任务目标：微信/QQ对话窗口
4. 给任务设置约束条件
- 不要使用搜索（测试搜索的时候除外）如果使用搜索完成了测试目的，那么就会变成了搜索是否可用的测试。而测试不到实际的功能点。如果参与者忘记了这一点，并试图使用搜索，你可以提示他们：测试中不希望使用此功能。
- 留在产品内，这一点一般不需要特别指出，只是遇到测试者试图离开产品的时候，需要稍作提示。别忘了后续追问，用户为何会想要离开产品。
- 不私下交流，因为我们要模拟线上环境，所以不可以私下交流，需要在线上房间内去交流
五、测试前的准备
1. 招募用户
尼尔森博士曾经提出“有5个人参加的用户测试，即可发现85%的产品可用性问题。”大部分可用性测试的经验是一次测试招募3名左右用户。
（1）用户的数量
根据尼尔森说“有5个人参加的用户测试，即可发现85%的产品可用性问题。”大部分可用性测试的经验是一次测试招募3名左右用户。鉴于我们产品的特殊性，一组的用户定位4-5人，符合大多数用户场景。
（2）招募标准
专业用户（4-5）：
- 专业+置信度高（直播设计+产品）；
- 高玩（经常使用产品的用户）。
有竞品使用经验，不是产研开发同学，好处是因此目标用户遇到的问题更有参考价值或者目标用户具备其他用户不具备的专业知识。
如果你希望严格按照目标用户来招募测试用户，你需要注意以下几点：
- 根据测试目的来定，找出与测试目标有关的筛选维度。
- 特别考虑用户使用行为相关的特征，例如竞品使用经验，使用产品的目的，用户活跃程度。
- 挑选最核心的维度，转化成用户的招募条件，并尽量客观化、具体化、可衡量。
- 注意辨别用户信息的真假-伪需求。
自由招募（5-6）：
总不能为无法招募到目标用户而不进行可用性测试，对招募用户的条件进行适当的放松，多进行几轮可用性测试，显然才是更聪明的做法。只要规定好测试任务就好。
（3）招募渠道
- 公司内部非本项目产研的同学；
- 社会招募。
（4）招募方式
群发内容：
声探社试玩开始啦！想参加的同学可以扫码填写【甄别问卷报名表】即可报名。
除了基本信息，还需要设定一些甄别条件，比如有无产品使用经验、使用频次等问题，便于给测试用户分组测试。
招募要求：
- 测评对象：选择那些活泼开朗且沟通意愿强的参与者。在进行可用性测试的时候我们通常会希望被访者能采用“发声思考法”。
- 招募条件：有剧本杀的经验（最好）
- 参与人数：12名
- 任务：15个
- 测试时间：100分钟
2. 确定测试时间和环境
- 表单：系统可用性量表+用户体验问卷+任务评估量表
- 录音笔
（1）测试时间
- 测试准备时间：建议为期3天。准备相关物料、场地、测试任务，和向上同步等。
- 用户测试时间：建议为期3-5天。可短时间内容集中进行用户测试，或在工作日穿插进行测试。
- 结果整理时间：建议为期3天。用于整理测试信息、落实产品迭代任务、撰写总结报告等。
（2）测试地点
会议室（一人一间），提前预约会议室。
（3）拉群通知
开始前的最重要的意向就是把测试分组后的用户拉到群里，通知大家时间、地点、需要准备是事项和物品。同步一下是否都能到场。
3. 测试物料
线下环境我这次准备了：
- 操作设备：取决于目标用户群体主要使用的设备，自己的手机更新到软件的最新版本。如果需要测试音乐相关的功能，需要准备耳机。
- 录音设备：测试结束后需要进行详细的信息整理，录音资料可以帮助回忆沟通内容。可使用手机自带录音功能或专业录音笔。录音前必须告知用户，在征得许可后方能进行录音。
- 录屏设备：工具型产品的操作过程中涉及很多细节，录屏资料可以帮助工作人员进行问题定位。可使用电脑自带录屏功能，或录屏工具。
- 记录本和笔：测试过程中进行表格填写时需要使用。
- 统计文档：主要包括测试过程中需要填写的表格。建议打印n+2套，n是测试样本数量，另外2套备用。
- 测试酬劳：具体可根据公司政策进行准备。
- 如果远程测试，除了准备这么设备外，还需要准备远程在线协作软件。zoom、腾讯会议、飞书等。
4. 组织人员注意事项
（1）积极发问+时刻观察+及时记录
用户发出疑问的声音或者微表情，然后这时候你就要提出你的问题啦，比如说你可以适当的问一些，你这是怎么啦？然后你在想什么？你是在哪一个步骤，有什么疑惑吗？那你为什么要这样操作？但是切记注意语气，保证亲和力。还有不要揣度用户行为并抢先给予提示。比如，“这个部分您似乎觉得很难理解”等等。
观察人员尽量时刻观察用户和用户操作界面。比如：误操作了看可以观察用户是否可以顺利的返回测试页面，以防遗漏一些细节。
（2）保持中立
不回答，保持中立。鼓励用户表达对任务的看法，而不是直接提出意见。如果用户不顺利可以给予适当引导
（3）适当干预
如果在测试过程中遇到无法进行的情况，或者测试进度拖慢的情况，可以适当的干预。
（4）事后回顾
测试结束后，可以再次回顾过程中发现的问题。比如：参与者对于某些功能发表了看法，这时你可以层层挖掘，了解到底为何导致了他的这种看法。
或者错过了发问的时机，还有就是碰到了不善于表达的用户，可能没有及时表达观点。“您刚才在xx页面做了xx操作，能说一下为什么这么做吗？”
需要特别注意的是，一定要在所有任务全部完成之后再使用回顾法进行提问。如果在任务执行过程中向用户提问，很可能打断用户的操作，作为采访人员我们绝对不可以干扰用户对产品的使用过程。
六、正式测试
我们是150分钟的测试，提前和测试者同步一下，按照大纲来进行测试流程，及时调整问题，维持好现场的顺序，保留测试录音就可以。
1. 开场介绍
打招呼，说明此次访谈目的：
“您好，我是XXX。今天这个访谈主要是为了了解您对我们声探社的使用情况。测试的时间两个半小时左右。希望大家能积极的发表意见”
介绍一些试玩规则+简单介绍我们测试流程（完成任务-评价任务-最后反馈）。
“我们的测试流程主要是跟随着测试任务进行。进行每个操作前，都会发布任务；完成任务之后，会发放相应的量表进行填写，填写完成之后再发布下一个任务；直到所有任务完成，填写总结量表。
您的任何反应都对我们至关重要，请您在测试全程随时表达，我们将会根据您实时的反应、填写的量表进行整体性的评估。请大家记住，我们的目的就是希望大家提出问题。”
需要注意的是：
- 测试流程时间有限，必要时会我们介入Push流程。
- 除了游戏环境内，玩家不能在现实中交流，需模拟线上环境。
- “希望您能一边操作一边把您心中所想的说出来，特别是您要怎么样操作，为什么这样操作，这些内容对我们来说非常重要，也非常具有参考价值”。
- “虽然您可以在访谈中进行提问，但由于我们想知道用户的产品使用情况，因此可能不会马上回答您的提问，事先对您进行说明一下，希望您谅解”。
2. 简单热场
简单热场的目的：(活跃气氛)，等待手机调试。
- 询问用户背景以及产品使用情况。
- 让用户在执行任务的过程中说出正在思考的内容（发声思考法说明）。
- 确定用户的手机型号，app版本号。
- “您使用产品的经验有多久了？”
- “您玩过几次剧本杀，是线上还是线下的，有没有什么特别体验好的回忆能分享下吗？”
- “一般玩什么类型的剧本杀”
3. 测试任务、观察记录
给出任务，用户开始测试，完成任务之后可以停下来填写用户感受。
需求池（设计师）：
初始问题的积累，我和同事会根据二十一条可用性原则走查出我们当前的视觉和交互的问题。设置为任务。
任务设计（产品+设计）：
主要功能的流程，设计的原则参考第四点。
用户体验问题记录表（组织人员）：
随时记录用户提出的问题。
4. 任务评分
（1）辅助工具
这些使用顺序和方法【需求池】-【任务后评估量表问卷】-【系统可用性量表】-【用户体验问题记录表】。
（2）任务后评估量表问卷（用户）
在一个任务结束或者多个任务结束之后，我们会给当前的任务打分，比如说任务1，你觉得从1到5打一个分，5是特别满意，及时进行对任务的反馈，以防测试时间过长遗忘细节。
5. 事后访谈
如果发现访谈当时遗留遗留问题，联系被访者可进行简短询问感想、主观评价、期望等。
- “今天请您使用了声探社，请您谈一谈使用感受”
- “如果要综合评价今天的体验，十分是满分推荐，您给声探社打几分呢？为什么？”
- （未达到满意的情况）“假设现在我们要优化评分，您认为哪个部分应该最优先得到改善？”
系统可用性量表（用户）：
这个是在整个测试完成之后，就让他填写打勾的去评价的。
这个我之前用的是翻译版，会有用户打分相斥的情况，于是我整理出来了一份解释版，给大家参考一下。
6. 信息收集
需求优化表（产品+设计）：
我们会将所有的问题记录表，然后把它去排到整个的需求池里边，然后再分优先级组，可以再和产品经理再分优先级。
七、整理结果数据分析
1. 归类和分析问题
通过收集用户体验问题记录表，进行小组会议讨论，把问题总结归类，并对所有问题做一个统一的规范分类（例可优化问题保留，不是体验问题的舍弃）。
当问题总结归类完成后，下一步需要引入「用户体验八阵图」来对应相应页面，让我们能够更直观的了解到现有项目中精细到单个页面中所面临的用户体验设计问题，这样一来，可以快速发现体验问题最多是哪个页面？体验问题最严重的是哪个页面？体验问题中哪个模块的问题最多等。
2. 系统可用性量表
（1）系统可用性量表的使用方法
在填写的时候发现了一个现象，本来互斥的问题但是用户打分是一样的，这几说明用户没有好好审题，或者没有题解题目的意思，所以在第一场测试结束之后，更新了有讲解的表单，或者在填写问题的时候控制填写题目的进度并讲解。
3. 撰写报告
再得到结果和改版方向之后，可以把整个过程再次复盘一下，可以按照总分总的形式去梳理。同时报告一定要高度总结，高度概括，条理清晰。从发现问题 – 解决问题 – 过程中做的不到位的地方去梳理。
#作者#
郝小七，微信公众号：七酱设计笔记。蜻蜓FM高级UI设计师，5年工作经验。专注于体验设计，欢迎各位同学一起交流。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
