交互文档是交互阶段的最终输出产物，好的交互文档不仅仅是线框图的呈现，而是包含了设计思路、设计流程、组件等的综合文档。不要小看交互文档，如果交互文档写不好，交互设计师很难讲清楚设计的思路，从而无法说服产品经理和业务方，同时因为缺乏细节和系统的专业表达，也会提高与研发的沟通成本，甚至会引起后期问题，大大降低项目推进的速度，造成延期。那么，一个成功的交互文档应该从哪些方面进行表达呢？
01 需求背景
在呈现交互方案前，需要讲明白前置背景，才能一步步推导方案，方案也更有说服力。
a. 项目背景
首先，要明确问题是什么。相关的用户反馈是什么，产品出现了什么问题，或者这块相关的数据出现了什么问题，或者在核心业务目标上出现了什么问题，这些都是问题的定义。其次，明确要解决什么问题。这里可以是对应上面的问题，也就是业务目标或体验目标。
b. 设计目标
我们已经在第一步明确了业务的目标，但用户想要的是什么？明确用户体验目标，可以通过用户画像等研究方法，大的项目可能需要更多维度的分析才能明确用户目标。用户调研方法是交互设计知识体系中很重要的一部分，由于内容过多，在此不做展开，请关注小编后续文章。根据业务目标和用户目标，推导出设计的目标，设计目标就是这个设计方案的指导方向。
c. 核心数据
上面提到了业务目标、用户目标，那么跟这几个目标相关的哪些数据能在项目上线后证明目标是不是达到了，它们就是核心数据，在这里都要明确出来。
d. 项目风险
我们优化了某些功能很有可能会给其他模块带来一些负面的影响，这里要明确出有可能的风险，然后评估一下风险的大小，若风险可以忽略，那项目就可以执行下去，若风险的负面影响大过了整个项目的收益，那就要另做考虑了。
02 交互流程
项目背景介绍清楚后，就可以介绍方案了。首先介绍交互流程，这样比较容易简单明了的将功能的整体流程和重点介绍出来，并将大家带入到整个方案里来，不至于后面不知道在说什么。
03 核心页面交互说明
a. 层级结构
这部分描述核心页面的布局、结构、层级，比如是顶部导航结构还是底部导航结构，比如层级顺序是什么。该部分若没有大的变化也可以不展示。
b. 功能逻辑
这部分介绍需求变化的功能逻辑，比如点击后的流程是否有变化、展开形式是否有变化。
c. 组件说明
这部分介绍具体的组件交互方式，比如播放组件的几种状态，弹窗的交互方式，表格的交互形态等。移动端的组件一般会有一些公认的规范，设计师结合自己产品的特点和统一性对规范进行优化润色，从而形成自己产品的组件规范。组件的规范也是一个知识体系，后续小编会做相关分享，请持续关注。
04 交互Story
这部分将整个需求的交互流程串联起来，遍历整个流程，将所有的正向流程、特殊状态都呈现出来。如果需求仅仅是页面上的改动、没有流程变化，这部分也可以不呈现。
总结以上从各个层次对交互方案进行了介绍，这几部分基本能涵盖交互阶段需要考虑的东西了，这样出来的交互方案基本可以将需求、目标和方案都讲清楚，当然这只是常规需求的文档输出方式，如果是设计师自驱发起的项目，思路和文档会更复杂一些，小编后续会继续做这方面的分享，敬请各位持续关注。
