交互设计虽然是个新新职位，现在越来越多地渗透到了大大小小的互联网公司。就算没有专门交互岗位的公司，界面设计师也会承担交互设计的工作。作为交互设计师的重要产出之一，交互设计文档（DRD）并没有特别定型的规范。以往的工作经验中，各家公司的DRD文档书写都不一样。纵然条条大路通罗马，但总有快的有慢的，编写交互设计文档时掌握关键要素，就能够帮你提高效率，节省沟通时间，然后早点下班。所以这篇文章我总结下过往DRD的经验，为建设不加班的设计时代贡献绵薄之力。

为什么要重视交互设计文档？

团队协作工具。交互设计师需要跟产品、程序、UI、测试多个人打交道。如果你只拿着几张线框图，靠口头交流你的设计思路，可以预见你的工作绝大多数时间是在和别人唇枪舌战，有损咽喉。交互设计文档就是你的武器，你精心打造，它就增强你的战斗力。一份好的文档帮你阐明设计意图，节省沟通成本，而且越是大型的团队，文档的重要性就越高。

责任划分留档。交互设计与产品和视觉存在工作交叉，当产生疑问时，到底是该找谁，以谁的为基准，文档里写的清楚。而发生了错误追责时，交互设计文档也是很好的事前备案。

工作交接。设计师的流动很常见，换项目、换人、离职，当有其他人来接手你的工作或者要合作时，如果你适时祭出一份清晰的交互文档，新人就会少踩很多坑，赠人玫瑰手有余香不是，我们也会省去很多的沟通时间。

DRD的读者一般是产品、程序、UI、测试，如果多个交互共同合作，其他交互也要看得明白。在写DRD时以传达设计意图为首要任务，所以应当遵循以下原则：

简单直白。DRD不是写小说，不需要起承转折，不需要华美辞藻，用最直白的语句，最简单的语法把过程说清楚，多多使用“点击该按钮，则怎么怎么样”、“如果传输错误，则怎么怎么样”这样的形式。可以用专门的页面来讲述你的设计背景和理念，但大多数情况下DRD是规则指导，别人最需要知道的要做什么、怎么做，不需要了解各种原理性的东西。

思虑周全。交互设计师不一定有产品的洞见深刻，但交互思维广度在团队中应该是最全面的。产品往往分地而居，设计却需要纵观全局。任何一个设计点，要想到正常操作以外可能发生的各种情况，比如错误处理，空状态，不同用户下的呈现状态，可能存在的冲突等等。在书写交互文档时必须完整清晰地列举出来，不然程序GG会隔三差五地来问你这些细节问题。

先定稿再写。先作出设计稿，跟产品开发确定可行后，再写交互文档，切忌反客为主。修改是很喜闻乐见的事，特别是程序一句“做不了”，你就得重新更新一遍设计。为了确保交互设计师效率最大化，能够早点下班，需要先定稿后再细化细节。

正文书写要领

图图图！设计师用图说话，能用图来完美表达的不要用文字来说明。比起“勋章加上反馈文字的提示”，一张图更简单明了。即使是局部的小修小改，也应该贴张局部截图来展示。

在要解释的地方贴上序号。用醒目的标号样式引导读者，不要将所有的字堆在一起没有逻辑先后。正确做法是在操作点按照顺序贴上标号，然后在旁边一条一条附解释，不仅提高了阅读性，修改批注起来也更加方便。

善用附件。文字不能表达清楚的动效，应额外附效果图；特别复杂的流程，应做出可交互原型。站在阅读者的角度，使用别人最易懂的方式来呈现，也是交互设计的卖稿技巧。

除了主体部分要写清楚外，一篇完备的DRD还应具有“预见性”。你是否有碰到过这样的情景：你去着手一个已有系统A的功能迭代，但是它里面有很多暗藏的坑，你想知道当时的具体设计过程，但由于时间久远，没有文档留存，你不得不找程序进行遍历回查。又有次你和很多交互设计师一起设计同一个功能，但是交互文档写在一起没有区分，程序来问你问题的时候，你说“这不是我做的呀！”时间就浪费在这些重复工作中。所谓预见性，就是为以后可能发生的状况做好提前埋下伏笔，目的还是节省设计师的时间，减少沟通浪费。

需要额外记录的内容有：

1、版本记录。在文档的开篇需要有一页来专门做版本记录，包括修改时间、负责的设计师和产品、修改内容等，方便责任划分与回查。

2、流程图。如果是大型需求，需要配置一张逻辑流程图给程序和测试看，帮助他们概要性理解设计流程。注意是流程图，不是思维导图。

3、修改内容标志。交互文档的修改是家常便饭，在开发过程中、评审后、上线后都有可能发生迭代，重新输出一份文档既浪费时间，别人也不知道哪些地方改了。对于大的修改，应该另起一页写，并标明修改说明和时间。而对于很小的点的修改，在对应位置用醒目的颜色标识清楚。

4、数据埋点。如果设计点需要记录用户数据，尤其是体验方面的数据，在DRD里面当清晰写明。推荐写两遍，一遍在设计说明中对应要埋点的位置，用醒目的颜色标识；另外再另起一页，将本文档中所有埋点整理在一个列表中，以防程序遗漏。

文件格式

不同的公司有不同的风格，但其实文件格式是很重要的。文件格式各有优劣，采用哪种格式除了个人喜好之外，也要看公司现有的流程是怎样的。主流的格式有Word、PPT、Excel、网页、图片这几种，易获取易传播，其他人不需要额外安装软件就能查看。这里就将这几种格式的优劣对比。

作为最常见的文档格式，用的人很多。但我真的不推荐用word写设计文档，主要因为它对图片排版的支持很差。交互说明会有大量的图，而且在图的周围要做批注说明，word的图片调整起来非常麻烦。并且word不支持多标签，不支持模块化编辑。

个人最推荐的格式，集各种优点于一身，图片可以自由移动不要太爽，多标签方便管理与版本控制，无限高度适用于各种文字图片大小。写了这么多文档，还是觉得Excel最好用了。

目前用PPT写交互文档的很少，个人认为是个很有前景的文档格式。PPT可以很方便地阅读、修改，而且它可以内嵌各种多媒体文件，能直观地表现基础动效，甚至可以用PPT做可交互动效。新增的节功能可对块内容进行折叠，提高了文档阅读性。不足之处是对长页面无法支持，写字时需要多插入一次文本框。

很多人用axure软件做交互设计线框后直接在上面批注说明，生成的网页文档自带页面结构，比较直观，网页的阅读体验也较好。在网页中可以实现很多基础动效，也可以体现页面跳转关系，逻辑性很强。但是有两个问题，一是每次修改都需要重新生成网页文件，无法直接修改批注，二是单个文档输出文件很多，不利于管理。

PDF的易传播和矢量支持特性，可以很好地作为以线框图为主的交互说明。不仅支持长页面，也支持播放模式。大部分用illustrator写交互规范的导出格式都是PDF。然而PDF的可编辑性并不强。

图片与pdf类似，只不过后者一个文档可以集成很多页图片。图片格式说明一般是直接在设计图旁做批注，例如使用sketch时，在旁边进行批注，然后导出为图片，对设计师来说比较顺手。图片作为只读格式的文件，其他人无法修改，因此迭代时也不太方便。

你没看错，我曾经用CHM格式写过交互文档。当时想到用Windows上的帮助文档格式，是想找到既有网页优点、体量又轻易于保存的格式。CHM的表现力和网页无差，所以问题也相同。而且编纂起来非常麻烦，所以适用于一些不会修改的规范性说明。

其他问题

产品已经画了很详尽的线框图，交互要做什么？

有的产品控制欲较强，在需求文档中会事先画好线框图，然后让交互在这上面细化高保真。初级的交互设计师按部就班，依样画葫芦把产品的图做成原型。我们现在经常探讨交互的价值是什么，遇到这种情况，是展现交互自身价值的机会哟。首先你要跳出产品给你定好的框架，结合业务需求，首先确定产品的需求是否有问题，是否有改进的地方。在确定需求后，帮助产品理顺流程逻辑，找出问题点。而只有这些都厘清后，才是进行具体的细节设计工作。此外，交互设计师也担负一定的视觉概念设计，你可以在文档中给出概念方案，给UI参考。

在公司的不同阶段怎么优化交互文档？

如果是规模较大的设计团队，已经形成固有的文档模式，那么应该采用渐进型的改进，逐步渗透步步为营，通过实际的工作发现文档中改进的地方，进而改善整个流程。大团队你想一下子改变舵向是很难的，也得给别人一个适应期。如果是初创团队，可以直接推广你认为最合适的文档方式，尽早提高效率。