编者按：本文是蚂蚁集团体验设计师朋莱 & 梓美在 SEE Conf 2022 的演讲内容，包括演讲视频及文字内容，欢迎享用。

引言

在 B 端产品中常常存在用户无法自助上手的问题，导致用户满意度、转化率低等业务难题。《如何提升B端工具型产品的自助率》将和大家分享介绍在B端工具型产品中如何发现并系统解决自助率问题，让用户告别帮助，自助上手。 今年下半年，我们团队完成了提升 B 端工具型产品自助率的设计研究，并最终沉淀了一套系统的设计指南。本文分两部分和大家分享，第一部分关于自助率设计研究，第二部分关于自助率设计案例。

自助率设计研究

如果读者你是中后台产品的设计师或者产品经理，我相信大家在日常工作中有听过如下类似的用户原声：

什么是自助率？

上图这些问题本质上是产品存在自助率的问题，到底什么是自助率？在此分享一个公式：自助完成任务的人数/完成任务的总人数*100%=自助率。 为了方便大家理解，举个日常生活中的任务例子：“使用医院的自助终端完成自助挂号的任务”，假设有10个人需要在自助终端完成挂号的任务操作，这10个人里面只有5人完成了，另外5人需要通过旁人的帮助才能完成的，那么就是5除以10，然后乘以100%，最终是50%的自助率。

为什么要做自助率？

自助率提升有什么好处，自助率不高又会产生什么影响？

• 对于业务侧

如果你的产品自助率比较低的话，那么相对应的产品的NPS、满意度、易用度就可能会相对偏低，产品的答疑和技术的支持成本可能会居高不下。

• 对于用户侧

自助率低，意味着用户上手产品困难，大多数用户无法自己独立完成既定的任务，大多需要培训或者专门产品技术人员协助才能上手。 其实无独有偶，在我们蚂蚁的工具性产品中也有类似的这些问题。我们去年摸底调查了 160 多个产品自助率，我们发现有70%+的产品都有自助率相关的问题。

如何提升自助率？

自助率的解决方式包含 3 个步骤：第 1 步是发现问题，第 2 步是解决问题，第 3 步是衡量和验证。

01 发现问题

本文先从第 1 步发现问题开始讲，发现正确的问题是设计方案成功的一半，这里我们通过自助率检测的方式发现产品核心任务链路中的关键体验问题。1.1明确核心任务链路以自助挂号任务案例说明：我们假设核心任务链路是自助完成挂号，把任务分成五个步骤：首先，你要选对一个自助终端，你是选自助挂号机而不是自助发票机；第二步，通过身份验证；第三步，选择就诊时间；第四步，选择一个科室和医生；最后，付费成功。 1.2 实施任务测试实施任务测试的过程中，我们要观察真实用户在完成这个任务时的具体操作的行为。 然后，根据用户的反应做访谈以及记录，这是我们后续针对性地实施设计策略的关键。 1.3 结论分析整理针对比较简单的任务，我们只是检测产品的自助率情况即可，我们判断这个任务是否可被完成，发现任务体验问题并针对性采取设计策略。 当我们面向一些复杂产品，即使知道了自助率，仍然不足以明白用户问题出在哪里。如何更加精确地发现任务链路中的体验问题，于是我们引入了新的任务数据指标——任务完成率。「自助率」和「任务完成率」具体关系是什么样的呢？仍以自助挂号任务为例，如下图，有5个任务节点，假设共有3个人需完成任务，这3个人里面只有1个人自助完成，那么自助挂号任务链路的自助率是33.33%。采用任务完成率，我们可以统计5个任务分支节点的任务完成情况，发现3个人平均任务完成率是80%。 我们发现第2个步骤，即P2节点（身份认证阶段）特别难被完成，任务完成率只有33.3%，我们称之为高阻碍任务节点，这便是设计核心需要解决的。通过引入「任务完成率」，我们发现了核心任务的核心体验卡点。 02 解决问题
我们已经发现了正确的问题，接下来，我们如何解决问题？在以往的设计实践中，各个任务复杂程度各不相同、业务类型千差万别、产品阶段各有差异。比如，刚起步的产品，可能更关注可用和不可用；如果产品阶段处于商业大规模推广阶段，除了关注可用不可用，更关注好用。这样看似不同的业务自助率难以得到一套系统的解决方法。 我们想寻找 1 把万能钥匙，能够帮我们解决所有的自助率问题。我们团队通过半年时间的业务实践，发现实际上万能钥匙是存在的——我们发现所有的B端产品本身都会有 1 条主线，即从任务的角度出发，每个产品都在完成任务。 回到刚刚那个例子里面，我们结合了《设计心理学》中关于任务的描述，把用户面向任务的行为分成了五个阶段：

• 阶段一：产品能实现什么目标
• 阶段二：达到目标要完成哪些任务
• 阶段三：任务从哪里开始
• 阶段四：任务过程中如何操作
• 阶段五：任务的状态与结果

回到刚才自助挂号的案例，具体的一一对应关系如下图： 既然所有的任务都可以分解为五个阶段，我们可以做一个大胆的假设：假设用户在这五个节点都能够顺利地完成，那么该任务的自助率就可以为100%。 我们用半年时间，以上述的用户视角，从160多个产品中选择了15个核心业务进行优化。优化前，15个业务核心任务链路的自助率为0%，经过半年时间的跟踪解决，平均自助率提升到了78.9%。 业务取得阶段性成功后，我们发现其实很多任务阻断点的设计策略和解法都有共通之处，如果可以整理汇总成通用的设计指南手册，那么再碰到各个任务阶段问题的时候，其实不需要重新思考和设计方案，可以从指南手册的对应任务阶段找到对应的解法，以帮助大家快速解决业务中的自助率问题。下图是指南的设计经验目录。 设计经验提供了每个阶段下的设计目标、设计策略、设计手法、以及对应阶段的实际业务参考案例。在后文中将会介绍如何使用指南的设计经验解决业务问题。

03 衡量与验证

衡量与验证阶段重复前述发现问题的验证方式，方便前后对照。衡量阶段其实是结束，也是开始，一方面验证我们的设计解决方案是切实有效的；另一方面，验证发现的新问题又是新一轮体验优化开始的依据。

自助率设计案例

以下是一个 B 端数据建模产品的自助率提升案例（由于业务数据涉密，大部分数据由笔者编纂，案例说明只为讲解如何发现、解决和衡量自助率问题，不代表真实的业务情况）。

自助率问题解决的三部曲：发现问题、解决问题、衡量与验证：

01 发现问题

本案例采用可用性测试的方法，大致包含 3 个步骤：明确任务核心链路、实施任务测试、结论分析整理。1）明确核心任务链路在发现问题阶段，需要与产品经理确定 2 个内容：

• 产品的核心任务链路是什么，包含哪些节点；
• 每个任务节点的任务成功标准。

例如，本产品的一个核心任务是「完成一个模型训练任务」，包含 6 个任务节点，分别是：添加数据页面、数据上传成功、创建项目、创建实验、模型训练、运行任务；然后，确定每个节点的成功标准是什么，在实际的任务记录中，采用二分式的数据记录方法，某节点被完成则被记做 1，失败记做 0。 2）实施任务测试任务测试前需要准备一份给用户的测试任务书，以说明本次测试的任务范围，以及用户需要完成的操作； 在用户做任务的时候，记录员需要观察用户的任务完成情况， 顺利完成的记做 1，没有完成的记做 0；用户完成该任务后，需要对用户进行即时访谈，询问用户在哪里遇到了疑惑，并记录用户原声。 3） 结论分析整理最后整理分析测试结论，如下图表格所示：本次受邀用户 7 个，在核心任务的测试中每个节点的任务完成率分别是：85.71%、42.86%、28.75%、100%、42.86%、14.29%，由于每个人在任务链路的测试中都遇到了阻碍点，该阻碍点导致任务无法进行，所以每个人的任务自助率为 0%，总体的自助率也为 0%。 同时，也总结了用户原声报告，得到 11 个阻碍卡点的关键用户原声。

02 解决问题

解决问题的阶段，可以参照自助率设计指南，从用户任务的 5 个阶段出发一一解决。在指南中，提供了每个任务阶段的设计目标、设计策略、设计手法以及实际的业务参考案例。 任何一个任务的完成都将经历以下 5 个阶段：用户要知道产品可以达成什么目标、达成目标要完成什么任务、任务从哪里开始、任务过程中如何操作、任务的状态和结果，于是，笔者把在「发现问题」阶段总结的关键用户原声分类到不同的问题阶段，发现用户实际上在以下四个阶段出现了问题。 以下将一个个解决不同阶段的问题，本次以第二个阶段作为案例讲述。 首先，回溯原产品设计，找到用户问题。由于产品在设计之初发展过快，当时只注重功能的堆叠建设，首页只有针对一类角色（即模型计算任务方）的一个任务入口，对于另一类用户（即数据任务方）没有功能入口，所以不同的用户来到平台后不清楚各自要做的任务及流程。 指南中提供了「达成目标要完成哪些任务」阶段完整的设计目标、策略、设计手法以及每种设计手法的使用场景。 设计整体策略如下所示： 于是，可以参考指南确立设计目标和梳理设计策略：

通过梳理，平台有两类不同的角色，角色 1 的任务是完成模型训练，核心任务链路是管理数据-进行实验-管理实验-部署发布；角色 2 的任务是完成数据授权，核心任务链路是上传数据-授权数据。 在指南中提供了三种不同的解法，可以让让不同角色及目标的用户知道做什么才能实现预期目标，第一种是提供全局任务概览，第二种是提供核心任务的导引，第三种是提供强制任务体验路径，如下图所示： 最终，笔者选择了「全局任务概览」的方式，可以让新用户进入后快速概览了解不同角色的任务流程，每个流程的任务目标。 「全局任务概览」在指南中用决策树指引的方式分类了不同的任务类型推荐的设计解法，如果是上下承接的需要一次完成的有序任务，推荐将任务流程串联起来，并提供了单路径、多路径两种不同的表达方式；如果是相互独立的无序任务，推荐将核心任务展示出来即可，并提供了核心功能展示的表达方式以供参考。 由于本产品用户要完成的任务是单路径任务（任务过程无分支，可以依次一步步完成），所以最终选择了有序任务下的单路径任务的表达方式 并且指南提供了单路径可以直接复用的设计源文件： 于是，结合以上设计参考和本产品的设计策略，最终，为了解决让用户知道「达成目标要完成哪些任务」的问题，设计表达如下： 以上，通过「全局任务概览」简单的设计表达，便解决了让用户知道「达成目标要完成哪些任务」的问题。在指南中提供了每个阶段下可以参考的设计方式，我们一一回溯了用户问题，并针对性地解决了对应任务阶段的设计问题。

03 衡量&验证

为了验证问题解决情况，同样采用了可用性测试进行衡量。最终，核心任务的单个节点的完成率 100%，全程没有阻碍节点，自助率也达到了100%。衡量与验证过程中，虽然用户的核心任务链路自助率 100%，但是用户也提出了一些疑惑点，我们也进行了原声的整理，当自助率没有问题时，意味着产品的可用性得到了保障，根据这些用户声音，我们正在将本产品从可用转为易用的路上。

总结

最后，通篇总结一下 B 端工具型产品的自助率是逐步如何得到解答的：

• 最初，由于自助率课题太大，本组团队的小伙伴们都处于一团乱麻的状态，由于各个业务千差万别，这个问题似乎没有办法得到解决。
• 然后，通过多番讨论以及桌面研究，我们发现唐纳德·诺曼的《设计心理学》中早就对任务的实质做过解答，通过总结，我们将任务行为阶段归纳为了 5 个阶段：用户要知道产品达到的目标、达到目标要完成的任务、任务从哪里开始、任务过程中如何操作、任务的状态和结果。
• 带着这样的用户任务视角，我们开始在15+的业务中解决自助率的问题，后来我们发现，即使各个业务千差万别，但是最终在设计表达上大家的方法有趋同的地方（例如为了让用户知道达成目标要完成什么任务，大家都会采用全局任务概览的方式）。
• 最终，终于拨开云雾见月明，我们大量研究了其他产品如何让用户自助上手，提取解法的共性，得到了 B 端工具型产品自助率提升指南，以帮助更多的业务快速解决自助上手的问题。

自助率指南，提供了精准发现自助率问题的方法；以及从用户行为出发，正确确立每个行为阶段的设计目标、设计策略，并提供大量的可参考、可复用的设计源文件；以及可以科学衡量验证问题的方法。 由于指南涉及大量业务数据，目前没办法对外公开，所以分享给大家我们经历多番探索后的解题思路，希望能够对还在「B 端产品无法自助上手」问题上挣扎的各位小伙伴有所帮助！ 感谢自助率全体成员的共同努力!