写文档有一个很常见的错误，那就是很多人文档都是写给自己看的，这种情况下就会导致你的文档只有自己或者和你有相似知识背景的人才能看懂，团队较小时这种问题还好，你们都做着类似的工作，所以也都能看懂文档。但当团队逐渐壮大后，问题就会凸显出来，新人有时候有着和你不同的工作背景，甚至现在都做着不同的工作内容，这时候你之前写的文档他们就很难读懂了。
所以在写文档之前请明确你文档可能的读者会是哪些人，然后针对他们的特点着重关注如何才能让他们理解。当然，文档也不一定要非常严肃和完美，只要能向你潜在的读者说明问题即可。 记住文档是写给别人看的，不是给自己看的。
根据专业水平可以大致将读者分为三种 新手、老手和专家，针对不同水平的人写作需要有侧重点。比如针对新手，你需要重点介绍下里面涉及到的术语和概念，然后详细讲解具体的的实现。相反，针对专家 你可以省去这些额外的信息。注意，这里没有严格的标准，因为有些文章新手会看，专家也会看， 这里还是需要具体情况具体分析。
另外一种对读者分类的方式就是根据读者阅读文档的目的来分类，比如有人知道自己遇到了什么问题，就是来找解决方案的。还有一批人只有一个简单的想法，但不知道具体的问题。举个例子，以读数据库慢为例，前者已经知道数据库慢可能是因为数据量巨大且没有加索引，解决方案很简单 加索引，这时候他可能需要知道的是如何正确地加索引。而后者可能着重关注的是为什么读数据库会慢，这时候你可能需要额外重点介绍下数据库相关的原理。
清晰的分类文档大致可以分为以下几种类型，每种类型也有自己不同的特点和写作侧重点。
参考文档参考文档也是大部分开发人员日常会使用和书写的文档，比如我们使用某个框架或者工具，都会有API说明文档，这就属于参考类文档。 它并没有太多的要求，只要能向读者展示清楚如何使用即可，但无需向读者讲明具体的实现。
注：参考文档并不仅限于API文档，还包括文件注释、类注释、方法注释，要求都是能准确说明其用法。
设计文档很多公司或者团队在项目开始前都要求有设计文档，设计是项目实施的第一步，所以在设计文档书写的过程中要求尽可能考虑周全，例如该项目的存储、交互、隐私……
好的设计文档应该包含以下几个部分：
设计目标
实现的策略
各种利弊权衡和具体决策
替代方案
各种方案的优缺点
写设计文档的过程也你对整个项目做规划、思考可能出现问题的过程，设计的越详细、思考的越多，未来遇到问题的可能性就会越小。
引导类文档引导类文档也很常见，一般都是Step by Step的形式。比如我们在使用某个框架或者工具的时候，一般都会有个引导类的文档一步一步帮助你快速上手。 大家写引导类文章大家非常容易犯的一个错误就是预设了很多背景知识。 一般使用文档都是有开发者写的，他们都非常了解这个工具的相关的知识，所以习惯性的会认为，啊 这个知识点很简单 用户也肯定会吧，实际上用户不一定会。这本质上就是一种认知偏差，这种现象在跨团队协作 尤其是多端协作的时候也非常明显。
这类型的文档写作中，要求写作者尽可能站在用户的视角上思考，极力避免出现和用户的认知偏差，力争每个步骤做到明确无歧义，每两个步骤之间做到紧密衔接。
概念性文档当参考文档无法解释清楚某些东西的时候，就需要概念性文档了，比如某个API的具体实现原理。其主要是为了扩充参考文档，而不是替代参考文档。有时候这和参考文档会有些内容重复，但主要还是为了更深层次的说明某些问题、解释清楚某个概念。
概念性文档也是所有文档中写作最难的，也是被阅读最少的，所以很多情况下工程师最容易忽视。而且还有另外一个问题，没合适的地方放，参考文档可以写代码里，落地页可以写项目主页里，概念性文档似乎也只能在项目文档里找个不起眼的角落存放了。
这类文档的受众会比较广，专家和新手都会去看。另外，它需要强调概念清晰明了，因此可能会牺牲完整性(可以由参考文档补齐)，也有可能会牺牲准确性，这不是说一定要牺牲准确性，只是应当分清主次，不重要的就没必要说了。
Landing pages(落地页)