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