产品一般都会帮助中心，帮助用户解决一些不知道怎么操作的问题。因为使用场景的不同，B端的帮助中心使用频率比C端的高很多，这个时候，帮助中心的设计就更加重要。

“请问你需要帮助吗？”

在生活中，我们有任何问题都会请求别人的帮助；而在屏幕世界中，使用不同的软件我们也需要寻求帮助。

使用 Notion，我会通过 B 站的视频去寻找教程；管理待办事项，我需要使用 GTD 的理念才能高效归类；使用帆软，我需要对 数据分析类 的专业知识有所了解。

对于我们而言，去做任何事情都会遇到困难。但是 B 端产品当中，作为设计师的我们，需要去为用户解决困难。

为什么想要聊聊帮助体系，是因为现如今大多数的 B 端产品进入成长期、成熟期，开始意识到帮助体系的重要性。

比如在微盟的迭代复盘当中，就明确将帮助体系作为核心板块进行迭代，同样在京东的复盘当中也会有类似的观点。

你会发现随着行业的不断发展，产品用户不断增多，你需要去教育用户，让他们从能用产品到用好产品，只有深入理解产品逻辑后，才能增加用户黏性，后续才能更好为产品付费。

我们今天就来聊聊 B 端系统的帮助体系，讲讲究竟应该如何进行设计。

一、什么是帮助体系

1. 帮助体系的定义

帮助体系是“在用户使用产品过程中，系统所进行的提示与指引，从而提升操作效率、降低认知成本”。

它作为我们系统与用户之间的桥梁，能够通过预设的“信息”来解决用户的问题。

在理想情况下帮助体系本身是不应该存在的。因为一个“完美”的软件系统当中，所有的设计都应该是符合用户直觉的，根本不需要学习。

但是在 B 端系统本身就会存在行业门槛，同时系统当中包含有大量的 专业词汇、业务逻辑，甚至需要大量的学习才能够上手（主要是行业属性型产品），也就造成帮助体系是作为系统当中的兜底策略，能够解决 用户 与 系统 之间理解不一致的问题，也就是让三大模型[1]当中的理解能够一致。

[1]三大模型其中包含，用户模型、设计模型、心理模型。

1. 用户模型：描述目标用户的抽象，包括用户特征、需求等信息，助力设计者更准确地预测和满足用户期望。
2. 设计模型：产品或系统的抽象表示，包括设计团队对结构、功能、界面的构思，指导实际开发过程。
3. 心理模型：用户对系统工作方式的脑海理解，设计者致力于通过设计使用户心理模型与实际设计模型接近，提高用户体验。

帮助体系真的有这么重要，如果没有好的帮助体系，会存在以下问题：

2. 帮助体系的痛点

1）B 端系统越来越难

因为 B 端产品已经 从初期的基础功能向高级功能 开始过渡，因此你会发现系统当中会存在越来越多不能理解的设计。比如下面这个页面主要用途是什么？

正确答案就是筛选的组合条件。

目前 B 端系统都在去强调 通用自定义 ，很多功能都变得异常复杂，如果这时候无法通过帮助体系去解决问题，对于用户而言则会弃用这款软件，导致用户不断流失。

比如在座的各位设计师，为什么不愿意从 sketch 迁移到 photoshop ，其实就是因为 photoshop 针对的是更为通用的位图绘制的场景，所以它更难，很多功能也用不太上；而 sketch 则只针对的界面设计领域，相对而言达成目标更加简单。

2）企业投入成本高

帮助体系本身就是为用户进行服务，但一个系统有着糟糕的帮助体系，会导致 客服人员、技术支持 的压力巨大，只能通过人力解决客户问题。

因为现在的系统大多是为 中级用户、专家用户[2] 来进行的设计，没有完整的帮助体系就需要大量的 客服人员进行解答；技术支持进行远程协助；实施人员进行现场培训，这都需要企业投入大量成本。

并且产品也在不断更新，我们还需要反复地教学用户新功能如何使用。如果没有良好的帮助体系，就只能用“口口相传”的方式表达设计理念，这也是需要花费巨大成本的。

关于企业成本，越是成熟的产品企业投入越高。在 Salesforce 团队的分享当中提到过，因为他们用户量很大，一次产品更新所需要投入的成本在千万美元。因为背后涉及到 员工学习、用户培训、更新讲解 很多成本，这些都不可忽视。

[2]中级用户、专家用户：我们把 B 端系统的用户群进行划分，主要分为 普通用户、中级用户、专家用户。其中中级用户是指对产品使用较为频繁的用户群；专家用户是指对这一领域有着自己独特认识的用户群。

3）产品角色多

在我们系统当中本身就会有很多角色，不同角色他们所关注的利益点并不相同。

对于帮助中心来说，就不能针对单一角色展开，需要更为全局的考虑每一个角色所关注的内容，需要给出当前场景下的合理的解决方案，才能搭建好用的帮助体系。

二、帮助体系的类型

正是由于上面提到的痛点，你会发现系统中需要帮助的地方非常之多，这也就形成了常见的八个帮助类组件：提示信息、新手引导、全局提示、帮助中心、人工客服、任务预设、智能助手、产品学院。

在这里的每一个组件都会有：提示方式、展示位置、呈现内容 等差异，我们便可通过这些维度分门别类的去做总结。

1. 提示方式的维度

提示方式就是在系统当中，是如何给到用户提供的帮助。它主要分为：主动提示与被动提示

主动提示：系统主动发起向用户提供帮助，其目的是为了让用户尽快熟悉系统。

常见的主动提示组件有：工具提示、新手引导、全局提示、任务预设、功能提示。

因为是系统主动发起，对于用户的干扰较为明显，所以在条件的判断上要更加的苛刻。

比如：新用户进入系统，不能有过度的主动帮助，在适当的帮助后就得让用户自主探索，如果这时候你刚完成一个新手引导、紧接着让你查看一个任务预设，同时旁边还伴随着全局提示以及小窗解释，这对于用户而言干扰过多，用户会极度反感。

被动提示：系统被动的向用户提供帮助，这类情况往往是用户遇到问题，需要自行寻求解决方案。

常见的被动帮助组件有：帮助中心、人工客服、智能助手、产品学院。

这类帮助通常整体的耗时都会较长，都是用户在遇到的疑难杂症时，需要进入系统的解决方案中进行寻找，因此需要花费大量时间，所以在设计时需要给出清晰明确的指引。

比如：帮助中心的分类、人工客服的快速帮助、智能助手的智能提示，都是在想要快速解决用户的疑惑。

2. 帮助范围的维度

帮助范围就是在系统当中，针对哪些模块提供的帮助提示。因为 B 端系统本身就比较庞大，对于帮助的对象也会有所不同，所以我们按照由小到大划分为 字段 – 组件 – 功能 – 系统。

1）字段层面

服务于系统当中的文字信息，是用于解释批注文字中的专业信息，它是系统当中最小的帮助单位。

通常字段帮助主要有：工具提示、文案提示。因为范围最小，所以使用的时候也较为频繁。同时字段提示大多数为被动提示，因此需要考虑它出现的位置，以及如何呈现帮助内容。

比如我们在文章当中，进行的专业名词标注；在系统当中的标签提示，都是属于字段层面的帮助。

2）组件层面

主要服务于系统当中的组件模块，它能够解释复杂组件的各种逻辑，帮助用户快速进行组件使用。

常见的组件帮助有：提示信息、全局提示。在 B 端产品当中组件规范化已经深入人心，其实在组件规范的过程当中，就会去考虑对应的帮助提示，便于用户快速理解。

比如在输入框中，就可以通过 popover 进行信息提示，帮助用户快速理解输入的格式与内容要求。

3）功能层面

专注于系统的功能模块设计，它是去解决这个功能究竟应该如何使用，具体配置规则的重要方式。

我们可以使用：任务预设、解释页面、帮助中心（会包含功能的维度） 等方式进行解决。

因为功能本身逻辑会特别的多，我们对于需要少量解释的情况，可以使用解释页面、任务预设来解决，如果内容较多，则会考虑跳转到 帮助中心 以及 系统层面 的方式进行解决。

4）系统层面

用于解决系统当中的所有问题，它是在聚合前三种范围，并且讲解全面完整的进行呈现。

常见的 帮助体系、漫游引导（新手）、产品学院，都是系统层面的帮助体系。

系统层面就需要全面、易查找，因为系统当中会存在很多问题，所以如何快速解决，就像你们去到一个大型的图书馆，怎样才能够找到你心仪的那一本书一样，系统层面的就是这个图书馆，因此层级的合理性，内容的划分都格外重要。

三、帮助体系的用法

帮助体系当中的组件非常多，为了让大多数同学能够用于实际的工作当中，我们将其分为 初创期、成长期、成熟期 三个阶段。

因为每一个阶段对于帮助体系的需求并不相同，我们所采取的设计策略也会有所不同，大家可以根据自己产品的目前状况做到上手即用。

1. 初创期 – 提示信息

首先，在系统刚刚搭建的初创期，我们想到的便是投入产出比，“希望能够花小钱，办大事”。而大多数的帮助方式都格外复杂，需要增加很多工作量，所以初创期考虑的第一个帮助方式便是提示信息。

在提示信息当中，主要包含有 工具提示、文案提示、错误提示，

我们需要了解这些提示信息，并且在工作当中跟随每一个需求同步设计，这样就能提高我们的投入产出比。

工具提示：通过用户主动触发的方式呈现系统当中的文字说明，来解决用户对系统当中字段、组件信息不理解的情况。

在设计当中我们要求能直接展示的信息最好就不要隐藏，而使用工具提示主要是呈现层级较低的内容，同时又可以避免信息过载导致页面臃肿。

文案提示：将重要的文字信息通过直接平铺的方式展示在页面当中，能够辅助用户进行输入与决策。

在文案提示当中，主要有三类使用场景：辅助说明、占位提示、重要提示。

错误提示：在用户操作过程中，无法通过校验规则而出现的错误提示信息，目的是让用户及时的发现并且纠正问题。

错误提示一般都与组件设计密切相关，是我们在进行基础组件设计时重要的一部分。

在我们使用提示信息时，是需要考虑将提示的文案进行精准的表述，并且描述时，同样会存在很多技巧，比如：

对于专业名词，我们需要通过 「」 进行标注，这样能够让用户快速理解其含义，如果不知道可以通过搜索引擎进行查询；

对于对比信息，通过 序列化的 的方式进行呈现，让用户能够快速理解其中差异；

对于文案描述上，应该更多的使用口语化描述，不要为了解释一个专业名词而引出一堆专业名词，增加用户阅读门槛。

这些都是我们在使用工具提示上所需要注意的，帮助体系当中对于文案的使用颇有讲究，这部分就留着我们后面有时间再进行讲解。

2. 初创期 – 新手引导

由于初创期会存在大量的新手用户，因此新手引导会让这些用户理解产品的基础逻辑。

新手引导：是指在用户初次使用系统时，通过讲解系统设计思路，帮助用户熟悉和了解产品，提高其使用体验。新手引导的目的是降低用户的学习难度，减少初次使用时可能遇到的困惑和挫折感，从而提升用户对产品的初次印象，促使其更好地上手使用。

常见的新手引导主要会有 漫游引导、视频介绍、任务预设 三种方式， 而在初创期，我们一般只会使用漫游引导、视频介绍。因为实现起来较为简单，任务预设主要针对功能部分所展开的，因此放在成长期进行实现。

在设计过程中同样需要注意以下问题：

• 在形式上，尽可能少的去使用文字。因为这是和用户第一次见面，使用文字会感觉到比较“寒酸”，常见做法是通过 视频 的方式讲解产品理念，能够让用户快速理解其含义。
• 在内容上，趣味性同样重要。因为新手引导整个形式会非常干扰，用户第一次进入，需要先有趣才会让用户有更多的探索欲望。
• 在设计上，预留合适的出口。因为新手引导通常整个流程周期很长，因此需要留下出口方便熟悉的用户快速退出。

3. 成长期 – 帮助中心

渡过初创期迈入成长期的产品，帮助中心一定是必不可少的。

帮助中心就像是一个产品的完整知识库，能够展示平台所有的信息，它能够帮助用户了解整个系统全貌，同时也能教育用户，让用户在系统中游刃有余，使用户水平不断提高。

在设计帮助中心时，我们需要注意以下几点：

1）清晰的框架结构：因为帮助中心的内容量很多，我们会按照 用户角色、使用目的 等维度进行划分。

比如在滴答清单会按照使用目的划分为：新手指南、最佳实践、常见问题、设计理念、更新动态，同时会按照产品功能与特色功能两个维度进行划分。

在飞书应用端帮助模块中，按照 用户角色 划分为：我是成员、我是管理员，这样去使用的时候，通过当前个人角色进行选择可以更清晰的推荐解决方案

同时 B 端产品本身角色属性很强，可以按照角色、类型进行划分，能够将帮助体系设计得更为易用。

2）良好的更新机制：帮助中心是需要根据产品更新迭代不断地进行调整，因此我们要确立良好的更新机制。

通常帮助中心都是由 产品负责功能迭代的设计，然后交给运营人员进行内容文案的优化，设计师辅佐提供成熟的图片素材，最后进行更新。

建立完善的协作机制就能够持续的进行造血，提供更多优质的帮助内容。一般在刚开始搭建时，通常会利用各种文档类软件快速搭建，既简单又高效。

比如 raycast 就是在 notion 当中维护其帮助文档～ （顺便安利一下 raycast 设计师提效神器）

3）生动的内容形式：好的帮助中心一定要“活”起来，更注意用户的情绪价值。因为用户进入帮助中心情绪肯定难受，同时帮助中心又是一个被动方式进行帮助，整体的用户感受也会非常糟糕，因此考虑呈现活的形象，更容易树立品牌形象。

首先在帮助中心入口设计上，我们可以呈现更为生动的员工形象，这样能够缓解用户情绪，是一个情感化设计的好点子。

同时在内容呈现上，基础内容可以多以视频的方式进行讲解。对于初次接触产品的用户，能够通过教学视频更直观，更容易的了解内容的全貌。

4）预留入口更多可能：同时在帮助中心处，预留 在线客服、交流群 等入口，方便用户在当前帮助中心没有解决问题的情况下，有一个解决问题的出口，并且设计师可以在后续做用户研究时，通过群成员进行定性研究等。

4. 成长期 – 人工客服

人工客服是在用户有疑惑时，通过人工的方式去解答用户所遇到的各种问题，就像我们拨打 10086 去咨询中国移动的各种问题，在 B 端系统当中也需要有自己的 10086 来解决问题。

在系统当中，通常会在全局菜单处提供一个人工客服呼出入口，让用户能尽快找到对应人进行解决。

同时在小的功能模块当中，也可以将人工客户放在右下角进行访问。

人工客服几乎在每一个平台都会存在，虽然问题被处理的效率会大大提高，但是对于企业而言，相应的成本也随之提升。我们一般不会推荐，这也是为什么很多人工客服难以触达到的原因（比如 微信联系人工客服，需要有漫长的跳转）

作为设计师，其实是有必要参与的客服的服务当中，通常可以采取轮岗制的方式，一个月安排一天时间，深入接触用户，了解他们的真正痛点。

5. 成长期 – 任务预设

任务预设是新手引导当中的一个分支，它主要是在系统成熟后，会存在很多独立的新功能，这时候我们便可以通过任务预设的方式将其进行引导呈现。

因为在B端产品的配置端，通常其逻辑都会比较复杂，我们可以通过任务预设，让用户能了解其设计逻辑。

比如我最常使用的 Focus 软件，当你使用时，会让你立即使用它的核心功能。

6. 成熟期 – 智能助手

当系统进入到了成熟期过后，你会发现在系统当中会存在很多通用的问题，其实我们可以通过智能助手的方式进行解决。

比如现在在京东、淘宝，当你提问常见的问题时，智能助手都会对于你的问题进行快速的回答。同样当系统当中有各种问题时，我们可以让智能助手快速提示对应的解决方案，进而解决用户的问题。

为体现智能化，可以考虑与AI进行结合，通过正常的沟通对话，快速解决用户遇到的各种问题。

比如最近 小鹅通就将 AI 与智能客服进行结合，让问题更快解决，同时根据 AI 也能提供更多商家需要的服务。

7. 成熟期 – 解释页面

帮助体系本身就是要解决 在特定的地方，为特定的用户，提供特定的帮助，在 B 端产品里面特定的地方一般指的就是一个核心的功能。

为清楚了解该核心功能，我们可以将「解释页面」通过抽屉的方式，让用户快速知道当前页面所有会遇到的问题。

这种做法的逻辑就是将帮助中心里重要的帮助提示前置到问题页，抽屉的方式让用户不用跳转，同时也能快速查看页面的详细解释。

比如在飞书审批当中，就能通过解释页面，查看不同步骤的配置视频指南。

8. 成熟期 – 产品学院

产品学院是在成熟期后，是企业为想要深度使用的用户，提供一个学习的渠道。

因为在专业领域较强的产品当中，本身就会包含有很多逻辑，是需要通过系统的学习，才能够正常的使用软件。比如在帆软当中，我们就能够直接报名课程，并且会有学习班，针对不同的分类进行学习。

我们通过学院的方式，将产品当中的精华通过线上教学的方式传授给我们的用户。因为通过这样的方式，才能够培养初级、中级用户，让他们能够快速提升，更加深度的使用这款产品，同时也可以增加用户的粘性。

四、如何搭建帮助体系

关于帮助中心的搭建，我们还需要考虑几类原则，因为大多数场景都可以通过这几类原则进行解决。

1. 就近解释

帮助体系本质上就是要解决用户的问题，如果过程需要花费非常多的时间，消耗大量精力，就会显得得不偿失。因此在设计时，我们需要考虑将答案快速触达，这样就能更高效的为用户解决问题。

比如在一个优惠券配置页面，对于优惠券的不同差异，我们需要快速准确的进行展示，而不是需要让用户进行 hover 触发。

2. 高效传达

在用户阅读帮助内容时，就会打断之前的阅读任务。所以帮助体系不是终点，而最终目的还是想让用户回到之前的任务当中。

高效传达主要是在内容上优化展示形式，比如简化帮助内容，考虑角色更为合理的展示，先展示更为容易的内容再展示复杂的逻辑，这些都能够起到高效传达的作用。

3. 清晰明确

清晰明确不光是指内容清晰，你还需要了解用户的场景，尽可能采取最简单的方式。比如告知整体流程需要花费多少时间，具体流程步骤，通过清晰的方式能够让用户更为明确的进行操作。

4. 形式多样

在产品的设计形式上，我们可以有 图片、文本、视频、动图、音频 等多种手段进行表达。而不同的手段都能够在用户特定场景下进行学习。

比如 图片，你会发现它就会比单纯的文本表达更为明确；动图，又会比单纯的图片讲得更高效；视频，又会伴有音频的提示更容易理解。因此形式上的多样性才能保证系统的完整性。

5. 克制理性

对于帮助体系，也不是越多越好。作为设计师的职责就是要将复杂的系统更为简单的呈现，如果每一个模块，设计师都不会思考，遇到问题就帮助体系，很容易造成系统依旧难用。

因为并不是每个用户都会去仔细阅读，所以做好设计，理性使用帮助会更为重要。

讲了这么多，对于帮助中心的设计，我们只有了解到宏观的内容过后，才能够进行更多微观的设计。

而体系的搭建，也是一个循序渐进的过程，因此我们在设计时，需要不断反复思考才行。

希望大家能够根据阶段，合理的搭建帮助体系。