挖坑指南 - 设计与开发的沟通

做交互的这一两年,挖过许多坑,有时还会掉同一个坑里好几次,是没有看到问题的核心还是没找到解决之道呢?现在将这些挖坑经历写出来,说是「挖坑指南」,其实是为了把坑填上,以后不再犯同样的错误。

先说说最近在做的一个后台系统,这个产品是公司内部使用,本以为蛮简单的一个东西,结果也挖出了好几个坑,最后的结果就是开发出来的产品跟设计稿的差距很大,事后总结问题还是出在设计与开发的沟通上。

By the way,如果问为什么开发要按照设计稿去做?肯定是因为你的产品思路清晰,你的设计逻辑合理,你的业务场景让大家了解并认可,以这些为前提,你才能让工程师按照你的设计稿去设计和开发;这是一个大前提,这里就不细讲了,主要还是说说沟通和协作的过程。

下面开始复盘,直接说一下遇到的问题和目前能想到的解决思路。

交互与开发的问题

1、部分功能逻辑因为在「当面沟通的时候已经达成一致」,所以没有在交互上很清楚的写出来,最后开发没有按照「已达成一致」的逻辑去实现;

解决方向:

  • 在面对面沟通结束后,发一封确认邮件给所有参与人,内容是本次沟通所达成一致的内容有异议的内容汇总;
  • 在交互文档上,把已经达成一致的逻辑清晰的写出来(PRD上也要保持一致);


2、部分功能在交互上已经写得很清楚,但最后的产品并没有按此交互去开发,对此开发说「没有在当面沟通的时候说出来」;

解决方向:

  • 与开发沟通时,多次核实已经达成一致的地方,并告知已在交互文档上详尽的标注;
  • 在技术评审(开发评审交互)的时候,尽量把所有的交互细节都说一遍,特别是容易出错或理解有误的地方;
  • 在沟通已全部达成一致,且交互细节全部标注之后,要让开发有时间好好看看交互文档,有任何问题直接当面沟通,一定要保持交互跟开发的同步(即使因技术原因改动逻辑或交互,也要及时修改文档)


3、部分在其他页面已经存在的交互,没有做标注说明,最后产品出现了跟其他页面逻辑不一致的地方;

解决方向:在交互文档上,所有细节都要详尽清楚的标注,特别注意已经存在的功能,逻辑未更改的地方可以不标注,但最好在文档中注明,例如:未标注的交互保持原有逻辑不变等(如果之前的开发换人了,更要注明)