原文链接：https://mp.weixin.qq.com/s/OeniKBJbOR16dJeBDEnvig

可用性测试是什么

用户测试俗称 User test, 也叫 Usability test可用性测试。
这是一种包含定性成分的定量研究。让用户使用产品的设计原型或者成品，通过观察、记录、分析用户的行为和感受，改善产品可用性的一系列方法。

为什么要做可用性测试

当产品设计师做完设计方案后直接让程序员花大把时间开发上线，结果收到用户吐槽“这是什么玩意！”“怎么这么难用！”，那样整个团队会死的很惨，设计师也可以直接领大礼包走人了，为了避免这样的悲剧发生，需要在开发之前来测试设计方案，及时接纳反馈，调整设计方案，保证产品上线后的用户体验质量，保证产品上线后用户反馈和数据表现与预期不会相差太多。

总结起来进行可用性测试的目的主要是：发现产品和服务设计中的问题；发现提升产品和服务设计的机会点；理解用户的行为和偏好。

可用性测试发起的时机

可用性测试可以在产品的任何阶段进行：

• 在产品设计初期，使用低保真原型，测试想法的可实施性、用户对产品的接受程度、对于产品基本功能和信息架构的反馈等。

• 在设计阶段，测试用户是否能够轻松达到目标，完成任务。需要有一个功能方面相对完整的高保真原型进行测试，但是对于UI的要求不高，只要有完善的功能就可以。

• 当产品已经基本完工在投入市场之前，已经有了开发出来的具体产品，用来测试产品质量是否达到了市场标准和用户期待。

• 在产品持续迭代的过程中，可以通过已经上线的产品测试用户完成任务的高效性或是因为市场需求变化，测试用户对于某一功能或整体产品的满意程度。

• 对于同一功能，有多种设计方案，这时候需要通过测试比较这些不同设计方案，寻找最优的解决方式，可以在任何阶段进行测试。

以工作中真实项目为例，从0-1设计一款老师线上布置作业，获取作业学情的产品。整个产品共计进行了三次可用性测试。
在初步有想法阶段，大脑中已经有大致流程并在纸上进行简单的示意，找老师验证线上布置作业并获取学情这个大流程是否符合老师真实场景的诉求，老师对于该功能有没有什么想法。得到初步验证结论后进行高保真原型的设计，设计过程中产品和设计同学又在多个方案中有争议，双方都不是很确定哪个方案是最佳选择，这时候又找到老师进行AB测试，得出结论后进一步优化设计，产出最终设计稿。最后开发完成上线后，为了对之前的设计进行验证并为之后的改版提供设计依据，又进行了最后一轮行可用性测试，不断迭代优化打磨产品。

可用性测试中的角色

一个测试需要三个角色主持人、用户、观察者：

• 主持人：用户体验设计师或者用户研究人员，需要对测试的目的、任务、原型、最后提问环节了如执掌。

• 被测试用户：大企业会按照他们的用户群招募被测试用户，小企业或者没有预算就可以从身边亲朋好友下手了。需要注意的是，被测试者要符合产品的用户群。

• 观察者：只看不干涉，专心做记录观察，需要聆听被测试用户说的话，还要观察用户的使用过程、表情和肢体动作，实时记录下被测试用户的反馈点，哪里用户觉得不好，哪里用户觉得很棒，消极的积极的反馈点都需要记录下来。

本次可用性测试参与人员是该项目的6位同学一起进行，4位产品经理，两位设计师。两两一组进行进行测试。当时我和另一位设计师一组搭档，由于每个用户访问间隔时间很短，就轮着担任主持人和观察者，不用一个同学一直在讲话，或者一直在打字记录，完美搭配干活不累😄。

可用性测试的方式

现场测试：

• 现场测试可以面对面接触用户，能够观察和记录所有的现场信息，相对来说简单一些，首先选择一个能够让用户较为放松的环境，可以是布置的比较温馨的会议室或是咖啡馆。

远程测试：

• 疫情期间，选择远程可用性测试优先被选择，在被测试用户和主持人无法出于同一空间，或者进行现场测试成本过高时使用远程可用性测试。远程测试分为同步远程可用性测（主持型）和异步远程可用性测试（非主持型）两种：

• 同步远程可用性测：利用视频会议和共享工具进行测试，测试者实时观看用户的操作流程，观察被测试用户与产品的交互，并针对被测试用户的操作提出后续问题

• 异步远程可用性测试：不需要和被测试人员进行视频或通话，需要被测试者自己通过录屏将操作记录下来，时候发给测试人员。

无论是现场测试还是远程测试都有对应的优缺点，要根据自己的实际情况进行选择

• 现场测试的优点：更容易控场，可以保证无干扰的环境、通畅的网络，也可以及时解答用户的问题，保证用户能专注在测试本身

• 现场测试的缺点：由于时间、空间及成本的限制，现场测试方法只适用于少量、有限制的样本测试。比如研究人员在一线城市，现场测试可能只能招募本地的被试者，难以触达其他地域的用户。

• 远程测试的优点：在条件有限制的情况下远程可用性测试总比不做强，远程可用性测试比现场当面测试成本低，可以测试更多的用户。

• 远程测试的缺点：尽管在测试者熟悉的环境中测试，但是仍然会有观察者效应，被访问者即使觉得产品很难用，也可能选择不说出来，通过摄像头和麦克风得到的信息毕竟有限，很多场外信息包括用户肢体语言都会有所缺失，没有办法观察被测试用户的表情和肢体动作。

需要测试用户是学校老师，产品需要测试时间正好在学校放暑假期间，加上疫情没有办法进入学校找到老师进行现场测试，并且教师布置作业习惯有地区差异，出差到学校调研和把全国各地老师汇合在一起进行测试都不现实，所以选择线上远程测试。

测试前准备

测试目的：

明确做本次可用性测试是为了验证或者获取什么信息，以目标为导向，首先确定要测试的产品是什么，希望得到什么样的结论或预期，并确定产品测试的范围。

• 本次作业产品可用性测试的目标是：为了验证作业模块的用户体验是否能满足老师在工作中轻松获取作业学情，是否有违反用户交互体验的问题，是否可以在日常工作中常态化使用，帮助用户降本提效。
• 新用户的用户目标是全新产品带来的学习和使用成本，包括两类：1、没经验：对类似产品0使用经验，新手学习成本足够低；2、有经验：对类似产品有使用基础但没用过我们的新产品，使用成本不比竞品高。
• 对于老用户的用户目标：用过类似产品，不可忽视且必须额外要考虑对老用户使用习惯的改变。
• 原则 ：功能完整性：模拟用户任务流，主流程和常见分支流程有支撑不阻塞；产品易用性：流程走通的前提下，操作步骤尽量少，认知成本尽量低；

工作安排：

确定参与测试的工作人员，有的公司有专业用研，可以用研同学带着相关产品和设计一起进行。在没有专业用研的团队负责该项目的产品和设计同学也可以独立进行，周期在1-2周，可以空出独立时间也可以穿插在日常工作中。

由于我们公司没有专业用研同学，每次可用性测试都是产品和设计一起主导并完成，整个测试工作安排如下：

• 第一天：产品同学负责联系运营寻找样本，并分配给各个组，平均一组4-5位用户；设计同学撰写测试评估样本和任务卡片
• 第二天：每个小组收到分配到自己手里的用户进行拉群，和用户沟通并确认时间，熟悉测试流程和测试任务
• 第三、五天：开始进行测试，一组两人，一个担任主持人，一个担任观察者。平均一天2-3位用户，一位用户用时30分钟-1个小时，访问结束及时进行总结整理。
• 第六天：大家分模块进行总结梳理。

  
  
  

  测试脚本：

  为了防止在测试访谈过程中迷失方向，要提前制定好访谈大纲的结构和关键要点，增强对整个访谈的把控感。提前写好测试评估脚本，标注任务流程、任务要关注的重点以及预估时间，可以保证我们在进行测试中更好把握测试节奏。
  测试脚本包含：主持人大纲（测试前访问热身、基本信息提问、正式测试任务、体验访谈）；观察者大纲（根据主持人大纲同步整理，观察并记录用户完成任务过程）。

招募用户：

用户数量在6-10名用户参与，一般这个数量就能够发现测试里的80%的问题，继续找更多的人结果也是差不多的，需要确定使用你产品的用户群体，选择用户尽量选择沟通意愿强，愿意思考发声的用户。

招募用户的途径可以找公司内部渠道资源进行招募，像B端产品用户是特定属性，通常可以联系公司和用户的接口人进行招募。也可以自行在社会上招募，C端产品可以在公开平台发放招募问卷，或者找自己身边的亲朋好友进行测试。

本次测试样本通过驻校运营同学联系到了学校老师，包括初中、高中、文科、理科共13人，覆盖了全部类型教师。
招募要求需要使用过线上布置作业功能的老师（各种产品都可以），有使用类似系统经验的老用户和没有使用经验的新用户使用频次深度浅度均可。
联系到用户后，在微信上把相关同学拉群，方便和用户进行沟通，并更改群名称为【XX用户-XX产品测试-8月3日下午1点】人+事+时间，在群里预约好访谈时间，询问用户平时使用过哪些线上视频软件，腾讯会议、飞书会议均可。如果没有使用过类似系统，告知用户提前进行下载。

测试设备

最好让测试者使用自己的设备可以让结果更准确，这个设备是测试者在真实生活场景中早已熟悉使用的，陌生的设备会增加测试者的学习成本，可能导致结果产生偏差，比如iOS用户和安卓用户，windows用户和mac用户，他们的使用习惯有很多不同，另外一定要进行录音录屏存档，方便后期回看。

本次测试是远程测试被测试者使用自己的电脑进行操作，环境也是选择自己熟悉的环境。

准备物料：

• 交互原型，确保测试流程为可点击的完整闭环，本次交互原型使用Figma进行交互操作，提前测试在不同机型和各个网络、浏览器中都可以顺利打开并进行点击。
• 录屏录音，面对面测试需要准备录音笔和拍摄设备；远程测试使用会议软件，使用软件自带的投屏和录制系统。
• 准备任务卡，面对面测试需要提前打印好，测试时发给用户；远程测试提前编辑好每段文字，随时在群里粘贴复制给用户。
• 测试礼品，测试结束后准备一些小礼物送给用户作为酬劳（根据每个公司不同政策准备即可）。

需要提示用户提前下载好腾讯会议或者飞书等自己使用过等会议软件，确保测试环境网络没有问题，测试使用的交互体验原型提前发给测试者，直接使用浏览器打开就可以，被测试者投屏演示操作即可。在体验到某个任务节点时口头描述一遍给用户，在复制到微信群，并且在结束后每位用户申请了100京东元作为测试礼品。

测试中执行

访谈热身：

开场有礼貌的打招呼，并向用户介绍本次测试的背景、目的以及接下来的测试流程，以及整个访谈时间。整个过程中给用户营造轻松自然的氛围。

非常感谢您抽出宝贵时间来参加我们的访谈，整个访谈测试时间在30分钟-1小时，背景是我们现在计划开发一个服务于校内作业和小测验的练习模式，目标是让老师更轻松的获取作业学情。接下来主要基于我们初步的设计方案，听听咱们老师的使用感受和建议。

用户情况：

接下来询问用户的一些基本信息，聊一下用户有没有使用过类似产品，对于竞品有什么想法，对于这一类型产品的哪些功能好用哪些功能等。观察员进行详细记录。

首先询问基础信息，主要包括：姓名、地区、学校、教龄、年纪、任教学科、身份；然后请问您平常的作业、测试、考试有使用过什么线上产品吗？你平时会布置什么样的作业？作业的内容来源是什么？最后有什么推荐和吐槽的地方比如：哪个产品的什么功能好用？哪个地方不好用？为什么？

发放任务卡：

我们需要给用户模拟一个真实使用场景，以创造一个实际场景的方式告诉用户任务，用户就可以通过自己以往的经验，带着生活实感，更主动的使用产品。通过制作任务卡的方式来进行模拟场景，以假设一个什么样的场景，要达到什么样的目的，取得什么样的结果作为任务卡的模版。如果是面对面测试可以提前打印出来，在测试时发放给用户；远程测试把剧本化任务复制黏贴至对话。

• 任务一：假如您是一名高一的数学老师，我们在一个学期初给您提供了教辅《三年高考五年模拟》配套的线下批改的答题卡，您昨天给高一1班布置了教辅作业“集合”这节内容，学生使用了教辅答题卡进行作答。今天您把作业收了上来之后，并且在答题卡上批改完了主观题，想用我们的系统来获取学情。
• 任务二：我们平台的题库是给老师们提供了比较丰富的可以用于考试或者练习的题目资源。假如您打算在高一1班进行一场考察“集合”知识点的单元测验，想要选用我们平台的题库内容来出卷子、制作答题卡用于测验，后续使用我们系统获取本次测验的学情。
• 任务三：假如您已经自己准备好了明天的作业题，想在我们的系统上制作答题卡用于学生作答并后续获取本次作业的学情。
• 任务四：假如您发现“集合”这场练习，有道选择题分值设置错误，需要修改分值错误。

• 任务五：我们有一个原卷批阅的新功能，无需制作答题卡就可以实现客观题自动批改，在原卷上批改主观题后扫描试卷就可以获取学情。假如您已经在学生试卷上批改完了今天作业的主观题，今天的作业内容是自己选的题目，想通过原卷批阅的功能来获取学情。

  
  
  

  体验并记录问题：

  观察并记录用户的行为，并在一个单任务完成后，提示用户稍事休息，然后提问《单任务满意度问卷》中的问题。此时可以回答用户操作过程中的疑问，也可以藉由操作中的细节做延展发散，询问用户操作感受。通常可以获得很多针对该单任务的意见和建议。这些意见和建议后续就需要记录整理，作为优化任务帮助提升产品可用性和易用性。

• 不要主动引导用户：测试过程中，主持人给出任务和场景后，应当让用户自主操作，用户碰到困难不知道下一步怎么做的时候，主持人要让用户说出他们的想法，说出困惑的原因，不到万不得已，千万不要教用户下一步怎么做。

• 记录用户行为：操作是最直观、真实的反馈，观察员需要详细记录用户的操作点。用户会因为不好意思吐槽产品而给出虚假的反馈，而动作行为不会骗人，所以要减少对测试者语言上的干扰，多观察用户的动作行为。
• 观察用户的表情：在操作过程中，用户会下意识的发出一些声音和微表情动作，这些细微的反应需要注意。
• 把握访谈节奏：可能会面对用户会一直说大量和访谈不相关的问题，面对这种情况需要及时制止。

实际老师点击流程：
老师先点击日常测练按钮，然后点击新建练习按钮，在找不到练习题的入口后，又返回首页，点击了扫描仪读卷。

观察记录过程中的疑惑点：

1. 答题卡模板匹配，老师提到如果是自己，只看标题！其他老师通常看到蓝色就会点，不会认真看是什么。
2. 学校里有个老师统一发布作业，会把全年级班级都勾上！其他老师不会关注或处理这个。
3. 作业的答题卡版式，高中数学题量很大的，尽量减少非试题的占用空间给学生去写。
4. 完成电子化的，尽量会使用带题干的版式去使用
5. 希望选择题批改留痕，数学因为选择题少会出成填空题，手批！原因是希望题干、学生作答、批改痕迹评语等在一张纸面上显示。
6. pdf格式，题目质量非常好手抄下来，一般的话就换一张试卷
7. 练习班级，学校要求全年级一样的，不能出现不一样的会出问题的！
8. 周考考试时间是统一的，作业不会每次做完每次出，有的话就是全年级一起出好了
9. 默认一个年级都用，扫描看老师个人情况是否勤快要不要一起扫描了
10. 但是编辑分值入口，艰难找不到！找了半天只看到了编辑题目，无奈点进去发现可以改！
11. 修改分值，应该是去题目、改题干的地方去修改！主要是没有按钮，只有蓝色的字可以点
12. 模拟了一下修改客观题答案、修改题型，老师看不到蓝色的按钮文字，不知道可以点！
13. 对于样卷和学生卷放进去扫这件事表示能理解，第一反应有点担心样卷和学生卷放进去扫会有一次送两张纸的情况。

    
    
    

    体验后访谈并记录

    用户完成任务后，主持人需要向被测试者提问来总结和在确认用户的使用体验，问题要与被测试的目的对应。提问题的时候问题要明确，不要问含糊不清或者用户不好回答的问题。也避免问抽象的包含多种可能的回答，这样容易让用户不知道该从何说起回答不上来。多用开放式问题增强用户的表达欲望。

整个流程中哪个环节最麻烦？对比同类竞品，我们的产品有什么优势？我们有可以把作业/测验的成绩发送到家长手机里的功能，您倾向于默认每次都推送还是每次设置是否推送？还有什么建议吗？

测试后总结

问题汇总：

测试完成后，趁着记着内容，快速把问题进行整理，如果有录音或者录屏可以重新进行回顾，主持人和观察者需要一起进行总结分析，测试结果往往会出现大量问题，零散的问题不方便进行分析和归纳，需要按照测试任务或者页面进行分模块，在每个模块下，罗列用户好的反馈以及不好的反馈。并根据不同模块整理，把问题总结归类，并对应问题进行分类，区分哪些问题可以优化，哪些问题不是体验类的问题，当问题总结归类完成后，引入「用户体验八阵图」来对应相应页面，让我们能够更直观的了解到现有项目中精细到单个页面中所面临的用户体验设计问题，这样一来，可以快速发现体验问题最多是哪个页面？体验问题最严重的是哪个页面？体验问题中哪个模块的问题最多等，最后输出本次可用性测试的测试报告。

步骤：找到扫描入口

预期结果：用户可以顺利找到扫描教辅入口即「扫描仪读卷」

实际问题：绝大部分用户可以顺利找到入口；个别用户选择「日常练测」（2/12 都是教研）
“老师直接点击日常测练，新建练习，找不到教辅入口。（反馈：因为说是作业场景，所以第一反应点击了日常测练）”
“在大首页认为扫描应该在学情前面，因为是先扫描后看到学情”

问题点：用户理解场景需求是要完成一场练习，认为在「日常练测」中可以完成任务

影响因素：用户受背景描述影响

用户建议：“老师可能存在帮助其他老师扫描，不知道是哪些班级。建议默认发布到全年级，或是扫描后确认一下班级是哪几个”

问题类别：易用性问题

优先级评估：P1

得出结论：考虑是否要在【新建练习】中增加扫描教辅入口 ，先不加，再看反馈

可用性量表：
使用SUS可用性量表来进行量化，在可用性测试结束后，用户快速完成各个题目，不进行过多思考。整个问卷共10题，每题5分，奇数为正面描述，偶数为负面描述。填写之前不要进行总结或讨论，应当要求用户快速完成各个题目，不要过多思考，果用户因为某些原因无法完成其中某个题目，就视为用户在该题上选择了中间值。
计算SUS得分的第一步是确定每道题的转化分值，范围在0-4。对于正面题（奇数题），转化分值是量表原始分减去1（Xi-1），对于反面题（偶数题），转化分值是5减去原始分（5- Xi）。所有题项的转化分值相加后乘以2.5得到SUS量表的总分。所以SUS分值范围在0-100，以2.5分为增量。将得到的SUS的原始分数，对应到下图表格，即可得到产品的可用性程度。

写在最后

经历多次实战经验，对于可用性测试的注意事项总结三个重点：有目的性、可以灵活运用、持续测试

1、有目的性：可用性测试可以帮助团队优化体验路径，明确用户使用产品时的体验感受；帮助设计师进行设计验证。

2、灵活运用：完整的可用性测试从筹备到进行，从任务到结果，每一个细节都需要考虑到位，在过程中尽量保证流程规划清晰，文档整理完整，分工明确到位。一说到这里很多小伙伴就会望而却步，觉得自己公司没有专业用研团队、招募不到测试者、申请不下来被测试者到酬金和礼物…其实也可以灵活运用可用性测试，在没有 ，进行专业可用性测试时可以在设计过程中多次使用简易可用性方法，只要能解决问题就可以，只要了解一些必要的注意事项，产品经理和设计师也自行完成简单的可用性测试。比如这次可用性测试中，就是由产品经理和设计师发起配合，一起担任观察员或主持人，在对测试反馈的问题进行优化过程中，也是团队通力合作，推进迭代快速进行。

3、持续性的: 可用性测试不是进行一次就结束的一场表演。而是结合产品进展情况，可持续实施的一种有效的快速验证方式。可以在设计过程中进行简易可用性测试，节约成本，并且面对简陋的原型用户更愿意大胆评论给出简易。不过简陋的测试原型会使用户没有办法真正完成整个操作，一些设计的细节测试不到，建议在设计过程中进行多次简易可用性测试。在新产品上线后或者重要功能上线前进行比较正式的可用性测试，发现细节层面的问题。建议周期性进行可用性测试，取得一些结果后立即应用于产品，隔段时间再次验证，形成良性循环。

我们日常工作会接触大量设计方法论，可用性测试只是其中的一种，只是简单的了解这些方法论的概念是远远不够的，需要不断进行实践，从事情上不断磨练积累经验，才能真正体会到这些设计方法的魅力，并且在工作中也要学会灵活运用理论方法，更容易达到事半功倍的效果，长此以往不断实践打磨形成自己的一套工作方法。