时间: 2021-07-30 11:09:17 人气: 1 评论: 0
本文作者结合自身经验，并按照实例来分享下可用性测试的具体做法，enjoy~
用户调研分为两种形式，一种是定量，一种是定性。
定性的方式里面又包含可用性测试、用户访谈。可用性测试是用户调研中一种定性研究的方法，让产品更好的服务用户，可以说是一种低成本高回报的一种研究方法。
今天我主要通过以下几个层面来讲解可用性测试的亲身操刀经验：
一. 什么是可用性测试
1. 什么是可用性测试？
2. 可用性测试的好处是什么？为什么有很多公司不用呢？
二、可用性测试的具体流程及注意事项
1. 需求收集
2. 资料准备
3. 用户招募
4. 测试脚本设计
5. 预测试
6. 测试开始
7. 输出分析报告
三. 什么是ASQ？什么是SUS量表？
1. 关于ASQ
2. 什么是SUS量表？
四、可用性测试一般在什么时候进行？
五、什么功能适合做可用性测试？
六、总结
可用性测试，是通过观察有代表性的用户，完成产品中的各项任务，界定出可用性问题并解决这些问题。展开来讲就是：观察代表性用户；完成所测产品的典型任务；测试出产品有哪些问题；解决问题
举个例子：
拿咪咕圈圈的弹幕功能来说，用户通常在什么场景下**使用弹幕，在使用时是否能熟练使用以及是否对弹幕功能有自己的意见或不满？
测试出的产品问题：
解决问题：
第一种情况是，他认为我的产品没问题，用户都**用，不需要做可用性测试；第二种情况是压根没有这个意识，也不去了解学习，就这样用户离她们越来越远，过上YY的生活；第三种情况是，有意识去做，但不专业，害怕做不好，不知道怎么入手
有人又要问了，可用性测试很重要吗？当然重要。是必须要做的吗？也不是。因为并不是每次迭代更新都要做可用性测试，**很浪费时间人力成本，可能效果还不好。
那为什么可用性测试又如此重要呢？因为它可以让你接近真实用户，除了给你带来某功能的具体使用情况外，还可以带给你更多的用户信息。很多时候，可用性测试就是一次小型的用户访谈。
整个可用性测试可以分为以下几个阶段：
通常在进行可用性测试之前，用户研究员**去向产品经理、设计师、运营等人员收集他们的需求，当然，也可以用盐组内部提出需求，通常都**有专门的需求收集模版，让相关角色根据模版填写即可，然后进行整理汇总。
用盐需求模版基本包含：
在测试之前，一定要做好资料准备
一个是设备资源，当然不是专业的测试实验室，拥有各项专业设备、录音设备、观察室等，这种测试环境距离我们比较遥远。对于普通公司来说，实际上不需要非常专业的测试设备。通常情况下只需要2台电脑、2台手机。
如果是测试PC端，那完全可以用QuickTime等录屏软件，不仅可以记录操作，还可以录音；如果是测试iOS移动端，最新的iOS系统已经自带录屏软件了，老系统的话可以数据线连接电脑，通过QuickTime来显示并录屏；如果是安卓机，可以在应用市场下载录屏软件。
为什么要2台电脑2台手机呢？
因为1台电脑用户做测试用，1台是观察员记录笔记用，可以把问题直接记录下来，以免后期再重复且记不清。手机的话，1台做测试用，1台录音用，当然也可以用录音笔
除了测试设备之外，还需要准备一些小礼物。
礼物根据做测试的用户来定，如果是同事或朋友，耽搁不了很久的，买点小礼物意思一下即可；如果是你的目标用户，还很费时间，那投入就大了。
礼物注意事项：礼物可以提前送，打消用户心理的顾虑和隔阂，能快点进入状态，用户拿到礼物后，**比较敬业的完成测试，毕竟拿人嘴短。
很多人不知道在招募用户的时候，招多少人合适，也没有对用户进行区分，所以我们需要了解招募用户的正确方法：
（1）招募5个用户
尼尔森博士说：有5个人参加的用户测试，就可以发现85%左右的产品可用性问题。
为什么5个就够了呢？Jakob Nielsen博士统计了尼尔森集团在2012年做的83个可用性测试项目发现：参与可用性测试的用户越多，并不能发现更多的问题。
（2）招募目标用户
做可用性测试一定要招募目标用户，不是真实用户的话很难融入到场景当中，反馈给你的没有太大帮助。还有一点是，招募的用户需要有能力并且有经验完成任务，而且有一定的动机来完成。
举个例子：
咪咕圈圈是一款偏向二次元用户的产品，那么在招募用户时，就需要招募对二次元感兴趣的用户，喜欢看二次元的内容，即有一定动机来完成任务。
如果项目很简单，只想测试一下项目的交互流程是否有问题，为了节约成本，可以找其他部门同事来帮忙，做肯定要比不做要好，避免后期开发阶段发现太多问题导致推翻方案或项目延期
招募用户时，还需要做用户筛选，用户一般分为：小白用户、大众用户、深度用户，如果只招募其中的一种，那么结果很定**有偏差。小白用户对于行业不了解，像一张白纸，很难提出建设性意见；专家用户对产品足够了解，他**去关注各种细节，所想的范围**出了普通用户的范畴。所以在招募时，这三种用户都需要招募，这样能反馈更多有效的问题。
（3）招募用户有哪些途径呢？
对于B端产品来说，用户招募不是问题；对于C端比较简单的可用性测试，直接找内部同事即可，最难的是C端真实用户的招募
基本上有以下几个方法：
举个例子：
近期在做的项目，需要找初高中生群体测试产品的核心功能，我们首先在公号、app的banner区域宣传，还有运营部门的外部支持，以及可以汇集初高中生较多的地方宣传招募，成功征集到6个真实用户做测验
任务的设计，是整个测试的关键点，任务设计的好坏决定了后期的成败。
（1）首先要明确测试的目的，这个一定要牢记
（2）确定测试的功能
在设计任务的时候，一定要明确本次测试的重点是什么，这个在前期收集需求的阶段就要明确，一个模块包含很多个功能，如果每个功能都测一遍，那用户也**很不满意，所以一定要有所取舍，而且最好在正式测试之前，先预测试一番。
关于测试的时长，最好控制在1小时左右，这样，用户也不**觉得烦
（3）任务设计要场景化、情感化
任务场景化，是测试人员很容易忽略的问题。设计任务时可能只简单描述一下任务，比如，打开咪咕圈圈app，在看动画的时候发一条弹幕吐槽一下。这样描述问题，很难让用户带入到场景中，结果就是简单完成了任务，但是不能给你反馈的建议。
那我们怎么设计呢？我们要营造一个气氛，让用户感觉身处在这个场景当中。比如：请选择一部你感兴趣的漫画进行观看，在观看的过程中你发现有一个画面很有趣，想发表吐槽，并且分享给你的好友
（4）任务设计的数量
在设计任务时，经常容易设计的任务过多，前面讲过，1个可用性测试最好在1小时内完成，时间过长的话，用户的耐心和配合度都**减弱，1小时内完成3－6个任务是比较合适的。如果每个任务都很重要的话，可以分成2次来测试，先测一部分，剩余的并入下一期来测；或者是本期测完，但真对某些任务只测部分用户
预测试是指把测试设备、测试脚本都准备好，按照正常测试流程走一遍，尽可能的模拟真实环境，主持人要讲完所有的串词，注意不是拿稿子念，观察员要看完用户操作全程并记录，如果真实测试是在户外进行，还要考虑Wi-Fi不良的情况。
预测试的结果也要写进分析报告中，非百分百的真实用户提出来的体验问题也是具有参考意义的。
预测试结束后，需要问一下被测用户在整个流程中是否有不适的地方？哪些环节是我们需要完善的？主持人和项目组讨论复**整个流程和所有文档。
复**后改动的工作量可能比较大，所以预测试和正式测试最好不要放在同一天进行，这样有比较充足的时间修改和打印资料。
测试的时候总**有一些意想不到的情况发生，比如忘开录音、录屏，测试人员经常**偏离测试任务等。
那么在测试进行时，需要注意哪些问题呢？
（1）关于测试人员
测试人员最好2个，不要**过3个，为什么不能**过3个呢？可以想象一下一群人围着你看你完成任务是什么感受。人太多**给测试者带来心理压力，选择座位的时候也要注意，让测试者坐主要位置，让被测者有一种主人的感受，最好不要面对面做，要有一定的角度。
测试人员分为主持人和观察员，有人**说，一个人岂不是更好？其实并不是，一个人的话往往**让气氛比较尴尬，有时候你都不知道该说什么了，或者出了问题没人提醒你。
主持人最好是项目相关人员，比如产品经理、交互设计师，其次，主持人最好具备良好的沟通能力和随机应变能力。
主持人需要注意用户在做任务时的操作和我们预想的不一样而打断，直接引导他们完成任务，这是测试中很忌讳的，对于新手主持人一定要亲自跑一遍流程，主持人要和蔼可亲，不要板着脸，最好和用户成为朋友。
观察员要默默降低自己的存在感，跟用户打招呼，介绍自己，然后坐一边默默观察全过程，并记录发现的问题。观察员切记不要直勾勾盯着用户，**让用户感到紧张不安，除了在专门的提问环节，不要随意打断测试插入问题。
如果很多人都想参与测试呢？我们可以轮换着听，或者把测试后的录音录屏等资料给他们
（2）测试的环境
最好找一个相对安静、不**被打扰的地方进行测试，以防被测者被外部环境打断和围观，如果使用产品的场景就是在户外或者公共场所的话，那么要保持和使用场景一致或相似。
（3）暖场
暖场是指测试前的简单介绍，包括自我介绍、本次测试的目的、缓解气氛，把用户带入测试场景。可以和用户聊聊被测产品相关的小问题，平时怎么用的？一般什么时候用？感受怎么样等等
介绍测试时，一定要强调，我们测试的是产品，不是用户本人，告诉用户本次测试大概需要多久时间，让用户有个心理准备。但尽量少说一点，比如可以说这次测试大概需要半小时，但实际上可能达到1小时以上。
还需要告诉用户在测试时**录音、录屏，便于后期整理，但是一定**对测试资料进行保密。
还有一点一定要告诉用户：在测试期间您有任何问题，都可以问。但我可能不**立刻回答，因为我想知道大家在没有旁人帮助的时候**如何做。如果测试结束后，还有问题我将尽最大努力做出回答。
（4）发声思考法
发声思考法是指：用户一边操作，一边说出心里的想法，有些用户不太懂，测试人员可以演示一下。这样的话我们方便了解用户的真实想法，了解用户和我们的任务是否偏离，反馈更多我们意想不到的信息。
有时用户进行测试时，默默的完成了任务，忘记了发声思考，我们可以以问句的形式去提醒用户：
（5）不要对用户进行指导
有时用户在做任务时，不知接下来如何操作或者问你该怎么操作等，有的测试人员觉得被测者很笨，实在受不了，直接告诉用户。这是做测试时的大忌，我们需要时刻记住，我们测试的是产品，不是用户。
当用户偏离你的任务时，你可以提醒下用户；当他不知道怎么操作或者某个地方是否能点击时，你可以鼓励用户去尝试下，而不是立即告诉用户答案
（6）时刻观察用户
在测试时，需要注意观察用户的肢体反应和情绪、表情变化，并不时的问用户为什么感到惊讶、疑惑等。方便我们挖掘更多有用信息
在做完一个任务时，趁着用户记忆还比较新鲜，可以让他们直接说出来自己的体验或者不好的地方；在用户操作任务时发现用户有异常情绪但没紧跟着追问，可以在这时候补问。
（7）再来给大家简单归纳一下流程：
整个测试阶段的流程大致为：
分析用户测试数据，总结报告，推动完善产品，才是我们的终极目的。
具体怎么做分析报告呢？
根据我们前期的记录和录音录屏开始整理，把整个测试任务中遇到的问题和测试出来的问题记录下来，然后对这些问题作出区分：关键问题、重要问题、次要问题，然后将这些问题反馈给产品经理、开发、设计师，根据这些问题进行优化排期。
通常我在设计测试脚本时，**在每个任务后面，针对该任务进行一个小问卷调查，通常包含2-3个个问题，只需要打分即可，对用户来说很简单，辅助我们客观评价任务。
上图这个问卷，也可称为ASQ量表，即情景后问卷，是让用户完成一系列任务或者一个情景任务后，对产品进行可用性的评价。最好是完成1个任务后就开始回答一下，这时的记忆最新鲜，具体设置几道题根据具体情况而定，量表的分值可以设为5分。
ASQ问题涉及到可用性的3个方面：有效性（问题一）、效率（问题二）、满意度（问题三），问题如上图所示。
什么时候要用ASQ量表呢？可以让用户完成1个任务后填写，也可以完成全部任务后填写。如果这个任务不是特别重要，也可以不设置ASQ
2. 再来说说SUS量表。
SUS量表，即情景后问卷，量表一般由10道题组成，包括奇数项的正面阐述，也包括偶数项的反面阐述，要求被测者在使用产品后对每个题目进行打分，满分5分。
SUS的优势在于小样本量都能得出较为准确的结果。
SUS量表题目如下：
当参与者完成问卷之后，我们开始打分，奇数项的记分采用原始分数－1，偶数项得分采用5－原始得分，由于是5点量表，每个题目的得分范围是0-4，SUS的范围是0-100，故需要将每个题目得分相加后再乘以2.5，即可获得SUS的最终分数。
SUS的平均分数为68分，50以下是不可接受的，70分以上是可以接受的。
举个例子：
用户1的计算公式为：Q1（5-1）＋Q2（5-1）＋Q3（5-1）＋Q4（5-2）＋Q5（4-1）＋Q6（5-1）＋Q7（5-1）＋Q8（5-1）＋Q9（4-1）＋Q10（5-1）=37
然后37*2.5=92.5，这样就得到了用户1的得分，再把其他用户的得分算出来，最后得出平均分为84分
在使用SUS量表时需要注意什么呢？
（1）10个题目中，有个别题目对参与者来说比较难以理解，比如2、5、6题，需要和参与者进行解释。也可以根据具体情况优化一下问题表达方式。比如第二题，可以改为：我认为这个产品太复杂。第五个问题可以加上文字说明：我觉得这个产品多种功能结合的很好（比如我想要的一些基本功能都有，并且很容易找到）。第六个问题加上文字说明：我觉得这个产品有太多不一致（比如文字提示不一致、点击某个功能后出现的页面和我预想的不一致）
（2）在使用时，需要把“产品”换成我们产品具体的名字，如“咪咕圈圈app”
（3）SUS问卷除了给我们一个科学的打分方法以外，还有助于我们对用户进行追问。
（1）产品开发初期
也被称为探索式测验，这时候是对初期概念在市场上进行验证，并评估这一概念的可行性及后期的如何运作变现
（2）产品实现中期
这一阶段主要是对某一功能的交互流程进行验证，看能否跑通，其次是对交互或视觉上不同设计方案的验证
（3）产品开发后期
主要是检验产品的性能、功能方面是否达到标准
（4）产品上线后
这一阶段主要是为下一次的迭代做准备，更加深入的了解用户群体对该产品的使用体验及意见反馈
PS：可用性测试能在初期的时候做，就在初期做，这样避免后期各种状况不佳导致推倒产品重来的危险，成本巨大。
目前我们在做一款新的app，在放手做前期，就开始做市场调研、用户人群定位，充分了解该项目从各方面都可做的情况下，才开始动手去做的。
在原型、视觉稿出来之后，**出demo给到被测人员做可用性测试，检查使用流程上是否麻烦、流畅等，从视觉上，是否有icon表意不清等问题，检查出问题后再去优化，然后才是程序开发阶段，后面还有阶段包来验证产品等等。产品上线后还要继续新一轮的用盐分析。
不是所有的产品和功能都要做可用性测试的，比如一个表单、一个字段的修改等等，是不需要去做测试的。
（1）新开发的产品，急需得到验证
我们需要对整个产品的核心功能做测试，来验证产品是否符合目标用户的需求，用户在使用中是否有疑惑
（2）功能变更。可能是操作路径的变更，也可能是功能入口的变更
比如对不感兴趣功能的交互，以前是点击之后出现弹窗，现在是长按直接拖出画面，部分用户已经习惯了之前的交互方式，需要对新的方式进行测验
（3）新增比较复杂的功能
有些功能**比较复杂，步骤比较多，这种情况也需要做一下测试，看看用户的接受度，看哪里需要做出调整
（4）设计阶段有争议的
当在设计前期，无论是交互层面还是视觉层面，双方观点不一致，谁也说服不了谁，或者拿不准到底用哪套方案，可以去做一下可用性测试，看哪种方案接受度更高
（1）讨论测试功能
从以下几个方面例举：
（2）通过功能优先级排序法来筛选本次测试的功能
通过给每个功能的重要程度和对于该功能的疑问打分，并且相乘得出总分，来突出每个功能间的分数差异。
（3）确定本次测试的功能
以上是我的个人经验，有了可用性测试的结果，在评审或者后期做方案时**比较有说服力哦~
可用性测试完成之后，记得抄送相关同事及领导，或者也可以内部现场汇报一下结果，让大家都有一定的了解。可用性测试是让设计师变被动为主动的有力工具，一定要用起来哦～
本文由 @ 安迪 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels，基于 CC0 协议
