如何建设让用户“爱不释手”的B端产品帮助体系？（上）

B端产品业务场景和流程复杂，使用门槛高，为了帮助用户更快上手，需要建立帮助体系，引导用户正确使用产品。作者结合自己的工作经历，与大家探讨下B端帮助体系的建设方法及实践，希望对你有所帮助。

B端产品业务场景和流程复杂多变，产品使用门槛高。为了让用户更好地使用产品，需要建设帮助体系，以引导用户按照预期的产品目标来使用产品。然而，B端复杂的业务特征也决定了帮助体系的复杂性，且B端用户往往惰性较强，自主学习意愿弱，如何引导用户自助学习也成为一大难点。

本篇文章，笔者结合工作经历及个人认知，同大家探讨下B端帮助体系的建设方法及实践。文章内容较多，将分为上、下篇。

上篇主要讲解B端产品帮助体系设计的背景、目的和设计要点，下篇将以Salesforce为例，分享B端产品端帮助体系设计的优秀实践。

一、B端产品帮助体系设计背景

1. B端产品帮助体系定义

帮助体系是什么？总的来说，帮助体系并不是单一的某个功能，而是一种体系化的能力，帮助用户更好地使用产品，需要通过不同手段来实现。

2. B端产品帮助体系特征

对于B端产品而言，帮助体系具有刚需性。首先，B端产品业务流程复杂，专业能力要求高，使用门槛高，导致用户难以快速上手，无法通过自己使用产品高效完成任务，需要一定的帮助指导。

如果通过客服、技术支持等人工服务，成本非常高，会挤占研发收入。而产品帮助体系具有可复用性，如果建设得好，可以有效驱动用户自助解决，降低研发人员的支持成本。

因此，对于ToB产品，帮助体系必不可少，是用户自助解决问题的强有力支撑。

B端帮助体系具有刚需性

此外，帮助体系具有复杂性。因为B端帮助体系的建设和管理涉及多个用户旅程、多个角色、多个渠道、多个平台。

首先，在战略层面，B端产品帮助体系贯穿客户、用户、伙伴、开发者、员工等各角色从发现、评估、购买到实施、使用、续约增购的全旅程体验。

在范围层面，帮助体系所涉及的应用场景主要包括产品知识赋能与产品培训、产品服务支持、产品推广与产品创新3大类。

在结构层面，帮助体系的内容构成非常多样化，包含但不限于体系化帮助文档、产品授课培训、用户自助服务、实践案例、产品新特性通知等等，而为了满足不同场景需求、不同用户偏好，内容展现形式也需随之多样化，包含图文、视频、交互式课件、直播、tips、步骤式向导等等。

而建设和管理帮助体系，涉及运营、产品等不同岗位人员，也需要公司总部协同机构、伙伴等共同建设，同时还需要团队建立内容规范、开展培训来指导内容输出者高效生产内容。

为了更好地管理内容和监控效果，还需要内容管理平台、数据中台等能力支撑。内容建设完成后，还需要组合包装，分发到不同渠道，包括产品端和社区、官网、帮助中心等站外渠道。

可见，对于B端产品，帮助体系是一个非常复杂的系统结构，涉及多角色、产品内外多渠道，且用户需求愈加多样化、个性化。

B端帮助体系具有复杂性

3. B端产品帮助体系建设难点

尽管帮助体系对B端产品而言是必不可少的，但由于其复杂性，在建设过程中遇到不少难点：

首先，对于用户而言，B端的帮助文档内容较为晦涩难懂，且由于业务链路较长，常常会面临内容无法触及用户或触达不及时的问题。而在产品端的帮助内容，由于没有合理的引导或交互设计或培育用户习惯，很多用户难以发现。

此外，相比C端产品，B端客户非常注重数据安全性，用户数据获取较难，用户画像不够清晰、细致，导致B端产品的帮助体系内容推荐的智能化程度较低，难以根据用户角色、产品使用经验精准推送不同的内容。客户系统管理员也难以根据企业自身情况定制化帮助内容。

而对于帮助体系的运营人员而言，内容多，还涉及不同版本，维护难、成本高。同时，由于前期监控指标体系的不完善、用户画像的缺失，一方面，内容难以精准触达用户，另一方面，难以了解用户在系统中的真实使用情况和运营内容的有效性。

B端产品帮助体系建设难点

4. B端产品帮助体系建设意义

可见，B端产品帮助体系建设是块难啃的硬骨头。但如果建设好的话，将发挥巨大的作用，且作用随着用户的增长、内容的逐步完善，可能呈现指数增长趋势，而不是边际下降。具体而言，它可以提升产品易用性、传递产品价值、提升产品满意度、助力获客、增购等。

B端产品帮助体系建设意义

二、B端产品帮助体系设计要点

那么，如何啃下这块难啃的硬骨头呢？接下来，我们一起来探讨下B端产品帮助体系的设计要点。

好的B端产品帮助体系需要满足什么呢？

整体而言，设计B端产品帮助体系时，应该遵循以下原则：

1. 一是易获取，可以被直接发现；
2. 二是场景化，需要聚焦于用户核心任务；
3. 三是可执行，需要列出帮助用户执行任务的具体步骤；
4. 四是可运营，即帮助内容可配置，效果可监控
5. 五是智能化，能根据用户画像智能推荐帮助内容；
6. 六是可定制化，支持客户自定义部分帮助内容。

前三个原则是最基本的原则，保证帮助体系的可用性，而第四、五、六原则是相对进阶的设计要点，可以让帮助体系更好用、更易用。

B端产品帮助体系设计的整体原则

1. 内容组织

在前述痛点梳理中，我们提到过：对用户而言，B端帮助内容较为晦涩难懂。因此，在内容组织上，应尽可能地站在用户角度，把复杂信息转化为易于理解的信息。怎样才可以做到呢？

比起缩小内容篇幅，更重要的是要想办法讲清楚，整体思路是通过可视化、场景化、价值导向化的手段，把复杂信息转化为易于理解的信息，减轻用户的认知负担。

• 可视化指的是通过概念图、流程图、表格形式，把抽象难理解的逻辑/概念可视化呈现；
• 场景化指的是结合业务场景给出配置推荐，让配置逻辑更易理解；
• 价值导向化指的是从功能价值和用户利益出发，优于直白的功能描述。

内容组织：把复杂信息转化为易于理解的信息

2. 内容呈现

而在内容呈现上，基于产品界面的帮助指引有三种形式：

1. 一是主动式帮助：主动向用户提供帮助，让用户尽快熟悉系统界面；
2. 二是被动式帮助：用户遇到问题时，系统提供帮助去指导用户接下来怎么做，用于排除故障和提高系统的稳定性；
3. 三是自动式帮助：预判用户的预期，直接为用户提供建议和帮助，或者直接帮用户自动执行一些任务。

B端产品帮助体系呈现形式

主动式帮助的目的是帮助用户熟悉界面，通常出现在两种场景中：一是对新用户进行帮助教学；二是新功能上线后，对老用户进行提示。

在交互上，可以通过引导页、模态弹窗、向导引导、文字提示和工具提示来实现。

引导页：是在用户首次进入产品或者产品中某个独立功能的时候，将产品最核心的功能加入一些品牌基调展示给用户，也可加入一些插画或者视频吸引用户；文字部分不要长篇大论，提炼最核心的内容传达给用户。

模态弹窗：是在用户第一次打开某个特定页面时出现，让用户聚焦当前内容，同时保留二次进入入口。常用于「版本更新提示」「新功能介绍」「常规通告」等应用场景。缺点是用户容易忽略或者无视，直接关掉，引导的效果差一点，所以弹窗教程建议保留二次进入的入口，当用户需要的时候可以顺利找到。设计上可在文本的基础上加入图片、插画、动画、视频讲解和实例演示等。

向导引导：是在用户首次进入相关页面，且无操作时出现。有明确的指向性，提前告知用户具体功能的使用场景，不仅会指向界面中的某些特定区域，同时会随着操作的位置发生变化，让用户实际感知到功能的整个运转逻辑和流程。

针对局部功能升级或围绕某个操作的提示说明，一般与元素绑定关系较强，核心功能和操作在视觉上突出显示，可让用户直观了解关注点，提升功能触达率。为了让用户高效获取信息，一次仅显示一条。具体使用过程中有三种交互方式，随着提示强度由强到弱依次是：「分步式引导」「气泡提示」「闪点提示」。

文字提示：作为最直观的信息展示，一般会采用直接平铺的展示方式，针对一些功能较多、逻辑较为复杂的页面，将对用户有帮助的信息直接放在页面上从而指导用户的行为，具体的使用场景有：「页面功能辅助说明」「占位提示」，占位提示可使用户能够快速明确输入规则。

工具提示：比文字直接展示要更简洁降噪，没有直接进行展示，而是在用户需要的时候通过悬浮或者点击元素以气泡的形式唤出。在设计形式上有短暂性、匹配性、简明性的特点。

短暂性指工具提示出现和消失的时机需要恰当和短暂；匹配性指工具提示需要出现在与之关联的元素附近；简明性则是对工具提示承载的文本内容提出了要求，要尽可能具备简短性和描述性。

主动式帮助适用场景及交互形式

主动式帮助示例

若将被动引导映射到生活中的场景，可以看作是手机地图导航软件，当你不知道该怎么走或者迷路的时候才会主动去打开地图软件进行导航。另一个类似场景是产品说明书，在使用前或者在遇到不会用的功能的时候才会去查阅说明书。

无论是导航软件还是说明书，它不会自动把全部内容展示在我们眼前，都需要我们自己去查找。沿用到互联网产品中，被动引导是指用户遇到问题的时候，系统能够提供一些帮助，去指导用户接下来怎么做。

被动式帮助一般会依托于主动式帮助。在产品发展的初期阶段，主动式帮助是必须的，当产品发展到一定规模具备一定成熟度后，被动式帮助的引入就可以极大地提高产品整体的使用体验。常用的被动引导有：帮助中心/帮助文档、客服支持、全局常驻性功能。

自动式帮助的核心目的是通过一些系统自动化处理的方式来增加系统的容错性，最大化减少用户的决策压力。当一个系统足够聪明（或者背后的产品设计者考虑足够全面），能够预判用户的预期，那么它就能非常主动地给用户提供建议和帮助，甚至帮助用户自动执行一些任务，好比说：我先帮您解决了一些可能会出现的问题，同时我猜您会大概率会需要这些帮助。

自动式帮助主要将复杂性转移给了系统，从而减少用户的决策步骤和操作风险。针对一些用户操作风险较小且系统能力能够支持的场景，可以直接交付系统来自动完成。针对一些用户操作风险较大且系统能力也能够勉强支持的场景，可以提供部分选项供用户进行选择，同时提供必要的容错能力。

常见的交互形式有四种：

1. 一是模板/方案设计，将高频的内容录入、属性配置场景封装为模板或方案供用户选择；
2. 二是错误校验，当操作出现输入错误时，为用户展示明确的提示性消息，引导用户修改内容；
3. 三是自动纠正，如自动纠正不符合规定格式的数据或错别字、自动识别数据类型并进行分类、容错性较大的搜索匹配等；
4. 四是智能推荐/填充，系统自动提供内容供用户进行选择，帮助用户做出决策，前提是平台有足够的数据积累，如默认参数的预设、记住并自动显示上一次输入的内容等。

被动式、自动式帮助适用场景及交互形式

被动式、自动式帮助示例

3. 设计要点

前面已介绍了帮助体系设计的整体原则、内容组织方法及三种帮助内容呈现形式，那么如何基于原则，选择恰当的帮助类型，来设计出合理的帮助体系呢？

整体原则和目标是：结合用户生命周期，在不同阶段为用户提供恰当的提示与指引，通过组件的灵活应用及能力创新，帮助用户降低认知成本，提升操作效率，确保用户在整个系统中顺畅的进行功能体验，提升系统在用户感知中的稳定性和可靠性。

B端产品帮助体系设计要点

比如说，新手期、使用期、迭代期和培训期，用户的诉求是不同的，帮助体系相对应的教育目标则不同：

新手期是用户对产品产生第一步信任的关键时期，直接影响到新客活跃度，因此新手期的核心教育目标是让新用户尽快体验到产品价值，对产品产生第一步信任。对此，可通过新手Onboarding引导来帮助用户快速上手产品，形式包括但不限于：新手任务、全局导览、全局弹窗等（首次进入产品界面），进入具体功能页后可用空白页及内容示例/模板来进一步引导使用。

新手期帮助引导方式

度过新手期，到了正式的使用期后，用户的诉求变为使用顺畅，遇到问题时能快速得到帮助，因此，用户教育的目标随之变为随任务场景在产品端适时提供帮助，同时建设帮助中心、智能客服提供自助查询。

我们可以将用户使用产品完成任务的过程细分为操作前、操作中和操作后三个阶段，在不同阶段的教育目标侧重点虽不同，但整体原则是用户教育应贯穿整个使用阶段，随任务场景适时提供合理有效、触手可达的帮助，降低用户的受挫感，提升产品的易用性。

1. 操作前的核心目标是第一时间透传重要信息，加深用户对功能的全局认知，深化理解，助力精准触达，对应的帮助展现形式主要有全局引导/提示、模态弹窗、工具提示等.
2. 操作中的核心目标是助力提效，就近提供提示说明，让用户知道做什么、怎么做，对应的帮助展现形式主要有文字提示、信息预置、智能推荐、预览能力、工具提示等。
3. 操作后的核心目标是及时响应操作结果，将功能运行情况、数据的对错反馈给用户，并配套解决方法，对应的帮助展现形式主要有toast、表单错误校验、模态弹窗、独占式反馈等。

而帮助中心、智能客服等则主要作为辅助帮助，虽说不会在操作前、中、后主动地出现，但一直都在，用户在任何时候都可以通过它们自助查询、自助解决问题。

另外，当管理员在产品后台进行功能配置时，用户教育的基本目标是帮他高效顺利完成任务，但更高阶的则是要传达功能配置逻辑与功能间的联动关系。从“知道怎么配置”到“理解为什么这样配置”，结合业务理解把功能用深、用好。

不同任务阶段的帮助体系设计目标及展现形式

然后在产品的升级迭代期，用户的核心诉求是及时得知并上手新功能，且新老使用体验不断裂，对应的用户教育目标则是新功能可以有效触达用户，老用户体验可以平滑过渡。

对于一个产品而言，精心研发上线了一个新版本，用户却不知道、不会用，实属可惜！且如果有定期的新版本触达，用户会觉得这款产品一直在更新迭代，稳定、有发展潜力，能有效提升用户粘性。

要做好迭代期用户教育，需要界面内教育引导和运营推广共同发力。不是所有新功能都需要教育引导，只有在用户高频、核心使用路径上新增或升级的功能、或界面布局发生重大变动时才需要教育，而技术上的性能优化则不需要教育。

整体而言，迭代期的用户教育策略可分为三个方面：

1. 一是更新前有效触达，更新后引导上手；
2. 二是沉淀教育规范，搭建CMS运营工具，推动教育引导标准化；
3. 三是保证老数据迁移，使用体验平滑过渡。

迭代期用户教育策略

最后，在服务培训期，用户的诉求是了解与自身业务相关的功能；经销售/售后的诉求是统一产品认知；对应的教育目标和手段是用户培训分层传达、教育内容多渠道应用。比如说，产品的用户可分为系统管理员和普通用户等不同角色，面向这两类不同的教育对象，应差异化制作教育内容。

上篇内容到这里就先告一段落了，下篇将以B端龙头产品Salesforce为例，分享B端产品端帮助体系设计的优秀实践，包括Salesforce产品帮助与服务蓝图、产品内置帮助体系介绍、场景化帮助体系设计指南、亮点总结等等，敬请期待~

​Read More