美文网首页设计师的自我修炼今日看点PMskill
挖坑指南(一)- 设计与开发的沟通

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

作者: 梓非徐 | 来源:发表于2015-12-22 13:17 被阅读291次
    挖坑指南_博客.png

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

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

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

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

    交互与开发的问题

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

    解决方向:

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

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

    解决方向:

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

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

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


    交互与视觉的问题

    1、 最终的视觉稿上,存在与交互文档不一致的逻辑

    解决方向:

    • 存在逻辑不一致的地方,一定程度上说明视觉没有完全理解产品的交互逻辑:可能是自己的交互文档不够清晰存在歧义,也可能是视觉设计的时候发现了交互点遗漏的地方,没有告诉交互直接按照自己的逻辑去设计了…这些都需要交互跟视觉多沟通,然后再有交互去完善优化文档;
    • 为避免大意而出现的问题,视觉设计完成后应该多自我审查,没问题后再拿给交互,交互也要 Review 几遍,力保消灭粗心大意的错误;

    2、 视觉稿不完整,缺少了 Modal 对话框的页面

    解决方向:

    • 这次的视觉稿没有 Modal 对话框的样式,是因为交互认为这是前端框架里默认的组件样式(公司其他后台网站是有的),所以叫视觉设计师不用出这个样式......但没想到最后开发出来用的却是浏览器自己的控件(又丑又难用.T_T),解决的方法是:全部细节都出视觉稿,不抱一丝假设!不过要跟开发多沟通,如果已有组件样式的,找前端索要样式后放在视觉稿里即可(可以不用标注)。

    视觉与开发的问题

    1、 为了标注方便,设计师利用插件直接对源文件导出了 spec 页面,上面可以自己查看所有的样式属性和细节(需要自己去点击),但最后开发出来的产品在细节上几乎都没有达到视觉稿的效果;

    解决方向:

    • 一张白纸上画一个黑点,对方很容易明白你画了一个黑点;但如果你把这张白纸全涂成了黑色,对方可能会认为这本来就是一张黑色的纸,而你什么都没有画(一个例子)......我们以前的标注是把页面所有细节属性都标出来给到对方(Markman),现在 Sketch 有了插件 Measure,可以一键导出,开发需要看哪里的属性点击即可查看;但这样会不会造成例子中的情况呢?这是我们针对标注这件事情应该去思考的,现在能想到的就是要跟开发多多沟通,他们需要什么样的标注我们都可以输出,关键的问题还是我们的一致目标一定得是:按照设计稿100%进行还原!

    2、 设计师没有跟前端验收页面,导致成品与视觉稿相差甚远;

    解决方向:

    • 如果因为没有安排「视觉验收」环节,我们就不去验收、不去要求开发修改,那么只能说明我们的主动性不够强烈;设计师要有主动性,如果视觉没有主动去验收,那么交互应该更主动的拉上视觉去找开发一起验收和调整细节;

    其他问题

    因为是内部自己人使用的产品,所以大家都没有太注重视觉,以致于项目经理在立项的时候没有安排「视觉设计」和「视觉验收」的环节,间接导致了后续开发与设计师间的诸多问题...

    解决方向:这个产品的视觉重要与否,具体可从业务和使用场景来给出定义,但是作为设计师自己,是要力争拥有「自己经手的每一个产品都要做到很棒」这样的觉悟才行!所以没有排期要去争取排期,没有验收要去主动验收,不管有没有PM都应该主动承担起 owner 的角色。

    相关文章

      网友评论

      本文标题:挖坑指南(一)- 设计与开发的沟通

      本文链接:https://www.haomeiwen.com/subject/zpamhttx.html