从概念上看，作者分享了写交互文档的全过程指南，体验分享带你逛了逛产品设计的坑。
最近停了一段时间工作，一直在想交互文档。其实在几个月前，我整理了一部分，我把自己关了起来，规范整个平台。好吧，那是一派胡言。让我们言归正传。
在制作交互式文档之前，我们应该先了解什么是交互式文档，为什么要制作，为谁制作。
# #什么是交互式文档？
交互文档，即交互设计描述文档。英国设计要求文件，简称DRD.主要用于承载设计思想、设计方案、信息架构、原型线框、交互描述等。
# #为什么我需要交互式文档？
有些人可能会对文档感到厌恶，尤其是很久没有工作的朋友。事实上，你工作的时间越长，你会发现文档越重要。它可以帮助你理清思路，记录下来便于复习。就工作而言，有一个标准化的文档可以让你的设计更有说服力，也很容易一起工作，提高他们之间的沟通效率。
# #互动文档是给谁的？
实际上，交互文档是针对谁的，实际上，具体情况具体分析。有些公司老板还得盯着互动文档，还有甲方的爸爸和运营部的同事，这些都是可以看的。
然而，无论如何，有四种人必须是交互式文档的忠实“读者”:
1.产品经理：产品经理和交互设计师可能是交流最多的人。产品经理主要确认文档中的设计思路和业务流程，然后经过页面交互模块。
2.视觉设计：UI设计师通常最关注的是页面交互模块。有产品思维和体验思维的设计师也会仔细看设计思路和产品背景，让他们更好地理解产品的商业逻辑和用户心理。
3.开发人员：前端开发的同事，和UI设计师一样，最关注页面交互模块，其他人也会提升，帮助他们理解。后端开发人员更注重业务逻辑、信息架构、操作流程等。只有当这些都清楚的时候，他们才能输出一个准确和合格的开发文档。
4.测试人员：:因为测试人员是一群在线检查产品的人，所以在提出有效的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\. 废纸篓
废纸篓，被称为是交互文档的“后悔药”。在需求不断变动的情况下，改改改的过程中，请把你改过的稿子，放这里！！！因为很可能最后还是用的第一个方案（此刻内心有点绝望）……
## 总结
文档、软件只是工具，最重要的还是要落地、实行起来才能对产品有所帮助。所以在撰写文档的每时每刻，都应该站在“读者”的角度思考，他们看的时候感受会是怎样的，会觉得很难理解吗？
除此之外，还需要有耐心，耐心给他们讲解理解不透彻的地方。
用一个朋友的话总结下： 好的设计都是被虐出来的 （其实干哪一行不是呢..……♀重要的是：心态心态～）。
本文旨在提供参考，并非绝对的规范，还望抛砖引玉，多多交流。
本文由 @宛苏 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
