一份设计文档的结构大概可以分成Background项目背景、Schedule排期、History版本历史记录、Information Architecture信息架构分析（包括Site Map、Experience Map、Flow等）、Framework框架设计、Wireframe线框图和Mockup视觉稿等。取决于实际项目的情况，部分内容可以省略，也可以加入更多，比如Storyboard故事板，Prototype可交互原型等。
在过去，我一度没有什么规范的设计文档写作习惯，用纸笔画完Information Architecture和Wireframe后，就匆匆进入了Mockup阶段，最后的交付物也仅仅是Mockup。前期的时候觉得没什么，后来就感觉到了问题，这样很容易过早地陷入对视觉细节的纠缠，设计到一半忘了最初的设计目标，有时花了很多精力纠结一个模块交互or视觉设计的好坏，后来却发现整个模块都没有存在意义，已经背离了最初的业务目标与设计目标，根本不是用户想要的东西；或者场景考虑不全面，设计完一个模块后放到整体里充满矛盾，结果需要花更多精力来进行补救，导致进度Delay或只能上线充满问题的版本等。
而良好的设计文档写作习惯，虽然会在一开始占据比较多的时间和精力，但却能保证全程设计思路一直比较清晰，做设计的时候时刻思考用户是谁、目标是什么、这样设计是否能帮助达到目标，向团队、向合作伙伴沟通传达自己的设计方案时，也有更强的说服力。
Background
这一部分的内容在设计师和PM、业务方充分沟通需求之后完成，我的习惯一般是分成这几个模块：产品描述，要设计的产品是什么，依托怎样的平台，在什么场景下发生；业务/产品现状，总结需求方现在面临的主要问题，有哪些体验不好的地方，关键痛点是什么；用户目标，用户群有哪些类型，他们分别想解决什么问题；访问流程，产品有哪些入口，最终把用户导向哪些地方。这些都需要和需求方确认清楚，明白整个产品的来龙去脉，最终提炼出设计目标：需要设计什么新的功能，需要优化哪些已有的设计，提高产品哪些使用环节的体验，引导用户做出什么操作，最终达到怎样的业务目标。
Schedule
和需求方确认各阶段交付物的时间节点，制定完成设计的具体计划，每个阶段大概做哪些工作，什么时候内部Review，什么时候和项目组Review等。确保设计以一个合理的节奏展开，可以以较高的质量按时交付。
History
设计稿版本每发生一次比较大的迭代更新，都要记录在版本历史记录里，相比一个个去翻以前的设计稿，版本历史记录可以清晰地展现设计稿的迭代历程，有哪些需求的变动，有哪些设计时没思考清楚需要修改的地方，Review时大家给出了哪些意见和建议等。有时版本需要回滚，可以更方便地追溯，而项目结束后浏览这一部分，可以看到自己的设计在哪些方面一开始思考不足出现了各种问题，是如何被发现、改进和提升的，下一次设计的时候是否可以更早地思考到和回避掉。
Information Architecture
根据具体项目性质的不同，这一块的分析工具也有较大的差异，具体的选择和使用要按照实际场景来，而非机械进行套用。
如果是设计一整套网站系统，Site Map必不可少，通过它将需要设计的内容以全景图的方式呈现出来，对整个网站的架构可以构建起一个初步的印象，像架构层级过深、页面内容重复等问题都可以通过Site map发现，进而提出是否可以减少页面的信息层级、合并部分页面等，从整体上优化产品的使用体验，而非只见树木不见森林。
Experience Map可以把产品在不同使用场景、流程下的体验问题直观地呈现出来，我们有时会得到一些用研结果反馈，但大量反馈建议直接列举的话会很散乱，也不知道哪些是真正的问题，哪些只是个别用户的吐槽，通过Experience Map可以整理出用户使用产品大概有哪些场景和环节，各场景和环节下都遇到过什么样的问题，哪些问题出现的频率较高等，帮设计师更好地代入到用户使用产品的实际体验过程中去，进而思考各场景、环节下都可以进行怎样的设计目标拆解与设计优化、最终帮助完成产品的整体目标。
Flow流程图也是一个常用工具，可以总结出不同场景下用户使用产品的流程和步骤是怎样的，可能产生怎样的分支需要在设计中考虑到，在哪些地方可能产生较大的流失，步骤是否可以合并优化，能否抽象出通用的流程来构建框架设计等。
Framework
Framework和Wireframe的区别主要在于前者更抽象、通用化，不需要太多的内容细节，而后者更详细、分场景、已经有了删格化和详细的文案等，离Mockup甚至只差配色、图标、阴影细节等。