怎么写产品帮助文档才能帮助用户？

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

尼尔森十大互动原则的最后一个原则——“人性化帮助原则”建议我们应该向系统提供帮助文档，以便用户能够尽快理解系统并熟悉操作。

事实上，用户友好的概念，我接触的第一件事是“帮助”。那时，老师说如果你遇到不能解决的问题，你可以去“帮助”找到相应的解决方案。虽然我当时不知道，但我很少使用这些帮助程序。但当时我认为这个软件对小白很友好，它告诉我们如何使用这个东西。虽然当时的帮助文件并不了解小学生。那是另一个问题。

在互联网时代，许多软件培养了用户习惯。用户在使用大多数软件时都有“没有老师”的感觉。但面对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. 展示重要问题

我开始写产品文档的时候，容易将产品文档写成各个模块的说明文档。因为有一些模块是展示模块，不涉及流程，也没有复杂的功能，对于这些模块就是图片加上干巴巴几句介绍。这样就导致写出来的帮助文档篇幅很长，没有重点，可阅读性也不高。所以在写的时候，要思考用户最关心的问题是什么，以及这个模块里复杂的业务流程有哪些。

房源的查看、账单的查看，这些简单的问题，完全不需要介绍，用户自然而然地就知道。而对于那些录入房源、手工入账、提现放款这些稍微深一些的业务问题才是用户想看的。所以产品在写之前，可以提炼出自己所负责的模块的一些重要流程以及主要操作。然后在此基础上，想着怎样以最少的文字进行最全面的讲解。