别整标题党！ 这是一份阿里的设计师分享的编写交互设计师的启迪思路的文章

鸿影：一份设计文档的 结构大概可以分成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甚至只差配色、图标、阴影细节等。

Framework开始构建起产品的形，抽象出通用的布局原则，页面上大概有哪些模块，这些模块之间的主次、优先级关系是怎样的，每个模块要帮助用 户完成怎样的目标。思考清楚了这些问题，接下来的设计才会减少目标偏离与方案返工出现的概率，能把握住界面的整体结构、模块关系呈现等，而不是陷入细节， 结果让次要的东西喧宾夺主。

Wireframe

Wireframe在Framework的基础上具化出了产品的完整骨架，在这一步需要仔细考虑到每一个可能的使用场景，包括极多极少、错误等特殊情况都要包括在内。

我一般习惯在Axure文档里以建立很多页面，每个页面按照场景进行命名，再在页面里画Wireframe，具体到每一个模块可能出现的一些特殊场 景等，则直接在页面里以模块的方式在主界面旁边呈现，如果是比较简单的情况，也可用文字直接说明。总之，每一个角落都要考虑得当，不能有遗漏，因为水平经 验还比较稚嫩，一开始遗漏了较多内容，也非常感谢合作伙伴和团队前辈们的及时指出。

Wireframe虽然不是Mockup，但在视觉效果呈现上却马虎不得。一开始我觉得不是视觉稿没必要考虑那么多，在画Wireframe时完全 没考虑栅格之类，最终的视觉效果感觉也比较粗糙。后来被指出在Wireframe这一环，文案等内容基本就确定了，如果不考虑视觉效果，可能在实际的视觉 稿产出后，会发生因为文字内容过多溢出，导致整个页面结构都要被迫调整之类的情况，最终增加了产品的设计成本。作为交互设计师，我们可能不用考虑太多配 色、创建角色形象之类的视觉细节，但一定要懂基础的UI设计规范，甚至在视觉要求不高（如很多B端产品）的时候，需要直接扮演视觉设计师的角色，这也是我 们区别于“能画线框图的产品经理”的重要价值。

还有文案，通俗来说就是“说人话”，各种导航标签、各种引导提示问题、各种按钮说明等的文案也是交互设计师需要思考的，目前我在这方面做得还比较弱，文案有啰嗦、用户不容易理解等问题，正在努力看书写作试图弥补中，就不多谈了。

Mockup

Mockup作为表现层的主要产出，在Wireframe的基础上完成配色表现、图标绘制等视觉细节的呈现，为产品的骨架覆盖上最终的皮肤。在 Wireframe已经充分考虑到各种场景的情况下，Mockup不需要再面面俱到，而是选择关键场景的界面进行绘制表现即可，注意一些 Hover/Active之类的状态表现，再就是标注（在公司内部神器的帮助下似乎已经不用这一步了，怒赞，Sketch棒棒哒，前端都是专业的甚至还懂 点设计，不需要太多沟通就能高保真还原效果，感觉比以前幸福好多！）交付前端了。（想到自己以前画大量精力画不同场景的Mockup，很多只有一点细节的 差异，而Wireframe就是一点纸笔草图，感觉蠢爆了= =）

最后放一张自己的设计文档结构截图吧，虽然Axure很多人黑，但我觉得在文档结构呈现这块真的是最好用的。

来源：优设  原作者：鸿影