关于产品创造，大家都知道的一件事是：并不是设计师独自设计一款产品。许多利益相关者需要参与设计产品的过程并共同创造他。
许多公司的设计师与产品经理、产品负责人、QA 团队密切合作创造产品，但更多的时候是设计师与开发人员密切合作。
在我看来，设计师和开发人员之间能否密切合作对最终产品有很大的影响。他们需要密切合作以解决可用性和技术问题，以便为客户提供重要价值。由于关系密切，必须在两者之间建立良好的关系和有效的沟通。
很多产品团队之间存在着沟通问题，设计师不了解开发人员，开发人员也不了解设计师。沟通不畅会设计师和开发人员产生很多摩擦和误解，并导致团队内部返工、压力过大和易产生不良关系。在过去的六年中，我与开发人员密切合作，这使我能够从多个角度了解他们。
这篇文章的目的是 分享一些我学到的处理与开发人员的关系和沟通的技巧。我相信你会发现这些技巧很有用，并且能够将它们应用到你的日常工作中。
有时，并非所有团队成员都知道产品的用途、用户是谁及产品目标是什么。这似乎很讽刺，但有时开发人员确实在开发产品时并未意识到这些方方面面。
在大多数产品团队中，是产品经理协调整个团队，但并不能保证产品经理能够协调好一切工作。由于开发人员可能没有意识到这些信息多么关键，因此可能会导致进行很多无效的讨论。
召开项目启动会
在团队开始处理大型项目或明确目标用户之前，可以召开一场项目启动会。在会议上团队将一起梳理项目中所有的用户需求，以便所有团队成员都能就其相关问题达成一致；团队还可以讨论他们在这个项目中可能遇到的潜在问题。如果不知道如何召开项目启动会，你可以查看 Atlassian 网站。他们有一个很好的模板来说明如何操作。我相信它为这次会议给予充分说明，并会给项目带来很大帮助。
提出关键问题
如果与开发人员沟通希望彼此理解，你可以问他们这些简单的问题：
通过听取他们的回答，你可以很快注意到存在知识盲区。有时你会发现他们不了解产品中的某些内容，你也会注意到你们对于产品的知识差距。如果发生这种情况，和他们的项目经理讨论以共同建立对项目的理解。
为团队中的每个新开发人员创建一个了解流程
你可以创建一个简单的流程来讲解用户和产品的所有基本信息，给团队的每个新成员进行培训，帮助他们理解产品，确保他了解关于项目的信息。
在这种情况下，要确保他们要清晰地了解这些信息：
也许这不是你的职责，但如果你想与开发人员顺利合作，你应该确保新团队成员知道这些重要信息。
作为设计师，我们对自己的设计非常挑剔，对页面上的每个像素都很敏感，如果开发人员最终实现的效果与我们的设计有任何不同，我们都可能会不太开心。如果发生这种情况，我们应该心平气和地与开发人员进行沟通，并向他们解释设计和开发之间的区别。
在进行沟通时，最好先肯定一下他们的工作成果，然后解释为什么需要修改某些部分。所以要冷静地一起讨论需要修改的地方，并给他们解释这样设计的原因，它对用户的重要性。如果你注意到了某个错误重复出现，一定要去了解错误发生的原因并努力解决它。
例如，如果你发现开发人员总是犯错，那就需要和他们好好沟通来了解一下他们的工作方式；也许他们没有注意到你添加到文件中的流程图，或者他们不知道怎么在 Figma 中使用原型，我相信向开发人员展示如何正确使用软件并不是一件难事。
作为设计师，应该确保团队了解你的设计。在这个过程中，我们可以在设计评审、紧急会议或者闲聊时和开发沟通，给他们讲解自己的设计。我们经常需要解释一个复杂的流程或交互操作，但这些问题解释起来并没有那么容易。
因此，当你向团队成员解释某一点时，可以时刻地询问他们是否能理解你所说的内容。
你可以这样问他们：
我给你讲清楚了吗？
你能理解我讲的内容吗？
人们往往不喜欢承认自己没听懂，所以这样提问能鼓励他们提出问题并发现没有理解的地方官。我记得在一次设计审查会议上，我需要解释加载在我们的 APP 中是如何工作的。我说了大概这样一句话，“不要忘记在 APP 完成渲染之前添加加载占位图。”
讲完了以后我问了大家还有什么地方我没有说明白好几秒钟后，一位一个月前加入团队的初级开发人员问我：“什么是加载占位图？”
在做交互设计时，很难只用文字来解释所有内容。在展示你的想法时，尽量使用图像、视频和原型等方式配合着进行讲解。
我们以数据表为例，如果要解释其完整的行为，包括批量操作、扩展选项和动画，仅用语言文字是无法解释的。在这种情况下，你可以提供一个其他数据表的视频，并创建一个简单的线框原型。这些视觉效果可以辅助你进行讲解，为团队提供完整的理解并减少你的解释时间。
前段时间，听过这样一句话：一张图胜过1000字，一段视频胜过1000张图。我相信它很好地解释了这一点。
我们设计师经常会使用一些只有自己理解的术语，例如排版 x 高度、互补色或字体名称。在与开发人员沟通时，尽量用简单的语言来描述事情。如果你发现开发人员不理解，一定问一下他们不清楚的地方。
设计师有时认为他们比其他人更了解产品，但事实并非如此。设计师确实对用户和视觉设计有很多了解。不过，我必须说，我的编程学习最重要的部分来自于和开发人员共同探讨问题。
编程知识是一个产品设计师能力的重要组成部分。参加会议的时候，如果只了解设计流程、用户需求和视觉效果是不够的。有必要了解一些来自关于软件开发的基本概念，例如 merge (合并) , branch (分支) , deployment（部署对象）, React（React框架）,和 API（接口）。
如果你不熟悉一些基本概念，你就无法全面了解产品，针对设计做决定时可能就会出现问题。
一个简单的例子是当设计师参加关于一个新项目的启动会议时，设计师从开发人员那里听说他们想要使用 React 库来更快地构建产品。如果设计师不知道 React 库是什么并且也不问，设计师将不会意识到他们可以使用该库更快地设计视觉组件。
因此，如果你与开发人员一起进行项目，并且他们开始谈论你不熟悉的话题时，可以让他们给你讲解一下。在大多数情况下，他们会很乐意细讲关于开发的知识。
另一个好方法是写下每个你不理解的概念，然后在维基百科上阅读或在谷歌上搜索，这种方式能很快地提高你的知识储备。
在许多情况下，我们在设计时不需要发明新的解决方案。我们可以复制其他产品的解决方案，没有必要从头开始设计它。很多公司已经做过了，我们只需要调研另一家公司的产品，把这个功能复制过来就行了。
例如，如果你想向开发人员解释登录界面是如何工作的，可以在会议上给他们展示其他公司的登录功能。
当然在交接之前创建原型和流程图也是必要的，这一步可以作为方案落实下来的文档，节省很多讨论和会议的时间。如果谷歌、苹果和微软使用相同的解决方案，我们猜测它会更加奏效。
不同的产品团队都存在的一个问题是开发人员不了解设计。当然，他们不需要了解设计的所有内容，但了解一些关于设计的基础知识是一个很重要的优势。
根据我跟不同团队合作的经验，我可以说，当我们需要共同探讨解决方案时，具有一些基本设计知识的开发人员可以帮助我们。此外，了解设计的开发人员可以提出出色的解决方案，并可以在设计出现失误的时候及时发现。
想象一下，当你遇到某些事情时，开发人员会根据设计原则帮助你解决问题。很酷，不是吗？
所以如果你想付诸行动，可以从基础开始做起，给大家讲一讲 Norman Nilsen 的十大可用性原则。
你可以邀请团队每个月开一次会分享这种知识。这是一个缓慢的过程，但随着时间的推移，你将拥有一支更强大的产品团队，可以为你提供支持并帮助你构建更好的产品。
如果你没有时间安排会议，尝试在工作过程中讲解设计。例如，当你向团队展示解决方案时，可以解释一下你选择该解决方案的原因以及它是如何与设计原则配合使用的。
当你尝试与他们分享这种知识的时候，他们会非常感激你。因为我经常听开发人员说他们想学一些设计的知识，但却无从下手。
通常，在将设计进行开发之前，产品团队会召开设计审查会议，以确保所有团队成员都达成共识并征求他们的意见，这是非常好的。但是，我建议让开发人员从一开始就参与设计过程并进行协作，而不是在真正进行开发的一分钟前才让他们加入，到时候你可能会对他们所提供的帮助感到惊讶。
有时候，除了询问他们的想法以外，我还带领他们使用一些例如疯狂 八分钟法 [1] 的设计工具进行练习，一起发散出一些解决方案并讨论决定选择。
( [1] 疯狂8分钟法: 是一个核心设计冲刺方法。通过快速草图练习，旨在挑战人们在8分钟内勾勒出8个不同想法。目标是推动你超越第一个点子（通常是创新性最差的），并为挑战找到广泛的解决方案。）
当开发人员从一开始就积极参与并添加他们的意见和想法时，他们会发生三点变化：
你可以采取的措施：
这里有一件重要的事情：如果你征求了他们的建议，就需要对改变保持开放的态度。仅仅询问他们对设计的建议是不够的，把这些想法考虑在内而不是忽视掉才是非常有必要的。
在当下，有时很难整天工作和集中注意力。许多群消息、电子邮件、手机消息响铃和其他干扰会使开发难以专注于任务。
当一些事情打断了我们的注意力时，很难重新集中注意力，所以如果你有一些问题要问开发者，最好花半个小时和他们集中讨论所有的问题。对于在时区不同的地方工作的团队来说，另一种方法是录制一个视频并把所有问题都列举出来，或者在像 Figma 这样的协作工具中添加注释。
如果你每 5 分钟问他们一个新问题，他们会感觉到你在不停地戳他们，所以尽量把你所有的问题集中起来，一次问完，这样也是在尊重他们的时间。
在与开发人员交谈讨论设计时，可以问一下开发起来有没有困难。最好这样做，因为开发是一项复杂的工作，如果我们让同事开发一个非常复杂的解决方案，构建和发布可能会花费很久的时间。
例如下面这个情景：
开发人员需要四个星期来完成你的设计，但团队需要在两周内发布它。你可以问一问他们两周能做多少？
从那时起，你可以将整个方案分为两部分。在第一版中，团队需要完成基本功能的构建，在第二版中，需要完成整个 APP。产品负责人或产品经理通常会处理这种情形，但是，如果团队中没有产品经理，你可能将需要帮助团队来解决这些问题。
在问开发问题之前，先研究一下主题内容，同时把聊天群消息、通话，当然还有会议的内容也了解一遍。你可以阅读产品的文档并在 Google 上进行一些搜索，我觉得除了会节省时间外，你自己进行信息检索时会对讨论更有把握。
当然，跟他们讨论之后去进行调研了解相关的内容是必要的，但是最好的还是在询问之前就自己进行调研，产出一些想法，这样的话开发者就不需要给你从零开始解释。
当你这样做时，和你一起工作的人会觉得你掌握了工作的主人翁精神，他们不会觉得你每五分钟问他们一个问题，是因为懒得自己找资料。
我们经常会有很多关于产品的资料，大多数公司使用设计系统来帮助来整理视觉资产和设计稿，这是非常好的。
除了视觉资产这类之外，我们还希望给其他团队成员传递更多的信息，例如流程图和原型以及有关方案的一些解释。因此要想促进沟通，就要把资料整理好与团队分享。
没有必要一定要全部放在一个像 Figma 这样的协作工具中，但让其他成员能够便捷地查找到资料是非常重要的。当然，你与团队共享的所有资料都不要忘记授予访问权限（同时避免将重要信息保存在本地计算机中）。这样，开发人员就不会再问你文档放在哪以及为什么无权访问这种问题。
如果你发现团队中存在问题并且事情进展不顺利，可以召开回顾会议。
召开回顾会议的目的是审查团队的工作方式以及如何改进。在这里可以讲出来：当我与开发人员交付设计资产时发生了问题。
因此召开了回顾会议之后，我们使用了一种更好的方法来交付设计内容，它让我们整个团队表现得更好，许多摩擦都因此而消失了。
如果你想了解更多有关回顾会议的信息，推荐了解一下 Atlassian 模板，它详细解释了回顾会议应该如何进行，非常推荐大家去学习。
也许这是我可以在本文中与你分享的最重要的事情。
良好合作的最佳方式是和开发人员建立良好的人际关系。可以没事的时候他们聊聊生活、日常和兴趣等等。这样你就能和他们成为朋友，而不是队友，并赢得他们的信任。
与别人产生共情最重要的因素之一是了解他们的生活。例如，如果你知道同事的孩子今天第一天上学，你可以问：嘿，今天是你孩子上学的第一天，他们兴奋吗？或许这看似没什么，但这种同理心和理解，其实构成了人与人之间的关系。希望这篇文章能帮助到你，如果觉得有用一定要分享给你的朋友和伙伴~
加油🥤