如何输出一份合格的交互设计文档？思维导图

交互文档可以理解成是将需求文档图视化的一个过程，所做的产品原型有没有满足用户需求，达到公司的商业目的，交互设计师要和产品反复沟通，确保达成用户和公司的目标。

UI设计是将灰不溜秋的线框图转化为美美的视觉稿的人，他必须知道有多少个页面要设计，这些页面之间的跳转逻辑是怎样的，遇到特殊情况（数据加载、异常流程、网络异常等等）如何设计，这就是交互设计文档对UI设计师的意义。

不管是iOS、Android、H5等前端开发人员，还是后端开发人员，需要从交互文档里知道，产品要实现多少功能？如何去实现？涉及到多少页面？这些页面又是通过什么去跳转的？碰到异常流程怎么处理？…将这些问题理清后变成代码语言，从而将产品实现出来。

我们知道，产品必须经过系统测试才能上线，而进行系统测试之前，测试人员要进行测试用例的梳理，测试用例必须得覆盖所有的功能甚至是action，才能做到上线无bug，或者是少bug状态。测试人员整理测试用例表的时候就会参考交互设计文档。

知道了谁会看DRD以及DRD的意义。现在来说说DRD都包含哪些东西。

DRD的目录

这是我整理DRD的一个目录，包含九大部分：文档封面；设计背景；信息架构；整体业务流程；任务流程图；页面流；功能列表；交互规范说明；线框图。

把交互设计文档看成一本书，文档封面就是这本书的封面，封面就得包括书名，作者，出版时间等关于书的基本信息。同样的，DRD的文档封面包括：项目名称；版本号；时间；交互人员；内容。1.0版本的内容多为创建一个新的APP或者ERP，迭代版本的内容则是重构某个功能的页面，增加/删除某个功能等等。

文档封面

交代清楚产品定位；具体的设计内容；设计的目标是什么，让观众通过设计背景模块了解这次交互设计的一些基本情况。

产品分为几个模块，每个模块下包含多少信息和标签，一般会用思维导图的形式画出信息架构图。推荐一个Mac OS下的思维导图软件IThoughtsX，一款简约易用的导图软件。

整个业务模式涉及到多少主体？每个主体要负责哪些模块？这些业务的流程是怎么样的？业务流程图中的主体不光可以是买方、卖方等人，还可以是各个机构或者是APP、ERP等产品形式（由于公司的业务流程涉及保密信息，所以从网上找了个购物的业务流程。一般业务流程会用泳道图的形式来表示）：

梳理完产品的信息架构和业务模式，接下来就要将产品分解为多个任务，一般一个产品只有一个主干任务，其他则是支干任务（微信的主干任务是即时聊天，朋友圈、摇一摇、购物、设置等都属于支干任务）。

每个任务用一个流程图表示，太过简单的任务可以不需要画流程图（像设置里的任务，一般只涉及到两三步操作）。

一个任务流程图，继续具体化，就要输出该任务下的页面流了，不同任务之间的页面会存在重叠，这样就可以将所有任务流程汇总，形成整个产品的页面流。页面流不需要将每个页面的内容都详细的画出，只要画出每个页面涉及到的行动点（按钮）。

跟我司测试人员沟通之后，发现在交互上列出整个产品涉及到的功能点很有意义，测试可以通过这个去梳理测试用例，开发也能根据功能列表去比对发现哪些功能实现了，哪些功能没有实现。

对于一些特殊的交互状态，包括产品会共用的控件我都会放在这个目录下。

经过了上面重重分析，终于可以放开手画线框图了。线框图一般包括三个部分：每个页面的内容和排布；各个页面之间的跳转逻辑；一些交互说明。