编辑导语：在做B端产品的时候，你是否经常会遇到一些困扰，与技术部门、客服等持有的意见不一致。并不能从根本上解决问题？本文作者分享了可用性测试的实践经验。来看看吧，希望对你有帮助。

在产品设计和R&D过程中，您是否经常遇到以下问题：

新产品功能上线后，收集到的用户反馈不一致。比如“有人觉得直接打开更方便，有人觉得滑动更好”，“有人觉得页面蓝色风格不好看”，“版面设计不好看，信息太密抓不住重点”……在设计一个方案的过程中，某个功能有多个设计方案，无法判断哪个方案更好；产品已经开发出来了。上线前要不要检查一下是否符合用户需求？有多满意？业务和客服人员往往需要花费大量的时间时间和精力来收集和处理用户的投诉和反馈。但是因为有用户各种各样的投诉或者反馈建议，而且都有自己的立场，所以无法明确分析出问题出在哪里。

面对此类问题，技术部门通常通过版本回滚来临时解决用户的投诉和反馈，并不能从根本上有效解决用户的问题。

那么有没有其他更科学高效的方法来解决问题呢？

在这里，我想和大家分享一下我们在可用性测试方面的一些实践经验，和大家分享一下我们在B端产品上面对这些场景时所做的一些工作，希望能给大家带来一些直接的帮助。

目录：

一、可用性测试的基本概念我们先来看看国外体验设计专家Jeffrey Rubin和Dana Chisnell在《Handbook of Usability Testing》一书中对可用性测试的定义：

描述：典型用户是指真正制造产品的顾客、潜在顾客或意向顾客。产品是为典型用户设计开发的，只有通过典型用户的可用性测试收集的数据和信息才有意义。

在ISO 9241-11:2018，可用性的概念是指：

特定用户在特定使用场景中为特定目的使用特定产品时感受到的效果、效率和满意度所以可用性测试也是通过测试找出产品在有效性、效率、满意度等方面存在的问题，有针对性的进行改进，从而提高产品体验。

二。可用性测试的价值可用性测试是改进产品的较为科学有效的方法之一。

有时候，我们并不是产品的目标用户，很多需求和设计方案都是产品和设计师自己创造的。虽然我们会把设计建立在一些经验和设计规律的基础上，但这些都只是未经验证的主观猜测，并不能准确评价设计方案的优劣。

所以，要想真正了解用户，需要找到我们的目标用户，并向他们学习，让产品的各相关方尽快就设计方案达成一致，积极改善产品体验。

可用性测试的价值可以总结如下：

通过可用性测试，我们的最终目标是提高产品用户体验和满意度，并帮助实现业务目标。

三。可用性测试的类型。可用性测试适用场景可用性测试可以在产品的任何阶段进行，不同场景下可用性测试的侧重点也不一样。一般我们侧重于产品上线前的方案验证；上线后，专注于发现问题，迭代优化；同时，将每天进行可用性测试，对关键或高频功能进行体验跟踪，持续优化体验。

2.可用性测试的分类可用性测试的类型主要分为分析法(部分定性法)和实验法(部分定量法)。区别在于有没有用户参与。以下是两种测试类型之间的主要比较：

在某种程度上，分析方法和实验方法是互补的，不同的测试方法适用于不同的场景。需要根据测试目标、问题场景、产品阶段、预算、时间周期等因素选择合适的测试方法，以最佳的方式实现可用性测试的目标。

接下来通过一个过往的案例，和大家分享一下我们是如何根据目标选择考试方法的。

1)案例场景

有两款产品入口，分别列在产品列表入口和首页banner入口。我们通过用户点击数据发现，首页banner的点击率比较低，大部分用户还是通过产品列表进入入口。我们希望分析并找出banner入口点击率低的原因，提高banner入口点击率。

2)原因分析

从产品、设计、体验的角度：banner风格、动态效果、banner大小、banner位置、banner展示的文案等因素都会影响最终的点击率。

3)可用性测试方法和策略

首先通过专家评价和启发式评价对存在的问题进行分析，针对问题输出两种不同的方案。采用A/B测试，将两种方案在线小范围投放，结合投放数据选出转化率最高的横幅，正式投放。

四。如何组织更有效的可用性测试？结合我们的实践经验，我们将可用性测试分为七个阶段：

接下来，我们将根据小企业融资贷款产品领域的可用性测试实践，详细分享如何组织一次可用性测试。

说明：中小企业融资贷款产品为企业主和企业用户提供贷款资金，用于企业周转。申请人可以申请贷款、签订合同、提款、还贷等。在线。

业务诉求：由于历史原因，现有功能框架陈旧，日常客户贷款申请和使用过程中反馈问题较多；同时，客户应用转化率不高，应用链接流失率高。业务部门想了解产品功能和流程的哪些体验问题？如何提高客户应用转化率实现业务增长？

基于上述背景，我们决定对小企业融资贷款产品进行可用性测试，帮助企业解决遇到的问题。

1.需求收集可用性测试通常由设计师发起，但需求不仅仅来自设计师，还可以是来自用户、业务、产品、技术等角色的反馈。比如用户反馈问题、异常数据、阶段性业务目标、迭代版本优化、常规用户行为数据监测、创新产品方案设计等。都可以作为可用性测试的需求源。

我们建立可用性测试需求列表，统一收集各方提出的可用性测试需求，然后进行需求优先级的合并、筛选和确认，并将其纳入可用性测试计划的调度中，然后协同各方推动可用性测试计划的实施。

图例：可用性测试需求收集列表模板

2.写测试计划收到可用性测试需求后，我们需要根据需求制定可用性测试计划。一个完整的可用性测试计划包括以下几个部分：

以下是为小企业融资贷款产品的可用性编写的测试计划示例：

1)定义测试的目的和范围。

在测试之前，需要与需求提供者进行沟通，确定要测试的产品是什么，要验证什么样的结论或者要达到什么样的预期，以便发现产品或原型中的可用性问题，或者与竞品进行有效性、效率和满意度的比较，或者测试一些功能点等。明确本次试验的产品和范围，以便有效开展后续试验。

2)确定测试任务。

可用性测试任务是指导测试的操作指南。我们通常根据测试需求和目标，将任务设置在一个场景中，以任务脚本的形式引导用户进行测试。测试脚本包括：开场指导、任务设置、满意度测评、结束后面试等。

一般来说，可用性测试需要很多人的合作。由于涉及的内容较多，被测试用户的活动和任务复杂且环环相扣。因此，为了保证测试任务更好的执行，通常会准备一个相对完整的测试脚本，以便测试人员更好的配合。

图例：xxx贷款产品可用性测试脚本模板

开放引导

介绍测试的目的、注意事项等。给被测试者。测试前还可以做一个聊天式的沟通，了解用户对产品的使用情况，帮助用户转移对产品的注意力，为测试做铺垫。

任务设置

设计任务是“谁在什么情况下要做什么”，重点是“人”、“场景”、“目标”三要素。任务设计的几个核心原则：

a)根据测试目的列出任务清单。任务不要太多，一定要贴近核心测试任务。

比如贷款产品，用户的核心任务是申请、签约、提现、还款。所以我们的任务设置需要围绕这些主要流程来进行。

b)把任务交给真实场景。毕竟用户用的是有真实场景的产品。

比如贷款产品的申请，模拟用户在资金链紧张的情况下，如何找到并完成贷款产品的申请流程。

c)定义测试任务的起点和终点。判断用户是否完成任务的主要依据是用户是否从起点(A页)到达终点(B页)。起点不一定非得是首页，起始位置要根据具体场景来确定。毕竟不是每个任务都是从主页开始的。

比如贷款申请，任务的起点是贷款产品的申请入口，任务的终点是完成贷款申请提交。

满意度评价

每个任务完成后，用户可以对任务进行评级。注意评分的同维度，否则无法统计。比如可以从产品功能的满意度和操作的便利性来打分，可以5分制打分。最后计算平均值，得到每项任务的平均满意度得分。计算所有任务的平均得分，取平均值，得到整个产品的综合满意度得分。

可以考虑评估量表，如SUS量表、ASQ量表等。选择具体的尺度，需要根据测试场景、目标等选择合适的。以下是关于SUS秤的基本信息：

下面是我们在可用性测试中使用的SUS量表的一个例子：

图例：贷款产品可用性测试的SUS评估标准模板

结束后面试。

完成测试任务后，就可以采访用户了。访谈的目的是收集用户对产品的其他反馈，同时可以回顾和确认测试记录过程中的疏漏。

3)明确用户招募。

我们需要根据测试所选择的具体可用性测试方法，在方案中明确用户招募的内容。一般用户招聘需要从以下几个方面考虑：

招聘类型

通常招募的用户类型分为：小白用户和专家用户。在招聘时，为了保证数据的真实性和可靠性，应避免产品相关人员的参与。一般首选有代表性的用户，真正的产品目标用户最好。

招聘来源

招聘的来源一般分为内部招聘和外部招聘。我们需要根据实际情况来选择招聘渠道，这样在招聘阶段就可以根据确定的招聘渠道来招聘用户。

招募人数

测试人员不宜过多。一般5个测试员左右就够了。

根据Nelson博士的相关理论：五个人参加用户测试，可以发现85%左右的产品可用性问题。所以招募的用户数量并不是越多越好。

图注：尼尔森用户招募与问题关系图

4)确定与测试相关的资源。

可用性测试通常是离线进行的，所以需要提前准备好相关资源，以便在测试执行阶段测试能够正常进行。一般需要确定的相关资源包括：场地布置、测试设备、测试环境数据(软件安装包/版本等。)、助理测试员、测试后的礼物(如果有的话)等。

在测试计划中，我们需要根据不同的项目进行分工，根据不同的资源将项目准备给相应的负责人，从而更好的完成测试准备和进度跟踪。

5)确定每个节点的时间表时间

在制定可用性测试计划时，非常重要的一点是，我们需要根据总体测试时间，确定各个阶段节点时间的具体进度，我们需要在节点时间内完成这个任务。同时，在与各相关方达成一致后，大家按照这个时间排班计划前进。同时，在接近时间节点时，需要提前确认该任务的完成进度，以便控制整体进度。

同时，要考虑到在紧急情况下，事项可能延期或不能按时完成的情况。如果发生意外，我们的对策会是什么等等。

3.用户招募在确定可用性测试方案后，我们将开始招募用户。

用户招募的关键点是招募的用户要有代表性。根据产品的后端使用数据，可以知道用户的群体特征是什么，比如性别、年龄、婚姻状况、职业、生活状况等等。通过这些条件进行筛选，有助于更好的招募典型目标用户。

结合小企业融资贷款产品的可用性测试，在招募用户时，通过后台大数据分析平台了解小企业贷款用户的群体特征，如申请状况、职业角色、性别比例、年龄分布等。并为招聘用户提供基础参考数据。

图注：xxx贷款产品可用性测试用户招募

4.测试材料的准备。正式测试前需要提前准备好测试资料。有必要在测试前进一步明确他们是否准备好了。一般需要准备的测试资料包括：场地布置、测试设备、测试环境数据、人员安排、用户调度、测试结束后发送测试邀请函和礼品(如有)等。

5.测试执行阶段是正式的测试执行阶段，主要分为以下过程环节：

测试执行是整个可用性测试的关键环节，操作执行的质量直接影响整个可用性测试的结果。我们需要遵循之前测试计划中的测试任务脚本，指导用户按照脚本执行测试任务。同时，在测试过程中要随时观察和记录用户操作遇到的问题及其情绪表现。每次任务结束后及时对任务满意度进行评分。保持评分过程客观独立，不要干扰用户评分。

如果测试用户遇到测试相关的问题，不要直接告诉用户该怎么做。为了确保测试的顺利执行，我们需要注意以下几点：

6.整理分析测试结果1)整理记录原始数据。

测试完成后，应尽快整理好原始资料，资料和问题的整理应尽可能详细，便于后续核对和参考。对于可用性测试，需要整理的资料一般有：测试观察问题记录表、任务完成效率统计表、任务完成有效性统计表、测试问题截图，或者屏幕记录的文件整理。通过整理和记录原始数据和资料，可以保证结果分析数据的真实性和准确性。

图例：单个任务完成效率统计

2)试题归纳整理。

对于记录的问题，需要详细记录问题。一般会提前做一个可用性测试问题记录表，记录表需要明确记录模块、功能页面、版本、手机类型、问题描述、问题截图、用户情绪反馈、测试记录人、记录日期等。

图例：试题汇总统计

3)数据分析和整理

对结果的分析和整理可以从定量结果和定性结果两个方面进行。量化的结果可以分析任务的完成情况，任务的满意度等。和通过可视图表显示，例如：

统计任务的满意度得分。

我们会统计计算单个任务的满意度得分，并与总平均值进行比较。对于分数低的任务函数，要注意。需要进行后续分析，重点解决满意度低的问题。

例如，小企业融资贷款产品的整理结果如下：

统计任务的完成情况。

任务一般可以分为三种情况：完成、求助后完成、未完成。不同的完成情况用不同的色块表示，然后统计完成率。

例如，小企业融资贷款产品的整理结果如下：

图例：单个任务完成情况统计

定性结果的整理

根据用户测试中记录的问题，分析具体的问题类型，分成不同的类型进行统计，并进行概括性的总结，总结出问题点集中在哪些方面，如功能问题、性能问题、交互问题、视觉问题等。通过问题类型分布图，我们可以清楚地看到问题点集中在哪些维度。

例如，小企业融资贷款产品的问题类型分布图如下：

图例：问题类型分布的雷达图

7.测试分析报告的准备完成测试结果的分析后，就可以开始准备分析报告了。报告的内容通常分为以下几个部分：

测试结果总结、任务计划概述、测试问题分析、竞争产品分析、优化解决方案和后续优化计划。

可用性分析报告作为一份总结材料，不仅是对可用性测试过程的回顾，而且对所有相关方都有很大的价值。体现在以下三个方面：

动词（verb的缩写）如何驱动用户体验来提高可用性测试，可以帮助我们发现产品中存在的体验问题。完成可用性测试报告后，并不意味着工作的结束。我们需要将可用性测试中发现的问题和解决方案与各相关方进行沟通，将问题和优化方案推送到版本迭代优化中，并对优化效果进行验证和跟踪。不断通过可用性测试，打磨和优化产品的用户体验。

以上是我们在B端产品可用性测试的实践经验。不同产品使用的可用性测试方法与我们服务的产品和特定的测试需求密切相关。不同的测试需求需要考虑测试的目标场景以及是否存在限制因素等。不能简单直接的重复使用。可以根据具体情况使用这套工具和方法进行可用性测试。

我们大部分的可用性测试都是离线进行的。希望你能为自己争取机会，多尝试和用户沟通。你会发现很多之前想不到的问题。越了解用户的行为和习惯，越能避免设计时的体验问题。只有这样，才能有助于提升产品的用户体验，更好地帮助业务实现目标。

作者：WOWdesign，研究设计价值最大化，涉及用户体验、品牌体验、空间体验。

本文由@WOWdesign原创发布。每个人都是产品经理。未经许可，禁止复制。

题目来自Unsplash，基于CC0协议。