2017的年终总结第二篇，想粗谈在产品设计的过程中，如何更高效地与开发人员合作。

作为两个职能完全不同的工种，设计师与工程师从许多的角度上都有相反的出发点。设计师希望能完整并准确地展现自己的创意，无论形式多么多样、繁复，工程师则希望系统化地、逻辑地、高效地完成产品的编码。

要实现优秀的用户体验或是天马行空的设计，有时会需打破既有的代码结构；而如要系统化地设计筹划产品的每一个细节，设计师就势必舍弃一些有趣的点子。因而设计师与工程师的职能如何平衡，是一场颇有艺术的博弈，取谁舍谁，则是彼此不断沟通、结合外部建议，最终达成共识的过程。

在经历了一场场的博弈后，我总结了以下经验：

1. 产出清晰、完整、系统化的设计文档

首先，作为一个设计师，交付物的水准一定要高。

虽然设计初期，脑爆的过程往往出其不意，天女散花，但当设计完成，到交付时，依然要遵循严格的样式标准。

交互设计文档要有统一的页面设置，模块样式，和标注语格式。这样让开发人员在接到一个新设计时，仅从阅读文档，就能很快了解相应的信息，而不需花费时间在适应不同格式的交付文档上。如果你通常使用的都是橘黄色的箭头，不要突然将某一处的改成了绿色，工程师可能以为你有什么特殊的含义。

视觉设计文档需有系统化的标注系统，如对于颜色和字体，建立统一reference system，可以让设计文档更清晰，减少重复的标注。

尽量使用统一、一致的标注格式，避免让工程师琢磨一些不必要的细节。

2. 构建统一、规范的组件库

除了标注的样式，我们还需严格规范产品内的组件，并构建统一的组件库。

小如一个按钮，大如一个下拉菜单，任何一个组件都该有统一的样式。当在一份交互文档中出现了三到四种不同的可点击按钮的样式，有的呈黑色，有的呈深灰色，有的呈白色，开发人员该如何做处理？如果这三个样式都代表着主按钮，它们就应该以完全一样的样式展现给开发人员。

视觉组件亦如此，才不会造成歧义和混淆。有时，在初期设计时，你可能会增加许多不必要的组件，如在不同的填表页面中使用不同的输入框。但反观整个产品，在绝大多数情况下你会发现，使用统一的输入框样式，更能体现产品视觉调性的一致性。

无论如何，任何对于组件的删改，都应及时跟开发人员同步，以确保产品最终的质量。

3. 多沟通，少返工

在设计的每一个节点，都不忘与开发人员同步进度、并尝试在潜在的问题上取得共识。

当你产生了两个想法，不知选哪一个时，如果它们的用户体验类似，就不妨直接让开发人员介入。通过让开发评估方案的可行性，你可以快速知晓哪一个是更值得继续的。

还有一种复杂的情形更为常见：当你有两个体验略有区别的方案，其一体验更优，却要使用更多开发资源，其二体验虽然略次，开发时间却只有一半时。唯有及时与开发人员同步你的进度，你才会知道自己的设计会对进度造成的影响，进而你们才会去衡量，方案一略优的体验是否值得其额外的开发工作量。如果你闷头自己选择了方案一，并完成了精细的产出文档，在一周后的设计评审中，才得知其因没有突出的体验优势、又会拖延进度，而不得被采纳，之前的工作就白做了。

4. 懂点代码，穿上开发人员的鞋子

在上面提到的例子中，如果你懂代码，就能自行评估每种方案的工作量，那么连与开发对接的时间也可省去了，效率显然更高。

然而设计师懂点编程语言，有利也有弊，为什么呢？

当在技术层面懂的越多时，你在做设计抉择时，就会更倾向于评估设计的可实现性，而这有可能会限制你的创造力。设计师工作的第一步，往往越天马行空、大胆，越好。懂得太多，可能还未撒开手，已经被理性叫停。也许天才开发小哥能神速写出此功能呢？也许产品经理就是买你的账，宁愿牺牲进度也要将该设计上线？

因而，设计师是否该懂技术、懂多少技术，答案不是绝对的，取决于其所服务产品的特性，以及其自身拿捏的度。

结语

做设计时，不要只沉浸于自己的工作，而要尽可能地为设计工作前后交接的同事考虑；在设计前期与产品经理多沟通，设计中后期更与开发人员多沟通，以提高项目的整体效率。

从设计师个人成长的角度看，长期以来节约的时间也可用于设计充电，了解更先进的设计理念，培养更全面的设计思维与技能，为日后可能接手的项目打下更好的基础。

另外，有事没事跟前端小哥多开开黑，跟姑娘们多分享分享淘宝链接八卦消息，下次再拜托他们改设计时，人家态度可能会更好噢。