PM、UX、工程协作
PM、UX、工程协作
有些产品经理可能认为他们的工作只是写需求。一些工程师可能认为他们的工作只是编写代码。还有一些用户体验设计师可能认为他们的工作只是为了创建一个设计文档。
此外，我们这些人，在一个项目上合作：
- 来自不同的公司和产品文化，
- 对重要的事情有不同的期望，
- 并且有不同的沟通方式。
以下是关于 UX 和工程协作的一些想法。
UX，不仅仅是 Figma 文件
UX 设计师不能只对设计文件负责。以下 UX 职责对于取得质量和快速进展至关重要：
- 根据需要与工程师、产品经理和其他设计师进行“一对一”会议。如果没有“一对一”，关系就没有建立起来，可能会产生一个不安的工作环境。
- 与工程师一起找出技术限制。讨论它，一起工作，不要依赖离线的基于文本的对话。
- 建议并就应该进行的范围进行协作，最好将范围优化到最低限度。并捕捉在 UX 工作期间被描述的内容。
- 如果您有一个新想法，请与每个人交流，并征求反馈意见，但不要只是去做。
- 根据需要组织设计会议。尤其是当 Figma 中的讨论时间过长或者评论太难解决时。
- 尽早并尽可能多地寻求反馈，产品经理和工程师是第一批用户。
- 捕获并记录重要的设计决策。
总而言之，优秀的用户体验设计师是优秀的沟通者。
工程师，更好地解释并耐心等待
这 产品工程师 喜欢与用户体验和产品经理一起工作。工程师是特定技术的专家，该技术规定了在大多数情况下应该遵循的许多设计原则。
有时工程师认为用户体验设计师应该什么都知道，但这几乎是不可能的，除非你有一个只专注于特定平台和技术的用户体验专家，例如移动设备上的 iOS。
让我解释。工程师需要相当长的时间和精力才能赶上所有新技术的进步。例如，想想 iOS 的发展速度有多快，以及新的设计原则发明的频率有多高。这些范式和原则的变化会影响应用程序的设计方式。用户体验设计师不可能知道苹果在“全球开发者大会”期间介绍的每一件事。
我们发现，在经验丰富的产品工程师和用户体验之间进行“一对一”会议是最有益的活动，可以让用户体验与最新趋势和技术可能性保持同步。
总而言之，伟大的工程师是伟大的沟通者。
UX，解释原因并与所有人交谈
我们一直在努力限制会议的数量，这样我们就可以成为一个更有生产力的团队。但我们发现，在没有任何上下文的情况下发送指向 Figma 文件的链接弊大于利。
为防止混淆，用户体验需要添加对设计更改发生的内容和原因的简明解释。此外，最好明确说明设计的状态以及您正在寻找什么样的反馈。如果这是一个早期的想法，您期望得到高级别的反馈。如果它是一个高保真设计，你期望得到人们应该关注每一个细节的最终反馈。
如果审查设计的信息不能简明扼要，那么应该安排一次设计会议是一个很好的指标，因为它需要更多的讨论来解释用户体验的进展。
我们发现在 Slack 频道中提供每日或每周（根据需要）更新很有用。例如，如果设计已准备好进行审查，请立即寻求反馈，不要等到 sprint 结束。
可能发生的最可怕的事情是定期安排的设计审查会议，例如每周一次或每周两次。这是一个问题，因为那时 UX 开始依赖会议并朝着会议努力，这消除了所有“离线”通信和一对一通信。结果，我们冒着“委员会设计”的风险，导致产品设计平庸。
不要私信评论
当我采访 UX 设计师时，我总是会问 “想象一下，你花了 2 周时间做一个设计。你有一个非常漂亮的高保真设计，你对它很满意，并且你认为它已经准备好进行开发了。然后，工程师给你反馈他们不了解主要的用户流程并且存在逻辑缺陷。你有什么反应？” （这是一个错误的问题，但这是故意的） .答案通常是， “我不接受个人评论” .
但是当这种情况发生时，无论规模大小，用户体验设计师通常都会亲自处理。
因此，在阅读反馈时，请假设最好的意图，而不是相反。此外，每个人都想创造一个伟大的产品，这就是他们表达意见的原因。在所有这些困难的讨论中，用户体验需要成为设施的一个很好的沟通者，并且需要能够从所有反馈中提取好的部分。此外，用户体验需要能够优先考虑（并对其进行推理）应该保留的内容以及我们现在应该讨论的内容。
另外，经常询问反馈，而不是一周或两周一次。这将防止团队出现令人惊讶的大反馈循环。
尽早包括所有人
我们看到的第一个错误是 PM 和 UX 不想在设计上打扰工程师，他们孤立地进行设计。一旦 PM 和 UX 认为设计已经准备好，他们就会创建任务并将设计交给工程师。
由于工程师之前没有参与到任务中，他们会有很多问题，甚至可能会质疑设计的逻辑流程和可行性。这最终会导致各方面的挫败感，包括工程、产品经理、用户体验和其他方面。
工程师是我们的第一批用户！
工程师们很沮丧，因为他们不了解发生了什么，因为当 PM 和 UX 做出许多设计决策并且这些设计决策没有在任何地方传达时，他们并没有参与工作。这导致工程师处于不了解设计的状态，缺少流程，使用定制组件而不是设计系统中的组件等等。
UX 很沮丧，因为工程师的评论和问题太多。毕竟，更新现有设计比从头开始创建新设计需要更多的精力和精力。然后，UX 没有时间进行更改，因为首先，很难更改高保真设计，其次，他们应该已经在处理另一项任务。问题是，我们什么时候应该包括所有人？不可能每个人都知道一切，所有的人也不可能参加所有会议并参与所有讨论。
我希望工程师花更少的时间来理解问题，而花更多的时间编码。 _
—_ 从来没有人说过。
我们提出的想法是由产品经理、UX 和工程师一起创建线框和线流（或活动图）。这将帮助每个人了解问题以及我们如何考虑解决问题。产品经理会得到需求反馈，UX 会得到基本流程和一些早期的技术限制，工程师可以考虑实现新功能需要进行哪些 PoC 和准备工作。
最好的办法是计划一个 设计冲刺 并一起开发产品。好处是相同的，但只是一起做活动图时会更加强烈。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
