可用性测试是产品经理做调研时非常有用的方法，在B端也非常有效。这篇文章，作者通过一个案例详细讲解了其中的「场景自助测试」，主要解决的正是产品难用、初次体验不佳或是缺乏引导设计等主要问题。
作为一名ToB的设计师，你是否有遇到过以下这些问题；
当然了，也不仅限于上面这些问题，但是如果遇到了，或许你可以在此篇文章中找到一些答案。
源于“可用性测试”的一个细分延展应用，微型使用性测试也是可用性测试的一种细分延展应用，个人学习和了解可用性测试是在2017年从一本叫做《洞察用户体验》的书中习得，就下图里这本厚厚破破的书里。
在过去的这么多年里，可用性测试不仅我个人在用，在整个行业里也已经被广泛接受和应用，其效用价值还是可靠的，而作为细分延展出的场景自助测试，在我投身B端业务后，也是围绕产品目标参与发起很多次了，所以这次结合自身体会给大家安利一下，对了，可能其他团队或公司对此工具的叫法会不一样，但这不影响我们学习掌握。
场景自助测试主要是观测用户如何根据任务诉求自助应用产品来完成某项工作，这个过程中可以清晰的看到某个业务场景下产品是否容易上手，以及哪些部分阻碍了用户或需要进一步引导，当具备多组测试数据时就可以计算出用户自助完成的概率，那么就可以根据产品情况制定一个目标分，当优化后的测试结果满足目标分以后，产品的自助性与体验就会再上升一个门槛。
通过用户来找到产品的问题，验证设计是否符合用户预期，指引设计者将复杂产品简单化，完善产品的自助引导设计，提升用户自主解决问题的能力，以减少人工支持的开支，同时获取一定的用户意见或市场讯息。
所谓的以用户为中心原则，基本上就是还原真实环境下以用户为主导的使用效果，注重数据驱动与场景化分析，同时属于持续性迭代测试任务，当测试出一波问题后还需要进行改进后的版本测试回归，并保证自助通过的概率符合产品难度预期。
B端产品更工具化，通常围绕特定行业的业务流程展开，客户群体和业务流程都遵循着某些规范或标准，这些特性使得场景自助测试会很适用。另外那些已经上线和具备一定用户量的产品，特别是对于那些高度依赖用户自助服务的企业来说，提升自助率不仅可以直接降低客户服务成本，还能有效增强客户满意度，实现双赢的效果。
同时B端产品具备复杂的功能体系与交互场景，学习门槛往往较高，如果不能提供友好的易用性或引导帮助，那些没有经过培训学习的用户是很难通过产品自助展开工作的，变相的也会形成更多的人工支持成本。
另外当你的产品没有靠谱的引导设计或是自助完成率不高时，这是一个危险的信号，根据我们的真实经验，如果你的产品在价格或是售前培训、技术支持等方面没有优势的情况下，新客户流失率或付费开通率也会不理想，其原因在于新客户初次体验产品时，不能顺畅的走完核心流程而感到受挫甚至质疑产品，这时候客户大概率会去挑选其他更好用的竞品，毕竟对于公司来说，工具的快速上手或减少不必要的培训学习成本也是很重要的。
那么回到场景自助测试，主要解决的正是产品难用、初次体验不佳或是缺乏引导设计等主要问题，如此看来“ToB+场景自助测试=如虎添翼”这个公式便通俗易懂了。
秉持着越简单越实用的理念，我将整个实施步骤概括为“场景自助测试六连搞”；
这里不用纠结更细致的步骤或是模版，你就按照上面的问题把你对应的答案填进去都可以，焦点在于测试的过程与问题复盘规划，当然，后面会给出一些案例与模版。
1）为什么要搞？
首先确保产品的特性与发展阶段适合发起场景自助测试，即产品偏向功能性，有一些复杂或者专业门槛，有更加定向的流程任务，同时属于有一定用户体量的发展型产品。
然后场景自助测试本身是关注的某些特定场景下，用户是否能够顺畅地自助完成一系列相关联的操作任务，所以要考虑这些任务的测试优化，是不是能够对直接影响核心业务流程或是能减少企业对人力等资源的投入。
至于发起的状态可以是基于体验优化目标、新功能上线、功能改版、优化点洞察、场景自助分检验等等。
2）搞那些？
有了目标或是指标后，接着就是制定好对应的流程范围或者说测试模块，尽量不要搞得太复杂，并且有多个任务节点时，要紧靠一条核心线路，任务线路不易过于分散。
制定大致的任务书或测试材料，提供给测试者的任务书不用很细致，给出一个贴合场景任务的目标，并标记出流程中几个主要的事件阶段即可；
例如我们根据政策要求上线了“账户注销”，那么测试目标就可以是因为什么事决定将平台的账户注销，而事件阶段则可以视情况拆分为；
1. 进入个人账户中心、
2. 找到注销入口、
3. 浏览和同意注销知情书、
4. 提交注销信息、
5. 确认和退出账户。
测试材料部分主要是便于我们自己发起和记录测试过程的脚本，里面通常会记录一些话术、测试计划、任务流程简图、对应任务目标的事件阶段表格、以及整理问题相关的表单为主，不过不用担心，后面你会看到案例与简单易懂的模版。
3）找谁搞？
首先你不用纠结对方是不是典型或是资深用户，最基础的是保障行业对口，起码要对相应的业务流程有一定的认知，打个比方我们做一款开发者流程管理工具，那我们招募的用户一定不能是一个对产品研发流程一窍不通的用户。
接着对应到不同的流程场景，我们可以清晰的知道，一般是一些什么职能的角色会用，这些条件是需要符合的，至于对方是陌生人、同学、同事、朋友就不那么重要了，人数上基本上采用≧5即可，人越多自助通过率数据越精准。
考虑到重点关注的是产品上手与核心功能的自助情况洞察时，你可以关注一下对方是否有用过或了解过我们的产品，以及之前有多久没有使用过我们的产品了，这次是否能够测出新的发现。
最后则是发起邀约，不论是问卷、线上留言、电话邀约都好，总之确认哪些人可以抽出一些时间参加测试，把测试的时间、地点、参与方式(线上or线下)、奖品信息等记录好，并如期推进。
在邀约时，一定要简要说清你是谁？要做什么？有什么回报？以及告知没有什么难度，也不会占用太久的时间，只是做一下产品体验官帮助检验产品体验如何，不要让对方觉得很困难或很麻烦，这很重要。
4）搞咋样？
到场后先把一些必要工作准备好，比如测试的设备、软件或是账号资料、测试环境、测试记录的纸质表单跟笔的检查等，为了更好的跟踪整个测试的过程以及后续的复盘整理，所有在电脑或手机上进行的测试，可以提前准备好音视频录制软件，例如常用的视频会议的录制功能。
测试前可以先寒暄一下，可以递上一杯水、聊聊天气、出行啥的，通过彼此的简单互动减少紧张的气氛，然后将测试的目标、任务与材料分发下去，并宣读介绍一下此次的测试任务，可以着重说一下此次测试主要是根据任务目标自主进行，如果遇到问题可以放缓节奏，多看看界面的信息与功能，并根据自己的认知与直觉进行下一步，另外遇到问题时，最好能够口述出疑问是什么，你准备怎么应付，便于观测者了解测试者心里的想法。
当确认测试前准备没有问题后，就可以告知和开启屏幕录制并进行测试了，而你要做的就是在一旁安静的观察，做对方的倾听者，并在表单上记录好测试者在各个任务节点上的表现与结果，是否在某个节点上卡住而完全不能进行下去。
关于是否要对测试者的卡点进行干涉，你需要明确以下几点；
记录问题，在测试过程中，用户遇到问题或卡住相应的在任务列表中进行记录，并将测试者的反馈简要备注。
测试结束时，可以根据记录的问题，与测试者延展性的聊聊感受与预期，查缺补漏一下，通常这时候测试者是很愿意吐槽的，借此机会，你还可以延展一些问题，例如竞品偏好、个人习惯、对未来有何建议等，也可以酌情考虑跟可用性测试一样做任务后评估问卷（ASQ）、系统可用性问卷（SUS）或是用户满意度问卷，不过我们一般都是问一些想要了解的问题，不爱做这些测试后问卷调查～
5）哪没搞好？
重点是那些直接造成卡点的问题，这些问题意味着直接中断了核心任务的进程，导致用户无法自助使用产品完成任务，这种时候就很可能造成用户流失或需要提供技术支持，所以属于关注重点。
然后就是磕磕绊绊的问题，即用户花费了些时间精力才勉强完成的任务，这些问题说明了布局结构、文案信息、交互方式等方面还存在着明显的提升空间，当然因为技术原因导致的卡顿、缓慢也不容忽视。
最后则是测试者的吐槽与建议，如果在测试结束后做了些小访谈，那么对应提问的问题一定会有一些收获，其次用户在吐槽哪些功能不好用之余也会给出原因或是建议，都是可以适当听取的。
问题归档，结合测试者的表现与反馈将磕磕绊绊的问题完善到测试任务列表中，并且可以根据视觉、交互、产品逻辑、技术支持、功能满足等标签进行标记，以便于后续的整理归类。
通过率计算一般分两个维度，一是单个用户在整套任务中，能够自助完成的任务比例。然后就是统计所有测试者中能够自助完成全套任务的人数比例，后者代表了场景自助的通过率，可以结合任务的复杂程度与技术支持的程度，预设一个更高的通过率作为下次的优化目标，如果你期望你的产品拥有更好的用户自助表现，那么可以给出一个较高的目标分，并根据研发里程分成多个阶段逐步上分。但如果你的产品确实比较复杂或专业，就没必要大范围的追求普遍的高通过率了，还不如多想想怎么提供更多的教程或引导资料。
6）怎么搞好？
内部项目不方便公开，这里引入一个类似的研发效能产品进行讲解学习。
主要是针对华为云的研发管理工具的场景自助测试，检验作为最基础且免费的项目需求管理工具自助体验如何，是否能够让用户快速上手，为后续的更多云服务开通或尝试做好铺垫，其中参与测试的采样做了缩减以及一些相关信息脱敏处理，不过不影响整体的方法应用学习哈，那么，咱们开始本次的场景自助测试。
用户是否可以根据诉求快速创建一个基础的项目需求看板，创建后是否可以快速上手需求管理面板，并自主的创建或编辑相关需求，以验证项目需求管理部分的场景自助率如何？是否能够满足用户的基本诉求以留住用户，并引导用户试用和开通更多的其他研发增效工具。
测试产品：华为云研发效能工具核心模块：项目需求管理关联模块：登录注册、项目管理、需求看板创建、需求属性配置、项目需求管理任务流程说明：以账户登录为起点，历经项目创建到需求属性配置、项目需求创建管理与流程状态扭转为主
此处的要求需要根据不同平台产品的特征来做调整，以下是针对本次测试案例的测试者要求情况；
内部邀请
内部招募还是比较简单的，例如跨项目组、跨业务线、是比较容易招到人的，只要按照测试计划说明测试的背景跟奖励信息即可，可以建立合作关系，以后互相协助测试，同时提出是为了公司的整理利益发展，然后当对方有意愿参与测试后，就可以根据测试的周期与对方约定详细的测试地点、时间日程等信息了。
外部招募
相比于内部邀请，对外邀请需要准备的工作会更多一些，出了说明我们是谁？需要做什么？有什么回报、占用时长或难度情况以外，还要明确告知符合参与的条件，要准备简易的知情协议，如果项目还未上线，可能还要准备保密协议相关，至于怎么写这些协议，在网上找模板套用后打印出来等待用户签字即可。
招募渠道
此外招募的方式有两大类，一类是通过线上用户的数据层层筛选，然后面向合格用户进行短信或是电话邀约。第二类则是通过发布招募信息，等待用户主动申请，如果是要进行线下测试记得不要遗漏了详细地址或出行指南。然后发到产品平台的论坛、产品的答疑群、一些开放的IT技术交流群、技术型贴吧等都是可以的，以下是一份其他公司所发布的测试招募海报，信息已脱敏，可以参考以下；
具体看公司的预算来准备礼品即可，例如一些生活用品、平台周边、或是现金红包等等，内部招募的话，甚至是简单的一次下午茶、一杯奶茶都可以。
基本信息就是确认什么人、在什么时间、什么地点、如何参与测试，像测试的会议室或空间等不是一开始就确认好的，那就需要在确认好后及时与测试人进行同步，除此之外还可以将参与者的一些与测试相关的信息进行记录或备注，后续可以作为一个简单的用户画像使用；
（注： 以下均为脱敏后的化名）
任务书
记录表
记录表主要是便于我们测试时，记录核心流程下，每个操作节点下的用户反馈或结果，所以会比任务书更详细一些，这样我们才能够记录下更详细的测试数据，便于分析整理，通常记录表由细化的操作节点、序号、测试结果、反馈记录等信息构成，以下为本次测试所用的记录表电子版可供参考，实际测试前，我们会打印出来手动记录测试信息：
访谈问题
访谈问题是针对场景自助测试之外的一些补充问题，或整体感受评估，一般由一些特定的产品体验问题或是SUS系统可用性问卷构成。
针对本次的测试任务，我们提出了以下问题来帮助我们获取更多有用的信息来帮助产品提升场景自助率。
场景自助测试脚本
就是提前做好测试攻略，将测试安排、话术、注意事项提前预备好，方便开展过程随时参考或是预先彩排用。
测试设备准备
不同平台产品的测试任务，对测试设备、版本、环境、账户、权限等均有差异，所以在测试前需要提前了解情况或做好相关准备，以减少测试过程的差错，对此你可以参考以下表格自检；
通过率计算
※通过率说明：即计算不能自助完成测试人数占所有人数的占比
※场景自助通过率：4/5 = 80% （采样人数5，自助通过测试人数4，通过率80%）
问题分布统计
主要根据任务流程与操作项标记出所有测试者的任务卡点情况、卡点重灾区节点、以及通过率或任务完成率情况，这些可以让我们快速感知要关注的部分，以及全局概况。
主要是把此次测试的过程材料与相关问题进行线上整合，并存储归档。
任务记录表归档
以下为本次的任务记录表，其中有记录测试人俞洋反馈的部分问题，整体就是围绕多个测试人反馈，将问题按照测试的任务流程记录到表里并进行概括性总结，以下记录表可做模版参考；
访谈问题归档
主要是测试后的访谈问题整理归档，结构与以上任务记录表相似，归档后可以将两个表放在一起，以下访谈记录归档可做模版参考；
附件材料
将此次场景自助测试相关的材料放入对应计划下的知识库或文件管理中，例如签署材料、录制文件等，你可以将这些信息与前面的问题记录整合在一个文档中也可以；
（注： 以下均为脱敏后的化名）
根据大致的任务阶段与操作步骤，将问题概括性的整理出来，可以对问题类型、解决方案之类的信息进行初步的完善，然后经过与项目成员的沟通探讨后，就可以对优先级、分工情况、排期计划等信息进行补充，当然这些也可以由项目经理或是产品经理来接手推进，之后就是产品负责人创建优化迭代与需求优化推进了。
经过初步整理的问题规划表格可以参考如下，并且后续可以持续的维护优化解决的进度，当然你也可以在此套表格的基础上去做其他润色或变化，你觉得怎么好用怎么来吧，例如给重点部分加上色块标记等；
以上就是我们经常用作B端产品体验监测与改善的洞察工具，从为什么要用，怎么用，应用的案例参考模版基本上都在此篇中交代完了，不论你是项目经理、产品经理、或是设计师，我都建议你尝试一下这套物美价廉的工具，绝对比凭借着经验做出来的体验洞察与优化更可靠，另外补充两点：
好了，码字不易，欢迎点赞收藏，评论区留言互动。
专栏作家
泡泡，人人都是产品经理专栏作家。专注产品交互领域的体验设计师，擅长思考和UI呈现设计，喜爱交流探讨～
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。