设计师最该偷懒的环节找到了！劝你别死磕交互文档的4个原因

所谓「交互」，全称是「人机交互」，意思是人和机器的交流互动。交互设计，就是在 UI 方案之前，先构思用户如何操作机器（App/网站/软件/硬件……），又如何从机器获取信息反馈的。

通常来说，交互设计是 UI 设计之前的步骤。不同公司分工不同，可能有专职交互设计师，也可能交给 UX 设计师，还可能由产品经理负责。

交互设计交付的东西，有两种，一是交互方案，二是交互文档。

这两个东西别看都叫交互 XX，但截然不同。交互方案是在设计阶段，用来确定核心交互流程和规则的。而交互文档是设计阶段结束后的落地阶段，用来给开发和测试确定完整交互细节的。

交互方案与 UI 方案类似，但通常是没有颜色的线框图，旁边标注了很多规则说明和状态展示。

交互文档与需求文档类似，但是会贴很多方案图，然后用大量文字写清楚各种规则和特殊状况的处理细节。

相关教程：B端的交互文档如何写？这篇保姆级教程收藏起来！

我自己在大厂做过很多年的交互设计师，又是人机交互硕士科班出身，对这个领域，我还是比较有经验的。

然而我很少讲交互文档。哪怕有好几个人来问我怎么做交互文档，我都说暂不提供相关课程，为什么呢？

主要原因是，我真不太建议大家花费太多心思在交互文档上。尤其我们学习社叫做「体验设计学习社」，里面大部分人是设计师。我是尤其不太建议设计师死磕交互文档的。

至于原因，就是我接下来要讲的了。

一、领导不会关注交互文档

因为交互方案应该已经把核心的交互流程和规则确定下来了，遗漏的细节，才会需要额外写到交互文档上。

领导都是大忙人，能参加交互设计评审，就已经很用心了。怎么可能再去看那密密麻麻的交互文档呢？

所以，交互文档这个东西，或者大部分落地阶段的过程，只要没出大问题领导都不会太关注。

所以交互文档这个东西，你做得再好，也对绩效评定没有直接影响。除非交互文档写错了，或者写得不详细你又拒绝补充解释，影响到项目进度了，以至于被投诉到领导面前。

虽然这么说比较功利，但大部分人上班不就是为了赚钱？而决定自己能赚多少钱的就是领导。我们把力气多用在领导关心的事，少用到领导不关心的事，才是性价比更高的生存之道，不是吗？

二、开发也未必有耐心仔细看文档

说实在的，没人喜欢看说明书吧？但是看地图，还是有点意思。

交互文档就好比说明书，而交互方案就好比地图。

对开发来说，也是觉得看方案比看文档轻松。如果方案能看清楚，巴不得不要看文档。

而且那么多密密麻麻的文字，语言一点也不风趣幽默。这种文档看起来很累，很难确保没有遗漏，或者完全能理解。说不定到头来还是要找本人来问。

所以，写得过于细致也是没必要。

三、把设计规范和组件化做好，交互文档就不那么重要了

之所以需要交互文档，就是因为很多细节的交互规则，在方案上展示不全。

但是如果这个项目本身就已经有一套完整的设计规范，常用组件都整理得很好呢？

那么绝大部分交互都只需要复用规范和组件即可，需要创新的地方很少。

而复用规范和组件的部分，并不需要过多的文档说明，反正开发也是去找老代码。

而创新的部分，因为占比较少，交互方案就已经可以展示得差不多了。

这样一来，交互文档是不是就可有可无了呢？

顺便说一句，支撑我做设计规范和整理组件的主要动力之一，就是为了以后不用事无巨细地写交互规则了。

四、对设计师来说，不背 KPI 就不用对落地负责

如果设计师背 KPI，一旦方案没通过用户测试，或者满意度评分低了，就影响绩效。那么设计师肯定有动力把整个落地过程好好推进，生怕自己被开发坑了。

可问题是，大部分设计师不背 KPI 啊。那么只要方案通过评审，得到了领导的认可，后续的落地就跟设计师关系不大了。

至于开发没理解交互细节，落地没做好……那都是开发和产品经理的责任——他们才是负责落地环节的。

相反，如果设计师把大量精力用在落地上，追着开发事无巨细地把方案细节做出来，会怎样？那设计师就没时间好好打磨方案了，交付一推再推，领导对方案也不满意，该怎么办呢？这就是设计师本人对锅，甩不掉了。

所以，我是能理解产品经理在交互文档上多费心思——毕竟落地效果可能影响到个人KPI，需要多些责任心。但是对设计师来说，就没这个必要性了。

除非领导指明让设计师做交互文档，推都推不掉，那就没办法了。否则，我还真不建议设计师多费精力去做交互文档。

总结一下

建议大家好好打磨交互方案，把最核心的交互流程和规则，都尽量在方案上展示清楚了。

对于那些不太重要，且设计规范和常用组件覆盖不到的交互细节，才写到交互文档上。

而且，不建议设计师主动揽交互文档的活，因为这事的直接受益者是看文档的开发和背 KPI 的产品经理，对设计师来说没有直接好处。