#本文为人人都是产品经理《原创激励计划》出品。
结合可用性测试，产品经理或者设计师可以更加清晰地得到用户反馈，进而推动产品的开发或者后续的迭代优化。不过关于可用性测试，你究竟了解多少？比如在执行可用性测试时，团队是应该采取现场测试，还是远程测试？不妨来看看作者的案例总结吧！相信读完之后，你会对可用性测试有更深刻的理解。
用户测试俗称 User test，也叫 Usability test 可用性测试。
这是一种包含定性成分的定量研究。让用户使用产品的设计原型或者成品，通过观察、记录、分析用户的行为和感受，改善产品可用性的一系列方法。
当产品设计师做完设计方案后直接让程序员花大把时间开发上线，结果收到用户吐槽：“这是什么玩意！”“怎么这么难用！”那样整个团队会死得很惨，设计师也可以直接领大礼包走人了。
为了避免这样的悲剧发生，需要在开发之前来测试设计方案，及时接纳反馈，调整设计方案，保证产品上线后的用户体验质量，保证产品上线后用户反馈和数据表现与预期不会相差太多。
可用性测试可以在产品的任何阶段进行：
- 在产品设计初期，使用低保真原型，测试想法的可实施性、用户对产品的接受程度、对于产品基本功能和信息架构的反馈等。
- 在设计阶段，测试用户是否能够轻松达到目标，完成任务。需要有一个功能方面相对完整的高保真原型进行测试，但是对于UI的要求不高，只要有完善的功能就可以。
- 当产品已经基本完工在投入市场之前，已经有了开发出来的具体产品，用来测试产品质量是否达到了市场标准和用户期待。
- 在产品持续迭代的过程中，可以通过已经上线的产品测试用户完成任务的高效性或是因为市场需求变化，测试用户对于某一功能或整体产品的满意程度。
- 对于同一功能，有多种设计方案，这时候需要通过测试比较这些不同的设计方案，寻找最优的解决方式，可以在任何阶段进行测试。
- 主持人：用户体验设计师或者用户研究人员，需要对测试的目的、任务、原型、最后提问环节了如指掌。
- 被测试用户：大企业会按照他们的用户群招募被测试用户，小企业或者没有预算就可以从身边亲朋好友下手了。
- 观察者：只看不干涉，专心做记录观察，需要聆听被测试用户说的话，还要观察用户的使用过程、表情和肢体动作，实时记录下被测试用户的反馈点。
1. 现场测试
现场测试可以面对面接触用户，能够观察和记录所有的现场信息，相对来说简单一些，首先选择一个能够让用户较为放松的环境，可以是布置得比较温馨的会议室或是咖啡馆。
2. 远程测试
疫情期间，远程可用性测试优先被选择，在被测试用户和主持人无法出于同一空间，或者进行现场测试成本过高时使用远程可用性测试。
远程测试分为同步远程可用性测试（主持型）和异步远程可用性测试（非主持型）两种：
- 同步远程可用性测试：利用视频会议和共享工具进行测试，测试者实时观看用户的操作流程，观察被测试用户与产品的交互，并针对被测试用户的操作提出后续问题。
- 异步远程可用性测试：不需要和被测试人员进行视频或通话，需要被测试者自己通过录屏将操作记录下来，事后发给测试人员。
无论是现场测试还是远程测试都有对应的优缺点，要根据自己的实际情况进行选择。
以本次可用性测试为例：需要测试用户是学校老师，产品需要测试的时间正好在学校放暑假期间，加上疫情没有办法进入学校找到老师进行现场测试，并且教师布置作业习惯有地区差异，出差到学校调研和把全国各地老师汇合在一起进行测试都不现实，所以选择线上远程测试。
测试目的
明确做本次可用性测试是为了验证或者获取什么信息，以目标为导向，首先确定要测试的产品是什么，希望得到什么样的结论或预期，并确定产品测试的范围。
举例本次真实可用性测试场景。
本次作业产品可用性测试的目标是：为了验证作业模块的用户体验是否能满足老师在工作中轻松获取作业学情，是否有违反用户交互体验的问题，是否可以在日常工作中常态化使用，帮助用户降本提效。
新用户的用户目标是全新产品带来的学习和使用成本，包括两类：
- 没经验：对类似产品0使用经验，新手学习成本足够低；
- 有经验：对类似产品有使用基础但没用过我们的新产品，使用成本不比竞品高。
对于老用户的用户目标：用过类似产品，不可忽视且必须额外要考虑对老用户使用习惯的改变。
原则：
- 功能完整性：模拟用户任务流，主流程和常见分支流程有支撑不阻塞；
- 产品易用性：流程走通的前提下，操作步骤尽量少，认知成本尽量低。
确定参与测试的工作人员，有的公司有专业用研，可以用研同学带着相关产品和设计一起进行。若没有专业用研，负责该项目的产品和设计同学也可以独立进行，周期在1-2周，可以空出独立时间，也可以穿插在日常工作中。
由于我们公司没有专业用研同学，每次可用性测试都是产品和设计一起主导并完成，整个测试工作安排如下：
- 第一天：产品同学负责联系运营寻找样本，并分配给各个组，平均一组4-5位用户；设计同学撰写测试评估样本和任务卡片。
- 第二天：每个小组收到分配到自己手里的用户进行拉群，和用户沟通并确认时间，熟悉测试流程和测试任务。
- 第三、五天：开始进行测试，一组两人，一个担任主持人，一个担任观察者。平均一天2-3位用户，一位用户用时30分钟-1个小时，访问结束及时进行总结整理。
- 第六天：大家分模块进行总结梳理。
1. 测试脚本
为了防止在测试访谈过程中迷失方向，要提前制定好访谈大纲的结构和关键要点，增强对整个访谈的把控感。提前写好测试评估脚本，标注任务流程、任务要关注的重点以及预估时间，可以保证我们在进行测试中更好把握测试节奏。
测试脚本包含：主持人大纲（测试前访问热身、基本信息提问、正式测试任务、体验访谈）；观察者大纲（根据主持人大纲同步整理，观察并记录用户完成任务过程）。
2. 招募用户
用户数量在6-10名用户参与，一般这个数量就能够发现测试里的80%的问题，继续找更多的人结果也是差不多的，需要确定使用你产品的用户群体，选择用户尽量选择沟通意愿强、愿意思考发声的用户。
招募用户的途径可以找公司内部渠道资源进行招募，像B端产品用户是特定属性，通常可以联系公司和用户的接口人进行招募。也可以自行在社会上招募，C端产品可以在公开平台发放招募问卷，或者找自己身边的亲朋好友进行测试。
本次测试样本通过驻校运营同学联系到了学校老师，包括初中、高中、文科、理科共13人，覆盖了全部类型教师。
招募要求需要使用过线上布置作业功能的老师（各种产品都可以），有使用类似系统经验的老用户，和没有使用经验的新用户，使用频次深度浅度均可。
联系到用户后，在微信上把相关同学拉群，方便和用户进行沟通，并更改群名称为【XX用户-XX产品测试-8月3日下午1点】人 事 时间，在群里预约好访谈时间，询问用户平时使用过哪些线上视频软件，腾讯会议、飞书会议均可。如果没有使用过类似系统，告知用户提前进行下载。
3. 测试设备
最好让测试者使用自己的设备，可以让结果更准确，这个设备是测试者在真实生活场景中早已熟悉使用的，陌生的设备会增加测试者的学习成本，可能导致结果产生偏差。
比如iOS用户和安卓用户，Windows用户和Mac用户，他们的使用习惯有很多不同。
另外一定要进行录音录屏存档，方便后期回看。
本次测试是远程测试被测试者使用自己的电脑进行操作，环境也是选择自己熟悉的环境。
4. 准备物料
- 交互原型，确保测试流程为可点击的完整闭环，本次交互原型使用Figma进行交互操作，提前测试在不同机型和各个网络、浏览器中都可以顺利打开并进行点击。
- 录屏录音，面对面测试需要准备录音笔和拍摄设备；远程测试使用会议软件，使用软件自带的投屏和录制系统。
- 准备任务卡，面对面测试需要提前打印好，测试时发给用户；远程测试提前编辑好每段文字，随时在群里粘贴复制给用户。
- 测试礼品，测试结束后准备一些小礼物送给用户作为酬劳（根据每个公司不同政策准备即可）。
需要提示用户提前下载好腾讯会议或者飞书等自己使用过的会议软件，确保测试环境网络没有问题，测试使用的交互体验原型提前发给测试者，直接使用浏览器打开就可以，被测试者投屏演示操作即可。
在体验到某个任务节点时口头描述一遍给用户，再复制到微信群，并且在结束后为每位用户申请了100京东元作为测试礼品。
八、测试中执行1. 访谈热身
开场有礼貌地打招呼，并向用户介绍本次测试的背景、目的以及接下来的测试流程，以及整个访谈时间。整个过程中给用户营造轻松自然的氛围。
举例：非常感谢您抽出宝贵时间来参加我们的访谈，整个访谈测试时间在30分钟-1小时，背景是我们现在计划开发一个服务于校内作业和小测验的练习模式，目标是让老师更轻松地获取作业学情。接下来主要基于我们初步的设计方案，听听咱们老师的使用感受和建议。
2. 用户情况
接下来询问用户的一些基本信息，聊一下用户有没有使用过类似产品，对于竞品有什么想法，对于这一类型产品的哪些功能好用等。观察员进行详细记录。
首先询问基础信息，主要包括：姓名、地区、学校、教龄、年纪、任教学科、身份；然后请问您平常的作业、测试、考试有使用过什么线上产品吗？你平时会布置什么样的作业？作业的内容来源是什么？最后有什么推荐和吐槽的地方比如：哪个产品的什么功能好用？哪个地方不好用？为什么？
3. 发放任务卡
我们需要给用户模拟一个真实使用场景，以创造一个实际场景的方式告诉用户任务，用户就可以通过自己以往的经验，带着生活实感，更主动地使用产品。
通过制作任务卡的方式来进行模拟场景，以假设一个什么样的场景、要达到什么样的目的、取得什么样的结果作为任务卡的模版。
如果是面对面测试可以提前打印出来，在测试时发放给用户；远程测试把剧本化任务复制黏贴至对话。
本次可用性测试由于是线上测试，没有办法给用户发放纸质任务卡，首先口述一遍给用户，随后在微信群复制粘贴任务卡的内容，以防用户忘记任务，可以快速查看。
4. 体验并记录问题
观察并记录用户的行为，并在一个单任务完成后，提示用户稍事休息，然后提问《单任务满意度问卷》中的问题。
此时可以回答用户操作过程中的疑问，也可以藉由操作中的细节做延展发散，询问用户操作感受。通常可以获得很多针对该单任务的意见和建议。
这些意见和建议后续就需要记录整理，作为优化任务，帮助提升产品可用性和易用性。
- 不要主动引导用户：测试过程中，主持人给出任务和场景后，应当让用户自主操作，用户碰到困难不知道下一步怎么做的时候，主持人要让用户说出他们的想法，说出困惑的原因，不到万不得已，千万不要教用户下一步怎么做。
- 记录用户行为：操作是最直观、真实的反馈，观察员需要详细记录用户的操作点。用户会因为不好意思吐槽产品而给出虚假的反馈，而动作行为不会骗人，所以要减少对测试者语言上的干扰，多观察用户的动作行为。
- 观察用户的表情：在操作过程中，用户会下意识地发出一些声音和微表情动作，这些细微的反应需要注意。
- 把握访谈节奏：可能会面对用户会一直说大量和访谈不相关的问题，面对这种情况需要及时制止。
实际老师点击流程：
老师先点击日常测练按钮，然后点击新建练习按钮，在找不到练习题的入口后，又返回首页，点击了扫描仪读卷。
观察记录过程中的疑惑点：
- 答题卡模板匹配，老师提到如果是自己，只看标题！其他老师通常看到蓝色就会点，不会认真看是什么。
- 学校里有个老师统一发布作业，会把全年级班级都勾上！其他老师不会关注或处理这个。
- 作业的答题卡版式，高中数学题量很大的，尽量减少非试题的占用空间给学生去写。
- 完成电子化的，尽量会使用带题干的版式去使用。
- 希望选择题批改留痕，数学因为选择题少会出成填空题，手批！原因是希望题干、学生作答、批改痕迹评语等在一张纸面上显示。
- PDF格式，题目质量非常好，手抄下来，一般的话就换一张试卷。
- 练习班级，学校要求全年级一样的，不能出现不一样的会出问题的！
- 周考考试时间是统一的，作业不会每次做完每次出，有的话就是全年级一起出好了。
- 默认一个年级都用，扫描看老师个人情况是否勤快，要不要一起扫描了。
- 但是编辑分值入口，艰难找不到！找了半天只看到了编辑题目，无奈点进去发现可以改！
- 修改分值，应该是去题目、改题干的地方去修改！主要是没有按钮，只有蓝色的字可以点
- 模拟了一下修改客观题答案、修改题型，老师看不到蓝色的按钮文字，不知道可以点！
- 对于样卷和学生卷放进去扫这件事表示能理解，第一反应有点担心样卷和学生卷放进去扫会有一次送两张纸的情况。
5. 体验后访谈并记录
用户完成任务后，主持人需要向被测试者提问来总结和再确认用户的使用体验，问题要与被测试的目的对应。
提问题的时候问题要明确，不要问含糊不清或者用户不好回答的问题。也避免问抽象的包含多种可能的回答，这样容易让用户不知道该从何说起。多用开放式问题增强用户的表达欲望。
整个流程中哪个环节最麻烦？对比同类竞品，我们的产品有什么优势？我们有可以把作业/测验的成绩发送到家长手机里的功能，您倾向于默认每次都推送还是每次设置是否推送？还有什么建议吗？
九、测试后总结1. 问题汇总
测试完成后，趁着记得内容，快速把问题进行整理，如果有录音或者录屏可以重新进行回顾。
主持人和观察者需要一起进行总结分析，测试结果往往会出现大量问题，零散的问题不方便进行分析和归纳，需要按照测试任务或者页面进行分模块，在每个模块下，罗列用户好的反馈以及不好的反馈。并根据不同模块整理，把问题总结归类，并给对应问题进行分类，区分哪些问题可以优化，哪些问题不是体验类的问题。
当问题总结归类完成后，引入「用户体验八阵图」来对应相应页面，让我们能够更直观地了解到现有项目中精细到单个页面中所面临的用户体验设计问题。
这样一来，可以快速发现体验问题最多的是哪个页面、体验问题最严重的是哪个页面、体验问题中哪个模块的问题最多等。最后输出本次可用性测试的测试报告。
1）步骤：找到扫描入口
2）预期结果：用户可以顺利找到扫描教辅入口即「扫描仪读卷」
3）实际问题：绝大部分用户可以顺利找到入口；个别用户选择「日常练测」（2/12 都是教研）
- “老师直接点击日常测练，新建练习，找不到教辅入口。（反馈：因为说是作业场景，所以第一反应点击了日常测练）”
- “在大首页认为扫描应该在学情前面，因为是先扫描后看到学情”
4）问题点：用户理解场景需求是要完成一场练习，认为在「日常练测」中可以完成任务
5）影响因素：用户受背景描述影响
6）用户建议：“老师可能存在帮助其他老师扫描，不知道是哪些班级。建议默认发布到全年级，或是扫描后确认一下班级是哪几个”
7）问题类别：易用性问题
8）优先级评估：P1
得出结论：考虑是否要在【新建练习】中增加扫描教辅入口 ，先不加，再看反馈。
2. 可用性量表
使用SUS可用性量表来进行量化，在可用性测试结束后，用户快速完成各个题目，不进行过多思考。
整个问卷共10题，每题5分，奇数为正面描述，偶数为负面描述。填写之前不要进行总结或讨论，应当要求用户快速完成各个题目，不要过多思考，如果用户因为某些原因无法完成其中某个题目，就视为用户在该题上选择了中间值。
计算SUS得分的第一步是确定每道题的转化分值，范围在0-4。
对于正面题（奇数题），转化分值是量表原始分减去1（Xi-1），对于反面题（偶数题），转化分值是5减去原始分（5- Xi）。
所有题项的转化分值相加后乘以2.5得到SUS量表的总分。所以SUS分值范围在0-100，以2.5分为增量。
将得到的SUS的原始分数，对应到下图表格，即可得到产品的可用性程度。
经历多次实战经验，对于可用性测试的注意事项总结三个重点：有目的性、可以灵活运用、持续测试。
1. 有目的性
可用性测试可以帮助团队优化体验路径，明确用户使用产品时的体验感受；帮助设计师进行设计验证。
2. 灵活运用
完整的可用性测试从筹备到进行，从任务到结果，每一个细节都需要考虑到位，在过程中尽量保证流程规划清晰，文档整理完整，分工明确到位。
一说到这里很多小伙伴就会望而却步，觉得自己公司没有专业用研团队、招募不到测试者、申请不下来被测试者到酬金和礼物……
其实也可以灵活运用可用性测试，在没有条件进行专业可用性测试时，可以在设计过程中多次使用简易可用性方法，只要能解决问题就可以。只要了解一些必要的注意事项，产品经理和设计师也可以自行完成简单的可用性测试。
比如这次可用性测试中，就是由产品经理和设计师发起配合，一起担任观察员或主持人，在对测试反馈的问题进行优化的过程中，也是团队通力合作，推进迭代快速进行。
3. 持续性的
可用性测试不是进行一次就结束的一场表演。而是结合产品进展情况，可持续实施的一种有效的快速验证方式。
可以在设计过程中进行简易可用性测试，节约成本，并且面对简陋的原型用户更愿意大胆评论给出结语。
不过简陋的测试原型会使用户没有办法真正完成整个操作，一些设计的细节测试不到，建议在设计过程中进行多次简易可用性测试。在新产品上线后或者重要功能上线前进行比较正式的可用性测试，发现细节层面的问题。建议周期性进行可用性测试，取得一些结果后立即应用于产品，隔段时间再次验证，形成良性循环。
我们日常工作会接触大量设计方法论，可用性测试只是其中的一种，只是简单地了解这些方法论的概念是远远不够的，需要不断进行实践，在事情上不断磨练积累经验，才能真正体会到这些设计方法的魅力。
并且在工作中也要学会灵活运用理论方法，更容易达到事半功倍的效果，长此以往不断实践打磨，形成自己的一套工作方法。
参考文献
- https://mp.weixin.qq.com/s/ZLx4BYsZToWuq49whf2dqA
- 教你如何进行可用性测试
- https://mp.weixin.qq.com/s/65j8kuahKeQg0zfmatvF4A
- https://mp.weixin.qq.com/s/9Saf7NyEODWDw8oArULIpg
- https://mp.weixin.qq.com/s/QMgzae_aAAPNNrGNhsUKsw
- https://zhuanlan.zhihu.com/p/159871425
- http://www.woshipm.com/ucd/9748.html
- 深度总结可用性测试（上）：远程可用性测试
本文由@郭大毛毛设计笔记 原创发布于人人都是产品经理，未经许可，禁止转载。
本文为人人都是产品经理《原创激励计划》出品。
题图来自 Pexels，基于 CC0 协议
,
