devpoint.cn

团队合作，有的时候也需要讲究规范化，规范性的指南在指导设计与开发的交接时很容易遵循与修改，但是这些具体的操作指南是否能跟得上未来新工具的更迭？

人们都喜欢步骤型的教学内容。我作为设计刊物的编辑，经常会见到许多类似于“10步完美与开发人员对接”或是“整理设计文件时的禁忌”，他们会吸引许多在执行日常工作前需要寻找指导的设计师。这些指南大多数都是一些策略性的小技巧，例如标注设计文件、整理文件夹，或是同类文件整理的最佳案例，这些小技巧被证明可以应用到工作中的各个方面。

规范性的指南在指导设计与开发的交接时很容易遵循与修改，但是这些具体的操作指南是否能跟得上未来新工具的更迭？

事实上有许多种方法可以整理文件，命名文件夹或是多版本管理。如果只是提供一种方法，那么设计者就没有考虑到每个团队的需求与执行方式都是不同的。

我们使用的工具会经常变化。设计师们处于各行各业，设计类型与所处团队规模都有差异，而且每家公司都有自己的组织影响设计师的工作流程，工具使用与执行。甚至在同一个团队中，由于时间与合作人数的变化，设计的具体流程也会发生较大的变化。

好的合作方式是提供原则指导，而不是具体策略

我工作了15年，见过许多迭代版本的设计师与开发人员的交接流程。甚至在我刚开始从事设计工作时，我们将设计文件存储在本地然后直接扔给开发人员，他们带入自己的主观审美将设计稿转化为代码实现。

经过多年来的发展，设计师与开发者的合作方式已经经历了许多变化。一些方法已经通过实践验证效果较好—但是在不同的项目中，也许某种方法很适合与这个项目，但是对另一个项目而言使用起来却很糟糕。如果我要撰写具体的合作指南，那可能我每隔一段时间都要重新撰写——所以我选择了聚焦于设计原则。原则不仅可以经历时间的磨砺，适用的设计师类型以及团队规模也更广。

下面的列表列出了我个人提出的合作原则，作为一名设计师，我每天至少花三分之一的时间与产品经理和实现设计的开发人员一起工作。虽然多年来具体的方法和技术已经发生了很大的变化，但这些原则仍然能够抵抗时间的挑战。

1、开发人员是您的用户

如果我们像关注用户一样关注开发人员如何使用我们的设计（和设计文档）呢？

作为设计师，我们在思考产品带给用户的体验时，总是考虑用户的需求和痛点。除非你自己开发，否则最终用户永远不会与我们的设计互动，他们将与开发人员基于我们的设计文档构建的最终产品进行交互。这意味着我们在项目的这个阶段所交付给的真正用户是开发人员。

一旦我们将这个概念融入到我们的实践中，关于我们工作流程的每一个决定都是以开发人员为中心开始的。与我们对最终用户进行研究的方式类似，我们可以在项目开始时与工程团队进行面谈，以了解他们的偏好、过程和痛点，并提出满足他们需求的工作模型。

• 开发人员希望如何接收文档？多长时间？通过什么渠道？
• 细节越多越好？书面文档和可视化文档之间的正确平衡是什么？
• 对于特定的开发人员来说，如何使用系统里怎么去工作的非可视规则的最有效方法是什么？这如何与产品的其他部分和组织内的其他组织相结合?

团队可能为了方便协作会为项目建立一个维基百科文档；也许这个维基文档只是一个每周两次的会议记录，其功能更多的是作为记载会议的问答对话而无法形成具体的规范。有一些团队习惯在整理好所有设计文件后才会着手开发；还有一些团队比较灵活，会在开发迭代和实验中不断的完善规范。

既然我们在设计过程中要根据用户的需求调整我们的设计解决方案，同理我们也应该调整我们的设计工作流程，以适应我们的开发合作伙伴的需求。

2、唯一能确定的是：改变始终存在

设计师需要灵活处理项目，我们不仅要调整我们的流程以适应不同的团队配置，而且还要随着项目的展开调整我们的工作流。

除了极少数案例外，我们每次启动新项目时都必须调整文档和工作流。随着经验的积累，我们总结形成了自己撰写文档的模版，这种模版在特定的环境下可能会很好用，但不一定在所有环境下都完全适用。一个模版不是处理每个团队的设计文档和协作的好方法。

其次每个开发人员的习惯不同，有些开发人员喜欢和设计师面对面交流处理具体问题，还有一些开发人员可能更喜欢通过线上消息沟通或是投票表决来解决问题。

不是所有的事情都可以在设计师的掌控中，设计师唯一确定的是：每个项目都会存在变话。

有时候一些客观的因素会影响你的工作，例如新同事加入团队，发布日期的突然调整，不可预见的平台或网络技术的约束。学习识别团队中无形的协作机制并让自己做好快速调整工作流程的准备，这也许不能在短期内避免挫折，但是会让你变得更好。

3、设计永远不会终结

当我们完成一个项目的设计时，其实我们只完成了一半的工作。

特别是在瀑布式开发的项目中，或是敏捷性开发的初级阶段，有一种常见的误解：即设计师的工作就是将所有屏幕显示需要的图绘制出来就完成了所有工作，例如设计产品模型或原型，会让人误以为设计师的职责仅仅是满足开发要求设计师做的每个网页图片。但实际上设计师应该不仅应该考虑屏幕上显示的页面图片，还需要分析背后的功能。

真正的挑战开始于开发人员开始四处寻找关于我们设计的问题以及测试人员分析出设计师没能预见的用例。添加的限制和规则越多，我们就越难在这些条条框框容纳新的需求，并同时保持体验的简洁与明晰。那就是关键时刻：大多数团队能画出合格与优秀设计师之间的那条线。

见过太多设计师推卸责任——这绝不是一件好事。如果最终的体验没有按照我们的设想实现，那么这就是包括我们设计师在内所有人的责任。我们的角色是创造易于使用的体验方案，而不是看上去漂亮的界面。这意味着我们需要为团队实现的最终产品负责。

4、少一点，但更好

当产品经理砍掉产品某些功能来得到一个最小可行性产品时，设计师并不会感到沮丧，而是将它变为提升已有功能集合内体验的机会。

富有远见的德国设计师Dieter Rams时二十世纪最受认可和最具影响力的设计师之一。作为功能主义的坚定信仰者，他对设计的理性认识可以概括为他的著名短语：“少一点，但更好。”虽然他当时显然是针对工业设计，但这一概念对于我们当今创造的数字产品和服务仍然适用。

随着设计的发展，产品经理开始优先考虑功能，这时设计师会发现他们的许多工作都被缩水为最小可行性产品，包括他们对产品的最初设想和经验，这会令人感到沮丧。而我所知道的最优秀的设计师会将这种沮丧转变为机会，他们知道提供更少的功能是完全可以的，只要能提升体验即可。

对于我们设计师而言，需要设计的功能变少意味着：

• 我们能将更多的时间花在更少的设计方案上使其更好：例如过场，状态，动画，复制。
• 我们能更紧密地和开发人员合作以保证我们正确传达了初始设想。

5、激情具有感染力

在一些公司中，开发人员不参与早期的构思、设计探索和产品经理的战略层次讨论。我们如何才能帮助他们理解和领会，从而真正了解正在开发的功能?

设计师代表了团队中用户的声音。我们常常理所当然地认为，我们有能力设身处地为用户着想，而忘记了我们可以在团队中传播这种观点和看法。可以是我们在研究过程中从用户那里听到的一个小故事；或者是某个人的个人故事，因为我们所创造的产品改变了他的生活方式。