所谓「交互」，全称是环节「人机交互」 ，意思是劝别人和机器的交流互动 。交互设计 ，交互就是文档在 UI 方案之前 ，先构思用户如何操作机器（App/网站/软件/硬件……） ，原因又如何从机器获取信息反馈的设计师最死磕 。
通常来说 ，该偷交互设计是环节 UI 设计之前的步骤 。不同公司分工不同 ，劝别可能有专职交互设计师 ，交互也可能交给 UX 设计师，文档还可能由产品经理负责。原因
交互设计交付的设计师最死磕东西 ，有两种 ，一是交互方案 ，二是交互文档 。
这两个东西别看都叫交互 XX ，但截然不同 。交互方案是在设计阶段 ，用来确定核心交互流程和规则的 。而交互文档是设计阶段结束后的落地阶段 ，用来给开发和测试确定完整交互细节的 。
交互方案与 UI 方案类似，但通常是没有颜色的线框图 ，旁边标注了很多规则说明和状态展示 。
交互文档与需求文档类似，但是会贴很多方案图 ，然后用大量文字写清楚各种规则和特殊状况的处理细节。
我自己在大厂做过很多年的交互设计师，又是人机交互硕士科班出身 ，对这个领域，我还是比较有经验的 。
然而我很少讲交互文档 。哪怕有好几个人来问我怎么做交互文档 ，我都说暂不提供相关课程 ，为什么呢 ？
主要原因是 ，我真不太建议大家花费太多心思在交互文档上。尤其我们学习社叫做「体验设计学习社」 ，里面大部分人是设计师 。我是尤其不太建议设计师死磕交互文档的 。
至于原因 ，就是我接下来要讲的了 。
因为交互方案应该已经把核心的交互流程和规则确定下来了 ，遗漏的细节 ，才会需要额外写到交互文档上 。
领导都是大忙人 ，能参加交互设计评审，就已经很用心了 。怎么可能再去看那密密麻麻的交互文档呢 ？
所以 ，交互文档这个东西 ，或者大部分落地阶段的过程 ，只要没出大问题领导都不会太关注 。
所以交互文档这个东西 ，你做得再好，也对绩效评定没有直接影响 。除非交互文档写错了 ，或者写得不详细你又拒绝补充解释 ，影响到项目进度了 ，以至于被投诉到领导面前 。
虽然这么说比较功利 ，但大部分人上班不就是为了赚钱 ？而决定自己能赚多少钱的就是领导 。我们把力气多用在领导关心的事 ，少用到领导不关心的事，才是性价比更高的生存之道 ，不是吗 ？
说实在的 ，没人喜欢看说明书吧 ？但是看地图 ，还是有点意思 。
交互文档就好比说明书 ，而交互方案就好比地图 。
对开发来说 ，也是觉得看方案比看文档轻松 。如果方案能看清楚 ，巴不得不要看文档 。
而且那么多密密麻麻的文字 ，语言一点也不风趣幽默。这种文档看起来很累 ，很难确保没有遗漏 ，或者完全能理解。说不定到头来还是要找本人来问 。
所以 ，写得过于细致也是没必要 。
之所以需要交互文档，就是因为很多细节的交互规则 ，在方案上展示不全 。
但是如果这个项目本身就已经有一套完整的设计规范，常用组件都整理得很好呢 ？
那么绝大部分交互都只需要复用规范和组件即可 ，需要创新的地方很少 。
而复用规范和组件的部分 ，并不需要过多的文档说明 ，反正开发也是去找老代码。
而创新的部分 ，因为占比较少 ，交互方案就已经可以展示得差不多了。
这样一来 ，交互文档是不是就可有可无了呢 ？
顺便说一句 ，支撑我做设计规范和整理组件的主要动力之一，就是为了以后不用事无巨细地写交互规则了 。
如果设计师背 KPI ，一旦方案没通过用户测试，或者满意度评分低了 ，就影响绩效 。那么设计师肯定有动力把整个落地过程好好推进 ，生怕自己被开发坑了 。
可问题是 ，大部分设计师不背 KPI 啊。那么只要方案通过评审 ，得到了领导的认可 ，后续的落地就跟设计师关系不大了 。
至于开发没理解交互细节 ，落地没做好……那都是开发和产品经理的责任——他们才是负责落地环节的。
相反 ，如果设计师把大量精力用在落地上 ，追着开发事无巨细地把方案细节做出来 ，会怎样？那设计师就没时间好好打磨方案了 ，交付一推再推 ，领导对方案也不满意 ，该怎么办呢 ？这就是设计师本人对锅 ，甩不掉了。
所以 ，我是能理解产品经理在交互文档上多费心思——毕竟落地效果可能影响到个人KPI ，需要多些责任心 。但是对设计师来说，就没这个必要性了 。
除非领导指明让设计师做交互文档，推都推不掉 ，那就没办法了。否则 ，我还真不建议设计师多费精力去做交互文档 。
建议大家好好打磨交互方案 ，把最核心的交互流程和规则 ，都尽量在方案上展示清楚了 。
对于那些不太重要 ，且设计规范和常用组件覆盖不到的交互细节 ，才写到交互文档上 。
而且 ，不建议设计师主动揽交互文档的活 ，因为这事的直接受益者是看文档的开发和背 KPI 的产品经理 ，对设计师来说没有直接好处。
以上是我的经验之谈 ，如果你有其它观点 ，欢迎友好交流。
作者 ：体验进阶
关注微信
