国外互联网是如何编写设计文档的，其中重要的是量化和风险尽早发现和解决。
update 2020/5/8 Google最近给出了一个技术写作课程《Technical Writing》。
原文链接：How to write a good software design doc
为什么要写设计文档
A design doc is the most useful tool for making sure the right work gets done.
写设计文档可以帮助自己理清任务和确定方案（减少和避免后期返工的风险和成本），也是开发人员之间互相交流和协调工作的媒介。
设计文档中应该包含什么
标题和人
其中人包括了作者（可能多个，同时这些人也是参与到该项目中的人员）、评审人员，同时也要包含文档最新更新时间。
概览
言简意赅地介绍这个设计文档中的内容。
上下文
说明一下需要解决的问题，项目的必要性，了解项目所需的背景知识，是否满足公司的技术策略、产品策略或者季度目标。
目标和非目标
对于目标部分，需要描述该项目对用户（包括其它项目组、其它部门，甚至其它系统）的影响，以及如何使用相关指标来衡量项目的成功与否。
对于非目标部分，需要描述那些你不打算解决的问题。
里程碑
给出一系列可度量的检查点。如果项目周期超过一个月的话，可以设置一些面向用户的里程碑来讲项目进行切分。这样无论对于PM还是利益干系人都能够及时地知道进度。
已有方案
给出当前实现的流程、交互或者数据流，同时最好给出相关的用户故事。
建议方案
同样给出相关的用户故事，并且给出总体设计，细节部分可以后续补充。
其它可选方案
可以给出一些其它可选方案，以及它们的优势和劣势。
可测试性、监控和预警
这部分往往被忽略，或者事后补充。
部门间影响
需要考虑该项目对‘上下游的影响，如何应对。
遗留问题
可以列出一些不确定的问题，后续工作，设计上待改进的地方等等。
详细地项目范围和时间表
这部分个人觉得应该放到其它部分，设计文档中可不写。
如何编写设计文档
简单化
- 用词简单
- 避免长篇大论
- 多采用列表
- 给出具体示例
多加一些图表
最好是可编辑的图表，方便更新。
用数据说话
给出一些真实数据，可以更好地帮助别人了解问题和方案。
试着有趣一点
设计文档不是学术论文，不需要很严肃。但也要避免过犹不及。
做一些测试
写完后，不要急着评审，自己从评审角度去审阅自己的设计，然后不断地解决设计中的问题和疑问。
设计过程
只要实现还在进行，那么设计文档也应该保持同步更新。
关于设计
- 设计文档可以给你一些反馈，避免自己浪费大量时间实现错误的方案或者解决错误的问题。
- 项目中的每个人都是设计过程中的一部分。
- 设计过程不是理论空想，你应该不断去验证想法，可以试图搞一些试验代码来进行验证
开始设计之前你应该
这些事情可以让你尽早地得到反馈，发现问题和节省时间。
- 向有经验的工程师或者技术经理请教或者邀请他们对你的想法进行点评
- 向他描述你要解决的问题
- 解释你是如何实现的，并试图说服他