交互设计文档如何写，才给程序员以美得享受？-IAMUE

阿西UED授权发布

作者公众号艾欧交互设计ID：aioued

文章最后报名线上线下活动：

【HBAT创新设计峰会：design+下的生存之道】

“写交互设计文档(DRD)目的在于：

便于与前端、测试以及开发工程师沟通”

交互设计文档重要么？重要！但不是项目必需具备的内容，为什么还要学习呢？其实对于初学者来说，交互设计文档能够很好的梳理产品的逻辑关系、基本的设计规范等问题，让你真正透彻的认识一个产品所有可能性。基本上，在大公司都会写交互设计文档的，便于团队协作沟通，有问题好追溯。对于DRD来说，还是根据团队需求来看待，整理DRD还是要耗费一点时间的，如果团队沟通默契，直接输出视觉稿就能开发，这是最高效的形式，如果需要，还是得好好书写DRD的哈。

什么是交互设计文档?

我们先来统一一下概念以及名词，以免后续因为说法不够一统造成误解：
交互设计文档一般是指：交互设计说明文档（交互设计师产出的规范文档），又称DRD（Design Requirements Document），工作中一般称之为”交互设计文档”

为什么要写交互设计文档?

如果问不写交互设计文档可以不可以？

答案是：可以不写，那么写与不写的区别究竟在哪里？

我们从两个方面分析一下：

1.可以不写交互设计文档的情况

下列情况是目前存在很多公司内的情况，即使没有专职交互设计师也不出文档他们也在做产品，这些情况有可能不需要写交互设计文档。

产品没有交互设计环节
团队没有交互设计师角色
交互设计没有系统化规范化
开发边界不需要控制
产品没有动效或交互细节
有经验丰富的产品经理
产品没有复杂的人机交互逻辑
产品只有一个产品经理或负责任角色主要负责

2.要写交互设计文档的情况

下列条件具备后写交互设计文档更具意义：
产品有清晰的交互设计流程
产品团队中有专职的交互设计师
团队已有系统化的和规范化的作业流程
开发实现交互设计时需要定义边界（验收标准）
产品有比较复杂的、丰富的动效
产品有较为复杂的人机交互逻辑
产品有多个产品经理或部门协作

写交互设计文档的作用就很清楚了，如果要写这样一份文档最大的好处是，可以非常清楚的帮助程序员认知做出的产品是什么样子的。

看个小例子：

V1.0 没有交互说明文档的版本（可能是产品经理PRD代替）

产品需求的描述是这样的

需求说明：实现封面图片上，点击图片之后翻转一圈

（文字描述交互与需求）

开发根据这句话脑补怎么翻转？360°？从左边还是从右边？转速怎么样？这些开发都需要找PM问清楚，如果专业的PM还可以，能给开发讲清楚。但是遇到经验不足的PM就会说开发你看着做一个就行…。

V2.0 没有交互说明但是有UI设计的版本

UI设计出图是这样的

对于需求和期望达到的效果，静态可视化的说明要比纯文字更容易理解，需要给开发人员一个具象化的目标，否则程序做起来很容易路线跑偏，想要的A而开发给的却是B。

V3.0 交互原型加演示DEMO

动态demo!

输出HTML文件预览

小结：编写交互文档是为了将更丰富的人机交互动作、事件准确传达给开发人员，确保实现边界。

若只是语言或静态图片交付给开发、测试人员，那么他们很难构建一个产品形态，不好把控开发方向，另一方面交互文档也是给参与项目的其他人快速了解项目的背景，不用跑东跑西到处询问设计细节。

其实写作交互设计文档最大的好处在企业管理层面上，产品的交互设计文档作为产品资料入档，后续人员变动后，新来的人可以快速掌握整个产品的核心设计。减少人员无谓的沟通，不过有一点，这个文档要及时更新，有变动要发出更新日志，不然还是少不了同事之间的语言沟通。

交互设计文档由谁来写？

谁来写这文档本来不是问题，显然谁是交互设计师谁提供这个说明文档，但是，因为一些别的原因导致这是一个问题了。

比如：有些公司没有交互设计师这个职位，所以不论岗位划分如何，如果你的团队中有人负责交互设计这个角色的工作，那么这个文档就是属于这个角色对应的人员来提供。

也有可能交互设计的工作被划分给了UI设计师，所以越来越多的UI设计师改了自己的Title为：UI/UE 设计师。

交互设计文档要给谁看？

根据项目组角色来定需要提供给：PM、开发人员、测试人员、需求人员、业务方人员等。

交互设计文档更新机制

有任何一处变动需要更新到说明文档中，通过团队的沟通渠道发送通知，我们公司是SVN服务器，设计师更新了设计文件版本或说明书版本后会同步到SVN服务器后生成最新地址与日志记录后发送邮件抄送相关项目团队人员。

更新记录如下图：

交互设计文档要写什么内容？

我不想说一大堆高深的理论，那么下面的内容我会按照实际流程帮助大家梳理出怎么制作文档。

很多同学在新建一份空白文档后不知道具体写什么内容，如前面所说，对于一份交互设计说明书，你只需要把原型截图或原型直接画成一个文档。

其实交互文档就是页面文档，所有的软件页面、状态都分离出页面进行展现，然后加入页面流程和交互动作说明文字、箭头指示线条等。

关键点：逻辑结构、页面跳转、交互状态的文字说明，统一交互体验动作，确保页面组件的一致性。

小例子：交互设计说明文档截图

这是一个包含交互界面动作、逻辑步骤、页面流转、文案与注释的例，图中的交互动作说明是将所有出现的静态化界面的内容写在文档里进行展示。如果你想直接展示动态交互，可以使用原型设计工具设计好交互原型之后再截图编辑文档，交付文档时配合着原型（导出HTML）演示，这样会更有效率。

交互设计说明书的文档结构：

版本信息一般包括版本信息、日期信息、参与人信息、变更内容简要、备注信息。

目录

这个无需多说，平时我们看的书基本都有目录，不过记住目录要合理分级以分清主次。
Log更新记录页
这个页面是用来描述某次更新的信息简介与页码导航等。下图为交互设计说明文档的更新记录页的示例：交互设计说明书的更新日志

交互设计说明书的更新日志
交互行为逻辑图+文字说明

下图某一个应用商店的更新应用交互逻辑+文字说明图例

交互设计说明书中的交互逻辑页面流程

上图中可以看出，这个说明文档是把应用更新功能拿出来当一页，包括它的架构、交互、流程、逻辑、交互事件及文字解释说明。这个过程是针对产品经理和程序人员来的，因为他们需要看明白交互流程逻辑。
页面展开图+逻辑+文字

下图是页面、元件、文案、逻辑、页面状态的展示：

交互设计说明书的页面元素

这个部分是针对视觉来的，需要将所有的页面都展开解释一遍，共用部分可以单独标记。
其他单独的交互动作详细解释介绍

此部分是对不在流程里的单独的或独立的交互的补充书写。