交互文档的受众

交互文档是一名交互设计师或者产品经理产出的最基础的协同文档，目标读者是和你一起作战前线的精锐部队：UI、开发、测试、运营、或者其他产品经理/交互设计师。

交互文档的地位

我经常听到有同行小伙伴们抱怨：说自己明明是产品经理，交互设计文档为什么要写的事无巨细？说自己是一名交互设计师，但每次开需求（交互）评审的时候，被开发怼得很惨，是不是他们故意找茬呢？

有些公司没有交互设计师，所以产品经理在很大程度上承担了交互设计师的部分职责。因此，交互文档可能就是产品需求的终极产物。

由此可见，交互文档的地位举足轻重。一份好的交互文档的输出，可以帮你解决很多那些你认为开发经常来“找茬”的问题。

好的交互文档标准是什么？

那什么是一份会说话并且高效协同的交互文档呢？

·好的交互文档可以让你捋清自己的设计思路，和开发相关人员对接时可避免无效沟通。
·好的设计文档可以让你一册在手，追根溯源。防止背锅，有理可依，有据可查。
·好的交互文档，易读易懂、非常实用，就像一本使用说明书，直观明了。我们进入正题：如何让交互文档开口说话？

交互文档的内容结构

P1

P2

我们先来说说除了（四）交互稿（第二部分详述）以外的，你需要完成的内容有如P1和P2所示，那我们就捡几点比较难理解的结构内容进行阐释：

（一）封面：版本号、参与设计人员、时间。

（二）版本维护：这个文档在整个设计和开发过程中非常重要，每一次无论是需求的变更还是设计稿修改，都要打一次版本号，并且用尽可能地方式通知到相关人员（邮件、微信、口头等）。可以专门建立一个Excel文档来进行维护和版本追踪。

内容信息：修改时间、原因、修改人员（需求还是单纯的界面）、变更内容等。试想，如果修改后，没有通知到位，开发人员很有可能会拿着未迭代过的版本开发，后果可想而知，这也就是为什么总是存在“PM和开发干架的”原因之一。

（三）设计过程：包括需求记录、需求分析、用研和竞品情况、资料灵感的记录、产品信息结构（当然根据自己的项目需要，选择不同的信息）

1）需求记录：

可以包括最初的需求记录，评审后的会议记录，需求变更记录（也可以保留相关邮件，聊天记录截图等）。同样，时间、变更内容、人员、原因等都要写清楚。

2）有关用户体验分析：

可以用用户体验地图（如P3所示）——它展示的是用户在使用一款产品和服务的过程中，每个阶段的体验，包括行为、感受（痛点和满意点）、思考想法。

价值：

1、让产品设计者有更全面的视野，从体验地图中挖掘需求核心和痛点。
 2、从用户痛点中，发掘是否有创新的项目 或者 是否具有产品战略上的机会点。当然啦，可以进行需求分析的方法还有很多，在这里就不一一赘述了，我也将会推出关于需求分析方法的文章。

3）产品功能结构图

以脑图形式展示产品信息、功能、以及基本的交互信息。（是我在公司做的某产品功能结构图，因涉及商业机密，部分信息已做像素模糊处理，请见谅！）

接下来，我们揭开（四）交互稿的神秘面纱……

交互稿的目录是怎么生成的？

答：交互稿的目录结构就是产品功能结构图推导出来（如图所示），所以你要首先完善自己的产品功能结构图。

一篇交互稿需要包含哪些元素呢？

如图所示：

·页面标题：建议固定浏览器顶部。
·界面标题：方便交互稿互相索引。
·作者信息：方便他人联系设计师。
·跳转链接：可以通过点击界面上的某个功能，实现跳转。

交互说明的规范和原则

如图所示：

交互说明位置：要不统一在下方，要不统一在界面左边或者右边。

对应关系明确：界面中描述的点最好用1、2、3或者a、b、c角标来一一对应交互说明的内容。

巧用栅格系统：可以让布局变得井然有序，清晰明了：栅格布局-栅格与辅助线-网格设计，同时设置间距为40px。

界面说明：页面逻辑说明，动态动效说明，动态数据的来源和去向交代清楚、功能操作的说明等。

如果交互说明过长，可利用动态面板：