从概念讲起，笔者分享了撰写交互文档的全流程手册，经验分享带你绕开产品设计的这些坑。
最近停更了一段时间了，一直在寻思着交互文档这个事。其实早几个月前就整理了一部分，把自己给整自闭了就整平台规范去了。好了，说了一堆屁话言归正传。
在做交互文档之前，我们先要明白哪些是交互文档、为什么要做以及做了给谁看。
什么是交互文档
交互文档，即交互设计说明文档。英文 Design Requirement Document ，简称DRD。主要是拿来承载设计思路、设计方案、信息构架、原型线框、交互说明等内容。
为什么须要交互文档
有些人可能对文档这些东西比较厌恶，尤其是从事工作不久的同事。其实工作得越久，越会发觉文档的重要性，它可以帮助你理清思路，并记录出来，便于回顾。工作上而言，有一份规范的文档可以让你的设计更有说服力，也便于工作对接，提高彼此之间的沟通效率。
交互文档给谁看的
交互文档虽然要说给谁看，其实具体情况具体剖析。有的公司老总也要盯交互文档，以及乙方父亲、运营部门同学，都有查看的可能。
不过有4类人，无论如何她们都必须是交互文档的忠实“读者“：
产品总监：产品总监与交互设计师可能是沟通最多的人，产品总监主要在文档中确认设计思路和业务流程，然后过一下页面交互模块。视觉设计：UI设计师一般最关注的是页面交互模块，有着产品思维和体验思维的设计师也会仔细看一下设计思路和产品背景，以便于自己更了解产品业务逻辑和用户心理。开发人员：前端的开发朋友和UI设计师一样，最关注页面交互模块，其他的作为提高会辅助了解。而前端开发人员关注更多的是业务逻辑、信息构架、操作流程等，这些都清晰了，他们能够输出一份确切合格的开发文档。测试人员：因为测试人员是把关产品上线的一群人，所以各个模块、步骤都应当去了解透彻，才能提出有效的bug。如何撰写交互文档
本文主要探讨以Axure软件为撰写工具，大家可以按照实际需求决定用哪些软件（Sketch、PPT、Word、PS、AI 等）。
比如小需求可以用Sketch，快而高效。如果是要给乙方妈妈/大老板看的，使用PPT会让她们更好理解。
通常，一个比较基础、规范的交互文档（DRD）由：文档封面、更新日志、文档图例、设计背景/思路、业务流程、页面交互、全局通用说明、废茅房八部份组成。当然，这不是绝对，你可以按照你的实际工作须要进行增减。
比如，如果是C端产品的话，用户督查的推论、用户画像、用户体验地图等等，都可以放进去给看的人一个参考。尤其是在现在如此关注用户体验、产品思维的一个大环境下，这些数据支撑很有力量。同时还可以帮助开发人员、界面设计人员培养产品思维、体验思维，大家一起将产品显得更好。
其次，交互文档的整洁与美观也很有必要。相信在过去几年不少人有碰到过这样的产品总监（兼交互），他们会输出一些有时连她们自己都看不太懂或则直接从其它竞品截图来的线框图。当开发和界面设计的人提出指责的时侯还美其名曰线框不重要，重要的是上面的业务逻辑。其实用产品思维想，交互文档就是交互设计师的产品，而看的人就是用户，保持良好的可读性，可谓至关重要。
1. 文档封面
交互文档的封面如上图，通常包括产品的名称、Logo、版本号以及版本发布时间、所属部门、对接负责人/对接人。
2. 更新日志
我们都晓得，在产品的迭代的过程中，需求/功能是会不断调整的。而更新日志，就是为了迭代而生。它通常由更改日期、修改内容、修改人、版本号和备注组成。
如果是新增的功能或模块，建议是要加上链接可直接跳转至新增内容的，如上图。
版本号也是同理，都应加上对应的版本链接，便于查看者回溯之前的内容，与当前的新版本产生对比。
这一点对开发人员来说很重要，其次对于新朋友深入理解产品也能起到很大的帮助。
修改日期，通常是按时间逆序排列，查看上去会比较便捷。
3. 文档图例
文档图例，顾名思义就是关于此文档的一些辅助说明，目的是为了让读者更好地理解文档。如上图的：操作/跳转图例、标签图例、流程图例以及手势操作图例。
4. 设计背景/思路
设计背景，根据实际工作须要，放置一些关于思路整理、灵感来源的文档。比如用研报告、用户画像、竞品剖析报告、商业画布等提高文档的说服力，尽量让每一个人都能理解到产品的战略目标和业务逻辑。
图为我去年对接最久的是一个B端产品的项目，所以整理了一个产品画像，仅供参考。
5. 业务流程
业务流程图，不是操作流程图也不是页面流程图。它是产品的整体业务流程，直接和业务挂钩，可以说是产品的核心流程。
例如天猫APP，买家购物由始至终的流程就是它的业务流程。通常用泳道图的方式展示，多数情况下是由产品总监勾画。
以上是我所负责产品的核心业务的流程图。因为是B端产品，涉及角色较多，针对3个代表性角色分别进行了勾画，仅供参考(涉及到保密合同，所有关键词都除去了)。
6. 页面交互
1)信息构架
信息构架属于用户体验的结构层，是产品的骨架，一般是由产品总监或则更高层的管理人员给出大框架。除非是大的产品迭代，否则不会大改。
2)权限说明
如果是C端产品，权限这一块相对简单，比较好整理的。B端产品涉及角色诸多，可能要单独拎下来剖析整理。 以上仅供参考，大家具体情况具体剖析。若是功能很单一的产品，交互文档中也可省去这个模块。
3)操作流程图
产品操作流程图就是通过图形化的抒发方式，阐述产品在功能层面的逻辑和信息。它还能更清晰、直观地展示用户在使用某个功能时，会形成的一系列操作和反馈的图标。
注：不要将所有流程汇总在一个表里，或者展示在同一个页面中，而应追随具体的操作或则功能模块放置。时刻想着看文档的人的体会，怎么易懂如何来。
上图是登陆、注册和寻回密码的操作流程图，仅供参考。
4)页面线框图
页面线框图，是通过图形化的抒发方式，阐述产品在页面层面的信息。包括：
以上是注册的的页面线框图，仅供参考。
以上是登陆的线框图和详尽的交互说明。将重点内容用白色标记，可以让查看者一目了然更好理解文档。
7. 全局通用说明
全局通用说明，指整个产品可通用或则复用的元素。一般是边做文档边整理下来的，方便自己或则接手该项目的设计师直接调用。其次，对开发及时封装可复用控件也是有参考价值的。
1)常用控件
常用控件类似UIKit，通常将极具复用价值的控制整理在一起，方便及时调用。
2)复用界面
顾名思义就是全局可复用的一些内页，比如选择联系人、独立搜索页等。
3)时间规范
在做产品的第一步，就应当约定一个时间规范。不然各个端开发下来，你会发觉iOS是斜杠的，Android是横杠的，WEB是圆点的……真到了发觉的时侯再改，那真是彼此都是无比崩溃的。
4)缺省页汇总
缺省页通常包括加载失败、加载中、网络中断和无数据的空页面。为空页可以根据模块整理在一起，方便UI设计师最后一起设计缺省页，保持风格统一。
8. 废茅房
废纸篓，被称为是交互文档的“后悔药”。在需求不断变动的情况下，改改改的过程中，请把你改过的稿子，放这儿！！！因为很可能最后还是用的第一个方案（此刻内心有点绝望）……
总结
文档、软件只是工具，最重要的还是要落地、实行上去能够对产品有所帮助。所以在撰写文档的每时每刻，都应当站在“读者”的角度思索，他们看的时侯体会会是如何的，会认为很难理解吗？
除此之外，还须要有耐心，耐心给她们讲解理解不透彻的地方。
用一个同学的话总结下：好的设计都是被虐下来的（其实干哪一行不是呢..……♀重要的是：心态态度～）。
本文致力提供参考，并非绝对的规范，还望抛砖引玉，多多交流。
