如何写出好的产品帮助文档？
大多数程序员都不喜欢写文档，有写文档时间，还不如重构一遍代码。早前我也这么认为，究其原因，一则自己不喜欢也不擅长写文档，代码是给机器读的，只要语法和逻辑没问题，计算机就会听命执行，而文档是写给人看的，除了语法和逻辑，好文档还要照顾读者的心理；二则传统软件的客户对文档无感，它仅仅作为合同约定的交付物存在，客户压根就不会读这些文档，他们更依赖我们提供的现场培训和技术支持，让客户看文档自学太不符合甲方的身份了。
但现如今大部分软件产品都通过互联网向用户提供服务了，在线文档才是最高效的客户服务通道，我们熟知的那些开源软件都配有高质量的在线文档。好文档是优秀产品的标配，它不仅可以帮你带来更多的用户，而且还可以帮你服务更多的用户。作为互联网程序员的你，要是不懂如何写一份好的技术文档，都不好意思跟人打招呼，更别想做出好的产品。
- 好文档的评判标准是什么
无从下手，不知道从什么角度写，写些什么，这是我们经常遭遇的情况，那为什么会发生这种情况呢？通常是没有找到写作的意义，如果是为了交差而写，脑瓜容易卡壳，思路无法拓展。在敲键盘之前，我们先要想清楚这份文档是写给谁看的，通过这份文档可以帮读者解决什么问题。写作是我们输出影响力的一种能力，其最终目的是为了改变读者的信息、行为等，否则就容易言之无物。等明确了目标读者和意义之后，我们的思路也就打开了。
在想清楚这个问题之前，我们最好不要动手写文档，但真实情况是在不知道该写什么时，许多人就拿大量的实现细节来滥竽充数，包括代码片段和配置说明等，主要目的就是增加文档的篇幅，他的出发点不是用户需不需要，而是我擅长和熟悉什么，用户很容易被你的细节内容搞的不知所云。这就好比某个人的本领很高，总爱在人前炫技，而不是在帮助他人解决问题的过程中显露自己的本领，通常这种人很遭人反感的。
编写技术文档的过程中会遇到哪些常见问题呢？通常我们习惯一上来就非常详尽地介绍这款产品有哪些特性，具体怎么安装、配置和使用等等，其实大部分潜在用户都是初次接触此类产品，他对我们的产品还没有完整的认知，压根不知道这款产品到底能帮他解决什么问题，对他而言有什么价值，一上来就深入细节就很容易把潜在用户搞蒙。
记得当年研究生毕业准备答辩幻灯片，导师给我们传授了一些经验：“答辩就是将自己的研究结果展示给评委，改变评委对这个研究课题上的认知，以及对自己的印象，从而获得较高的评分。幻灯片最好从Why开始，告诉评委这个研究课题的背景和意义，有了这个上下文做铺垫，评委才可能对你的研究感兴趣，才会跟随你了解后面的 What 和 How。”
非功能特性是依附在功能特性上的，一款对用户毫无价值的产品，即使其非功能特性很优秀，那也引不起用户的兴趣。技术文档的开篇必须要通过介绍产品或方案的价值来跟用户建立连接，让他知道这款产品或方案跟他的工作是息息相关的，它可以帮助他优化工作。接下来才是让用户了解这款产品或方案是什么，以及怎么使用。这其实跟软件研发的流程类似，从用户需求开始，先分析梳理用户的痛点，再到产品需求，设计一款产品来解决用户的痛点，最后才是开发实现。
- 文档目录设计与用户思维
当我们明确了文档的目标读者，也明确了可以为读者解决哪些问题，写作本身就有了指向和价值，这样我们就可以调动身心和大脑，让自己文思泉涌，这就是用户思维。在此基础上，我们就可以开始考虑文档应该包含哪些内容，目录章节该怎样安排设计才更符合用户的学习规律。文档就是我们对外输出的一个产品，做产品就要学会换位思考，站在用户的视角考虑他们需要什么样的产品或方案，用户在技术选型时也是先确认产品或方案对其是否有价值，等他认可了这个价值之后才会进一步了解产品或方案的功能特性和使用方法。
今年上半年我们团队研发了一套微服务开发运维平台，下半年我们要把它推广给集团各个专业公司的研发团队，这时候我们就在思考目标用户当中哪些角色可以决定是否采用这款产品？通常是应用架构师，但他首先要了解这款产品的整体定位和作用，相较于其他同类产品有什么优势，这个阶段他不太关心产品的实现和操作等细节。另外，掌控感，或者说安全感，每个人都希望拥有的，那我们要帮用户建立这种感觉。在帮用户解决具体问题之前，我们要先搞定用户的情绪问题，让他在阅读文档时体验更佳。
如何帮用户获得掌控感或安全感呢？全景视图，让用户拥有上帝视角，从整体上把握产品或方案的情况，这个视图不会包含太多细节。就像要穿越一片热带雨林到达某个地方，如果一头就扎进森林里，那我们很容易就迷路了，最好是先爬上某处高地或树冠，从那里观察整片森林的情况，包括河流走向和地标特征等，掌握了这些信息之后我们就会更有安全感，更有把握走出这片森林。全景视图就像一个装载信息的框架，我们要先帮用户建立这个框架，后续再给用户介绍详细信息，这时候用户就可以把它们收纳进这个框架的不同位置，这样他就不轻易迷路了。因此，文档第一部分是产品概述，包括背景说明、功能定位和优势比较等等。
在对这款产品有了整体了解之后，那应用架构师这个角色接下来就要搭建一套演示环境了，以便对产品有更加感性的认知。这个阶段他不需要特别全面或深入地了解各种细节，只需要知道如何以最简单、最快速的方式把它配置运行起来，他可以借助这套环境给团队内的开发测试人员介绍这款产品。因此，文档第二部分是快速入门，主要是协助应用架构师把对概念理论的理解变成一套真实可见的演示环境。
通过上述两部分内容，我们让用户知道这款产品可以帮他解决什么问题，以及它是怎样运行的。接下来用户当中的开发、测试工程师等角色才会介入进来，他们需要深入了解产品的功能特性和使用方法，以便指导具体的编码实现。因此，文档的第三部分才是介绍产品特性的开发指南。不同角色的用户对文档有不同的需求，文档的章节目录设计要依照上述顺序来满足各类用户的需求。第四部分，除了知道怎样使用这款产品之外，用户还会关心在日常使用过程中怎样运营维护它，有没有一些配套工具或管理控制台，借助它监控微服务的运行情况，以及对微服务进行管控治理等等。第五部分，使用过程中遇到问题怎么办，尤其某些出现频率非常高的问题，这部分就要对这些常见问题做梳理，遭遇问题时方便用户查阅。
1. 产品简介
2. 快速入门1. 快速搭建环境2. 快速开发应用
3. 开发指南1. 基础开发指南2. 进阶开发指南3. 扩展开发指南
4. 操作指南1. 服务治理指南2. 网关配置指南
5. 常见问题
6. 经典案例
7. 历史版本
8. 下载说明- 故事思维让文档不再枯燥
文档的章节目录设计要围绕用户需求：首先，我们要分析用户的类型，明确哪些类型的用户会先接触到这款产品；再者，说服了这批用户之后会带来哪些新类型的用户，这就是产品推广过程中接触用户的自然过程。在线文档的主要作用就是帮助我们获得新的用户，但我们必须要记住，推广产品是我们一厢情愿的想法，是站在我们的立场角度考虑问题，它是第二位的。写文档必须要先站在用户的立场角度，帮他们解决具体的问题，在解决问题的过程中顺便推销了产品，这才是用户思维的价值所在。
与用户思维同等重要的另一个思维模式叫做故事思维，这是人类大脑在漫长的进化过程中形成的生理特质所决定的，我们对故事类信息的接收会更加高效一些。如果你干巴巴地罗列产品功能特性，就像传统的产品使用说明书一样，那用户在阅读这份文档时是无感的，他会觉得枯燥无味、困难重重，无法将产品跟他遇到的问题联系起来。此时，我们就需要采用故事思维来组织包装这些素材，结合用户的使用场景讲故事。
故事思维的落地关键在于设计一个故事剧本，就像拍摄一部电影或者创作一本小说，你需要设计好每一幕的故事梗概，第一步干什么，第二步干什么，第三步干什么，...... 把每一步会出现哪些角色元素、这一步他们需要完成什么事情想清楚。那怎样设计这个故事剧本呢？窍门就是思考用户是怎样使用我们这款产品的，还是以微服务开发运维平台为例，我们在“快速入门 -> 快速搭建环境”章节就设计了这样一个剧本：
1. 介绍微服务应用的标准架构
2. 搭建微服务必备组件：注册中心
3. 构建一个扮演Provider的微服务
4. 构建一个扮演Consumer的微服务
5. 搭建微服务必备组件：API网关
6. 搭建微服务必备组件：配置中心
7. 搭建微服务必备组件：治理中心
8. 对照标准架构介绍演示环境这个剧本是根据用户真实使用过程设计的，通过收集整理这些典型场景提炼出故事剧本，通过剧本组织各种素材。在阅读这份文档时，用户就会自然而然地代入到他真实的工作场景中，因为在用户脑海里原本就存在一些上下文，故事就是帮用户把上下文调度出来，这会有助于更好地理解文档，对文档可以带给他的价值有更清晰的认知。通过自助阅读文档解决了真实的问题，做到不求人会让他更有成就感。
- 故事线模拟用户学习过程
等故事的基本框架确定之后，我们就可以依次填充故事的各个部分，第一步该搭建哪个部件，第二步又该搭建哪个部件等等，一步一步层级递进，后续步骤依赖于前序步骤，从而构成一个向导式循序渐进过程，引导用户由浅入深、由易到难，这符合自然的学习过程，这样更容易让用户接受。
编写技术文档时有一种常见问题就是章节之间没有关联，彼此之间没有转承衔接，各部分内容比较零散，就像把不同主题的文章做成了杂文集。用户在阅读此类文档时思维很跳跃，刚看完一个内容，再看另外一个，这两者没有必然的联系。这其实也是没有站在用户角度思考问题，用户跟我们不一样，他对产品或方案不像我们这样熟悉，缺少我们所掌握的隐性信息，章节内容上的跳跃加重了用户阅读文档的难度。最好就是找到一条线索将每个章节的内容衔接起来，就像章回体小说一样，看完这章想下章。借鉴Oracle JDK的示例工程宠物商店（Java Pet Store），我们也设计了一个简单但完整的用户信息管理服务来贯穿整个故事。
- 进阶式设计跨越学习曲线
在文档内容编排方面，我们不要一次性让用户学习太多新东西，向导里每个步骤的内容分布，必须要符合进阶式的学习模型，一下子给用户展示太多信息，只会把用户搞懵圈，让他产生畏难的情绪，对学习丧失兴趣。每个小节的内容不能填充的太多，尽量控制在十五分钟到半个小时以内，用户只要稍稍努力就可以完成挑战，这样用户就会感受到学习的乐趣，小步快跑，每一次小小的进步都可以激励自我，这样他就有信心自助式地完成整个系统的学习了。这样的学习方式是符合人性的，符合学习心理学的。
近段时间参与外部客户项目写标书，刚开始大家都无从下手，打不开思路，想着从网络上摘抄一些内容粘贴进去，但这样写作味同嚼蜡，写的不开心，读的也没感觉。后来就想到我们必须要揣摩读者，想象对面就坐着读者。标书的读者是跟我们一样在专业领域有着丰富经验的评委，我们没有必要向他讲解任何概念性的内容，在标书中我们只需要围绕客户的问题提供解决方案，简明扼要，点到为止，这样即是对评委的尊重，也是体现我们的专业性，我们不是出售文字，而是出售专业经验，就是有个流传甚广的故事里说的，一个专家被请去给工厂诊断故障原因，他在工厂里转了一圈只用粉笔花了一个叉，就挣了十万美金。
不同的读者要采用不同的沟通方式，除了要清楚读者的角色和能力等级，还要知道自己在这次对话中扮演的角色，俯视时要就低不就高，仰视时也要就低不就高，平视时做到点到为止，即读者的能力水平跟自己相似，那就要做到简明扼要、重点突出。从读者角度看，照顾对方的心理，让他感到舒服就对了。
- 不同视图服务不同的用户
那你可能会说，除了新用户还有许多老用户需要看在线文档，上述这种设计是否符合他们的使用习惯了呢？针对不同类型的用户，我们必须要提供不同的视图，或者说不同的入口，例如按照产品的功能特性建立一个索引视图，类似 Hao123 一样的导航页面，或者提供一个搜索框，深度用户对我们的产品已经非常熟悉了，他们可以通过这些入口快速找到他们想要的内容，从而更加高效地使用这份文档。同样的内容通过不同的组织方式呈现给不同的用户，这就是视图法带给我们的价值，横看成岭侧成峰，远近高低各不同。
- 常用开源或免费文档工具
文末再推荐几款我日常写作用的软件工具：
- 闪念胶囊：支持语音录制和识别，好处是可以非常便捷地记录自己的想法，尤其是当你灵光一闪的时候，键盘和纸笔都没有语言表述来的快，本文的主体内容都是借助它完成的。
- 印象笔记：支持手机和电脑之间同步，在手机上写到一半的文档可以在电脑上继续写，反之亦然，做到无缝衔接，不会因为切换工具就影响了写作的连续性。
- MWeb Lite：Mac上编辑 Markdown 文本工具，免费易用，手机上我就用网易有道笔记。
技术人习惯从自己角度看问题，产品人习惯从用户角度想问题，技术人也要掌握产品思维，用户思维和故事思维是非常有效的两套方法论，市面上有很多经典书籍介绍它们，感兴趣的朋友可以找来看一看。
今天先分享到这里，如果你觉得有价值，麻烦动动手指 转发 给其他需要的小伙伴。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提升、影响力打造等经验，欢迎 关注 本博客或歪信公主号 「 IT老兵哥 」！
如何写出好的产品帮助文档？相关推荐
- 如何写简单实用的产品需求文档PRD
文章目录 如何写简单实用的产品需求文档PRD 前言 产品需求文档模板 1. 概述 1.1 产品概述 1.2 典型使用场景 1.3 功能列表 1.4 目标用户 1.5 名词解释 1.6 参考文档 2. ...
- 如何写好一份产品需求文档
如何写好一份产品需求文档 PRD写得好看还不如需求把握得准确,PRD写得好看还不如体验设计得顺畅. 工欲善其事必先利其器. 产品需求文档(以下都简称PRD)对于大多数产品新人来说都并不陌生,它是产品工 ...
- 如何写好PRD（产品需求文档）+范例
概述: 产品需求文档(product requirements document,PRD)描绘出公司将要创造的产品.它影响着公司的产品团队的成果,公司的销售额.市场和客户满意程度.它要为公司提出更重要 ...
- 如何才能写出好的软件设计文档？
作为一名软件工程师,我花了很多时间在阅读和撰写设计文档上.在磨砺了数百篇文档之后,我发现,优秀的设计文档与项目的成功之间有着密切的联系. 这篇文章将介绍怎样才能写出一份优秀的设计文档. 为什么要写设计 ...
- 干货分享 | 如何写出清晰易懂的交互文档？
交互设计说明文档,简称DRD.用来说明产品设计思路.设计方案.信息架构.原型线框.交互说明等内容,文档中的内容包括: 交互文档中的主要内容 1.用户权限:根据不同用户的权限对该需求进行检查,比如普通 ...
- 如何写出令人惊叹的设计文档？
与优秀的人在一起,自己也会优秀起来,点击加入 来源:DeepNoMind 一份好的设计文档需要提供清晰的问题描述.整体的概要设计.涵盖各个细节的详细设计等. 这篇有趣的英文小短文通过一个简单的小例子介 ...
- 一篇文章 读懂产品需求文档PRD
转自:松勤软件学院公众号 互联网公司人员组织架构 按职责分类 有产品经理 前端开发 后端开发 软件测试 运营 UI设计 视觉设计师 运维工程师 销售 客服 等 谁来写需求文档呢? 答案是产品经理 谁来 ...
- Axure写PRD：倒推淘票票APP产品需求文档
Axure写PRD:倒推淘票票APP产品需求文档 本篇文章从业务流程及交互逻辑这两个方面入手,对一款生活类手机软件--淘票票进行了分析. 写在前面的话:笔者作为一个有意向进入产品岗位的菜鸟,希望通过倒 ...
- 顶级产品经理是如何写产品需求文档（PRD）的
产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现,作用是"对市场需求文档(MRD)中的内容进 ...
最新文章
- DVWA系列之1 环境搭建
- 精通SERV-U配置文件
- Three-way Partition
- 同步外部接口数据的一些记录和分享
- JDK 12，合并的收集器和命名的挑战
- 动态代理之： com.sun.proxy.$Proxy0 cannot be cast to 问题
- mysql虚拟列表_「前端进阶」高性能渲染十万条数据(虚拟列表)
- [Vue.js] 路由 -- 前端路由
- LINUX下的GNU调试工具,GNU调试器 GDB 8.3 发布及安装更新，支持RISC-V与IPv6连接等
- 【报告分享】我国数字基础设施建设现状及推荐措施研究报告.pdf（附下载链接）...
- java byte to integer_Java中的Byte转为无符号的Integer
- 金蝶k3 使用两台服务器的优势,金蝶k3报价系统优势如何，电商企业应用尤为明显...
- 机器学习必学十大算法
- 编程不是一种知识，而是一门手艺。
- Day05_Manuals for Python@lisongye-元组/字典
- Scratch编程（十）扩展模块：视频侦测模块
- 应用服务器和数据库服务器有什么区别？
- 谁说大象不能跳舞——《读书笔记》
- java 接口重写_java如何实现接口中的重写
- 浅谈XMLHttpRequest