怎么写帮助文档才能帮助用户?

产品帮助文档篇幅视产品的复杂度来定,有大有小。帮助文档可以向用户展示业务操作步骤,使用户能够边看边操作。

尼尔森十大交互原则的最后一个原则—— “人性化帮助原则” 提出,我们应该给系统提供一份帮助文档,让用户能够尽快了解系统,熟悉操作。
其实关于用户友好这个概念,我最早接触到的是 word 的“帮助”。那个时候老师说,如果遇到不会的问题,可以到“帮助”里寻找相应的解决方案。虽然我那时候懵懵懂懂的,很少利用这些帮助的方案。但是那时候我觉得这个软件对小白是友好的,它会教我们怎么用这个东西。虽然那个时候的帮助文档对一个小学生来说看不懂。那就是另一个问题了。
在互联网时代,很多软件都把用户习惯培养起来了。用户对大部分软件的使用都有一种“无师自通”的感觉。但是在 To B 软件面前,尤其是业务复杂且深入的大型 To B 软件,用户会显得有些束手无策。
那么这个时候,一份简单易懂的帮助手册就显得尤其重要。如果帮助文档写得好,不仅能够给用户留下良好印象,同时还能大大减小培训成本。产品帮助文档的篇幅有大有小,这个视产品的复杂度来定。
帮助文档其实大概有两类,一类是在网站上的“帮助中心”,帮助中心的问题是一些通用的问题,比如这款软件适合哪类规模的公司、产品的定价和版本选择等等入门问题;而帮助文档一般是内嵌在系统里的,着重于向用户展示业务操作步骤,用户可以边看边操作。

一、帮助中心

有些比较大型系统的网站上一般会有“帮助中心”这个模块,上面有用户会想要了解的关于产品的内容。

1. 腾讯云

腾讯云算是一个典型的例子了。由于旗下有很多产品,所以帮助文档也整合成了一个平台,汇集了所有产品的帮助文档。用户可以通过类型查找、输入关键词搜索找到自己想要了解的产品文档。



当点进具体的产品文档,可以看到产品文档由多个部分组成。从产品介绍、购买说明、名词解释到使用场景、业务操作、常见问题说明,整个帮助文档可以说是分类明晰,简单易懂。


商业智能分析的帮助文档
除了文字帮助文档,腾讯云文档平台还有视频教程,即云学院帮助用户了解产品以及熟悉操作。

云学院
如果说上述的帮助文档是帮助小白了解产品,那么“API 中心”和“SDK 中心”则是提供给开发人员的帮助文档。

API 中心

SDK 中心

2. 阿里云

和腾讯云类似,阿里云的帮助文档也是系统而详细:既有文字文档,又有学习视频。和腾讯云略微有些不同的是,阿里云的文档有非常详细的基于系统的业务操作指导。这本应该是内嵌在系统内的帮助文档,但是阿里云却把这些详细的文档放在了平台里。

详细的充值流程
可以看到,除了详细的充值流程,还有例外情况说明以及常见问题的解答。这不仅仅是一份帮助文档,如果用心去钻研的话,这也可以是一份详细产品学习资料。不得不说,开源的很彻底,很优秀。

3. sales force

相对于腾讯云、阿里云的详细的帮助文档,著名的 SaaS 产品 salesforce 的帮助文档就不涉及具体操作。可以看出,对于具体的业务流程,Salesforce 是倾向于引导用户申请免费试用的。
因为在常规的产品概述、功能介绍中涉及到具体的操作流程,都会跳转到申请免费试用的页面。Salesforce 的问题解答主要集中在 FAQ(常见问题解答)里了。FAQ 里的问题是常见的一些小白用户对于产品的一些入门、定价、实施问题。下面以 SalesCloud 为例子:



如果说 Salesforce 的帮助文档很简单,这也不公平。除了产品介绍和 FAQ,它在整个帮助文档中还附上了很多链接,这些链接中会有一些其他的讲解页面,或者说是一些列表,又或者说是一些说明书。




比如我就找到了一份实施指南。但是里面也是简单的介绍,并没有具体的流程。

4. Word

上文说到了 Word 的帮助,现在 Word 不仅在软件里有帮助文档,在网站上也有“帮助和培训”。

软件里的帮助

网站里的帮助和支持
Word 软件里内嵌的是常见问题解答,网站里的帮助和培训则是详细的操作流程。其实如果是将网站的链接放在软件里的“帮助和培训”里显眼的地方的话,那应该是最好的。

二、内嵌帮助文档

说完了那些文档平台的帮助文档,现在来说一说系统内嵌的帮助文档。系统内嵌的帮助文档主要是帮助用户了解操作流程。尼尔森认为帮助文档的重点是 “任何帮助信息都应该可以方便地搜索到,以用户的任务为核心,列出相应的步骤,但文字不要太多”。
软件里的内嵌的帮助文档看似简单,但其实细节也很多。有的软件的帮助文档的布局排版都非常随意,而且内容全部都是文字,或者全部都是图片,一眼看过去,密密麻麻,找不到重点。那么,内嵌的帮助文档应该要怎么写呢?

1. 流程清晰

产品在写帮助文档的时候,首先自己要非常熟悉流程以及各个流程中状态的变化。比如说,手工入账、管家结账,那么产品经理应该自己首先弄清楚什么时候会在手工入账产生记录,什么操作会改变账单的状态等等。
如果产品自己不清楚,自然而然在帮助文档里写的也是非常糊涂的。此外,如果一个流程牵扯到多个终端,那么也要写清楚在各个终端的操作会引发什么状态,即记录全流程。比如说手机端进行的操作会引发 Web 端的变化,这也要写清楚。

2. 文字要少

帮助文档中,文字不能太多,主要是描写步骤。然后辅助截图,以箭头指示操作按钮。
如果帮助文档文字太多,会影响用户的阅读体验,让用户没有耐心阅读下去。

3. 展示重要问题

我开始写产品文档的时候,容易将产品文档写成各个模块的说明文档。因为有一些模块是展示模块,不涉及流程,也没有复杂的功能,对于这些模块就是图片加上干巴巴几句介绍。这样就导致写出来的帮助文档篇幅很长,没有重点,可阅读性也不高。所以在写的时候,要思考用户最关心的问题是什么,以及这个模块里复杂的业务流程有哪些。
房源的查看、账单的查看,这些简单的问题,完全不需要介绍,用户自然而然地就知道。而对于那些录入房源、手工入账、提现放款这些稍微深一些的业务问题才是用户想看的。所以产品在写之前,可以提炼出自己所负责的模块的一些重要流程以及主要操作。然后在此基础上,想着怎样以最少的文字进行最全面的讲解。

4. 统一模板

尼尔森的交互原则中,有一条就是“一致性原则”。这对帮助文档也适用。由于一般会是不同的产品负责不同的模块,所以如果不在一开始的时候统一模板,这会导致最后呈现出来的效果很容易五花八门乱七八糟。
帮助文档的模板最好是使用统一的模板,然后在页面上展示公司姓名和 logo。
样式其实有很多,有 word、有 ppt、有 pdf 文档。现在看下来,样式比较好的就是用 ppt 做好,然后转成 pdf 格式,这样的话,不管是页面展示还是在线观看,体验都更好一些。

5. 常见问题说明

内嵌的帮助文档也需要常见问题说明,尤其是一些常见的异常情况,更需要提醒。比如说一些隐性的限制,拒绝结算放款后第二天会自动进行结算发起放款申请,由于这些是通过定时任务来进行,很难在页面中告诉用户。所以可以在帮助文档中,解答用户的这些疑问。
下面是一个公寓管理软件的帮助文档。可以看出这份帮助文档,页面规范,有步骤、有重点、左字右图、有提醒,用户阅读难度不大,而且能找到重点,可以说是一份优秀的内嵌帮助文档了。


帮助文档并不十分重要,有的系统甚至都没有帮助文档。但是我认为帮助文档是用户友好的一个重要体现。帮助文档的好坏也是用户友好的一个重要体现。在写帮助文档的过程中,其实也是促进产品捋清楚流程、熟悉产品功能和业务的过程。
总的来说,一份好的产品文档能够提升系统的完整度,提高用户体验度、产品对系统的熟悉度,还能降低培训成本。一个好系统,产品人员是以一份优秀的产品文档结束的,而用户从一份优秀的帮助文档开始。
作者
异彩,微信公众号:一只蜗牛慢慢跑。从事房产管理系统的产品工作,关注 To C 产品的交互设计、运营、结构设计和商业模式。在成为一名优秀的产品人的路上努力前行。