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