DRD撰写指南如何写出科学易懂的交互设计文档

DRD撰写指南（如何写出科学易懂的交互设计文档）

从概念讲起，笔者分享了撰写交互文档的全流程指南，经验分享带你绕过产品设计的那些坑。

最近停更了一段时间了，一直在琢磨着交互文档这个事。其实早几个月前就整理了一部分，把自己给整自闭了就整平台规范去了。好了，说了一堆废话言归正传。

在做交互文档之前，我们先要明白什么是交互文档、为什么要做以及做了给谁看。

什么是交互文档

交互文档，即交互设计说明文档。英文 Design Requirement Document ，简称DRD。主要是用来承载设计思路、设计方案、信息架构、原型线框、交互说明等内容。

为什么需要交互文档

有些人可能对文档这种东西比较反感，尤其是从事工作不久的朋友。其实工作得越久，越会发现文档的重要性，它可以帮助你理清思路，并记录下来，便于回顾。工作上而言，有一份规范的文档可以让你的设计更有说服力，也易于工作对接，提高彼此之间的沟通效率。

交互文档给谁看的

交互文档其实要说给谁看，其实具体情况具体分析。有的公司老板也要盯交互文档，以及甲方爸爸、运营部门同事，都有查看的可能。

不过有4类人，无论如何他们都必须是交互文档的忠实“读者“：

1. 产品经理：产品经理与交互设计师可能是沟通最多的人，产品经理主要在文档中确认设计思路和业务流程，然后过一下页面交互模块。
2. 视觉设计：UI设计师通常最关注的是页面交互模块，有着产品思维和体验思维的设计师也会仔细看一下设计思路和产品背景，以便于自己更了解产品业务逻辑和用户心理。
3. 开发人员：前端的开发同事和UI设计师一样，最关注页面交互模块，其他的作为提升会辅助了解。而后端开发人员关注更多的是业务逻辑、信息架构、操作流程等，这些都清晰了，他们才能输出一份准确合格的开发文档。
4. 测试人员：因为测试人员是把关产品上线的一群人，所以各个模块、步骤都应该去了解透彻，才能提出有效的bug。

如何撰写交互文档

本文主要阐述以Axure软件为撰写工具，大家可以根据实际需求决定用什么软件（Sketch、PPT、Word、PS、AI 等）。

比如小需求可以用Sketch，快而高效。如果是要给甲方爸爸/大老板看的，使用PPT会让他们更好理解。

通常，一个比较基础、规范的交互文档（DRD）由：文档封面、更新日志、文档图例、设计背景/思路、业务流程、页面交互、全局通用说明、废纸篓八部分组成。当然，这不是绝对，你可以根据你的实际工作需要进行增减。

比如，如果是C端产品的话，用户调研的结论、用户画像、用户体验地图等等，都可以放进去给看的人一个参考。尤其是在如今这么关注用户体验、产品思维的一个大环境下，这些数据支撑很有力量。同时还可以帮助开发人员、界面设计人员培养产品思维、体验思维，大家一起将产品变得更好。

其次，交互文档的整洁与美观也很有必要。相信在过去几年不少人有遇到过这样的产品经理（兼交互），他们会输出一些有时连他们自己都看不太懂或者直接从其它竞品截图来的线框图。当开发和界面设计的人提出质疑的时候还美其名曰线框不重要，重要的是里面的业务逻辑。其实用产品思维想，交互文档就是交互设计师的产品，而看的人就是用户，保持良好的可读性，可谓至关重要。

1. 文档封面

交互文档的封面如上图，通常包括产品的名称、Logo、版本号以及版本发布时间、所属部门、对接负责人/对接人。

2. 更新日志

我们都知道，在产品的迭代的过程中，需求/功能是会不断调整的。而更新日志，就是为了迭代而生。它一般由修改日期、修改内容、修改人、版本号和备注组成。

如果是新增的功能或模块，建议是要加上链接可直接跳转至新增内容的，如上图。

版本号也是同理，都应加上对应的版本链接，便于查看者回溯之前的内容，与当前的新版本形成对比。

这一点对开发人员来说很重要，其次对于新同事深入理解产品也能起到很大的帮助。

修改日期，通常是按时间倒序排列，查看起来会比较方便。

3. 文档图例

文档图例，顾名思义就是关于此文档的一些辅助说明，目的是为了让读者更好地理解文档。如上图的：操作/跳转图例、标签图例、流程图例以及手势操作图例。

4. 设计背景/思路

设计背景，根据实际工作需要，放置一些关于思路整理、灵感来源的文档。比如用研报告、用户画像、竞品分析报告、商业画布等增强文档的说服力，尽量让每一个人都能理解到产品的战略目标和业务逻辑。

图为我今年对接最久的是一个B端产品的项目，所以整理了一个产品画像，仅供参考。

5. 业务流程

业务流程图，不是操作流程图也不是页面流程图。它是产品的整体业务流程，直接和业务挂钩，可以说是产品的核心流程。