你可能听说过 敏捷 软件开发，看板过程管理，以及 精益UX. 协作设计是一种不同的哲学和战术方法 企业产品设计.

协同设计是一种参与式的设计过程, 引人入胜的, 和现实的全员还是 智囊团 环境. It is NOT designing in a vacuum; instead, 顾名思义, 协作设计将设计师置于各个团队和部门的中心，与每个人一起工作，以构建具有凝聚力的产品. 通过这种方式，没有人会被遗漏，并且产品可以在所有涉众参与的情况下构建.

每个企业组织都是不同的, 把利益相关者围在任何想法或任务周围，就像把猫聚集在一起一样. 在本指南中, 我们将回顾与主要参与者合作的技巧和技巧, 不仅要得到他们的意见，还要让他们接受这种以设计为中心的新方法.

与玩家见面

设计师 在很多事情上都很出色，但他们的角色是从解决问题开始的. 这需要知道谁是专家，并与他们合作. 产品开发团队的每个成员都有自己的需求和责任, 所以了解他们和完成作业一样重要.

废话不多说，让我们来见见团队:

• 产品经理 定义范围, 需求, and development iteration cycles for products and features; they are often the gatekeepers for features in advance of a final yes/no and are practiced at communicating 与 the entire organization, 包括高管.
• 工程师 构建产品，让他们了解技术能力和限制. 这使得它们成为确定主要关注点(包括开发时间表)的关键资源, 使用的技术, 范围, 通常是设计可行性(如果我们的概念在技术和时间限制下可行的话).
• 数据库和系统架构师 了解如何集成数据，并深刻理解在继续构建现有产品/平台的同时保持性能所需的条件.
• 内部主题专家(中小企业) 非常熟悉业务流程吗, 用例, 历史, 和政治, 以及管理层的普遍期望, 客户, 和用户.
• 销售 专注于向潜在客户展示产品. 这使得销售成为第一个接触点, 因此，他们对产品的理解对于关闭(通常是创建)潜在客户至关重要.
• 培训师 (或者在SaaS中， 客户成功代理)直接接触销售团队和新用户或试用用户, 他们可以提供大量关于产品性能的有用信息 在体外 及以后.

当产品的所有工作人员都参与到设计过程中(设计的基本原则之一) 敏捷方法), 最终的产品有更大的成功机会——不是因为设计师与利益相关者合作, 但是因为利益相关者, 通常, 了解特定的用户和业务需求，这是我们可能无法做到的. 协同工作似乎总是最好的选择，但我们如何做到这一点呢?

如何与持份者合作

产品经理，产品的门卫和计时员

产品经理通常对产品有个人依恋，在公司内部被寄予很高的期望. 当出现问题时，他们还必须对产品的用户或客户负责, 未满足的承诺, 或对新功能的请求.

他们高度重视简单的沟通，需要保持最新的进展, 问题, 有什么变化吗?. 他们喜欢先看草稿，而且经常看草稿, 而且因为他们可以在不同的规模上工作(从直接的产品开发到亲自动手进行甚至很小的更改的几个级别), 你与他们的互动可能会有很大的不同.

因为项目经理花费大量时间与各种涉众(内部和外部)进行沟通, 重要的是让他们了解情况，而不是期望他们与你联系. 与您的pm建立定期的检查，以呈现迭代的草稿, 倾听他们的反馈, 并且总是以下次会议的行动项目清单结束.

用不了多久就能知道他们的产品功能目标是什么. pm知道 设计师 是问题解决者，所以设计师需要提供数据和分析来证明他们的推理. 你是对还是错都不重要. 证明构建最好的产品是你的目标，你将赢得PM的信任!

工程学:负责将设计变为现实

工程师 (also called developers) are the people closest to the product; they build it! 这给了他们一个优势，因为他们可以直接体验和测试产品的各个组件 在行动. 这很棒，因为, 毫无疑问, 他们会发现任何设计中的弱点——有时在构建任何东西之前——这是加倍伟大的，因为在软件编码之前找到缺陷在很多层面上都是一个巨大的优势.

赢得工程团队信任的最好方法是要么制定全面完整的产品规格说明，要么尽早让他们参与进来，或者两者兼而有之.

当开发者被认为是真实的 利益相关者, 他们更愿意讨论用例, 场景, 技术挑战, 以及克服它们的方法.

It’s easy to forget that engineers are true product architects; they have a vested interest in 解决问题 与 设计师，特别是当挑战很困难或可以用其他方法处理时.

数据库和系统架构师，数据结构的守护者

数据库 系统架构师知道产品在幕后是如何工作的. 他们了解数据的存储和结构, 什么可以被整合, 以及所有系统如何相互通信. 他们往往不太关心产品如何为用户工作，而更关心产品如何与各种系统交互(这是他们最终负责的)。.

对他们来说可能特别困难 以用户为中心的设计师 处理. 重要的是要记住，即使数据库/系统架构师从不与最终用户交互, 他们的重点始终是通过产品可靠性使用户受益, 速度, 或简单.

他们对数据结构如何操作的了解——以及对产品功能的任何更改的影响——如果没有他们的专业输入，很容易被忽略. 邀请系统架构师参加关于产品变更的会议和讨论是很重要的, 即使他们的职位似乎没有直接关系.

与系统架构师合作的一种方法是创建一个包含以下问题的检查表:

• 特性X会影响当前的数据结构吗?
• 还有别的吗? 设计/开发 考虑当前架构的工作?
• 设计Y是否与任何现有的用户输入/输出相冲突?
• 是否有任何外部服务受到特性X的影响?

这个简单的清单将为你指明正确的方向, 即使没有清楚地了解现有的(可能的)单片数据结构是如何工作的. 任何被选中的都是一个应该通过简单的讨论来调查的领域.

主题专家和业务分析师，信息奇才

Subject matter experts are aptly named; they are experts in the subject matter and can be a gold mine of unique and valuable information. 经常, 他们获得了该领域的专业学位, 或者他们一生中大部分时间都在自己的行业中工作. 他们对企业应该如何运作有实际的经验, 他们回忆起漫长的, 痛苦的历史和政治导致了每个人今天的处境.

业务分析师了解组织运作的来龙去脉，如果数据可用，但没有内部专家，业务分析师通常履行与中小企业相同的职能.

与中小企业接触，了解管理层如何看待项目，以确保满足内部期望，并且您没有涉足危险领域. 邀请分析师参加设计会议, 提前告诉他们，他们是专家，并要求他们分享他们对历史失败的了解, 政治冲突, 以及其他可能对产品成功发布至关重要的问题.

客户成功经理，新客户的接触点

当新客户最终被销售人员录用时, 运动鞋或, SaaS公司, 客户成功经理(csm)——负责指导新用户如何实际使用产品. 所以不用说，培训师花了很多时间与新手用户交谈. CSM具有独特的视角，因为他们与通常不参与公司购买决策的客户进行交互.

有了这个独特的视角, 培训师/ csm可以为设计决策提供有价值的信息, 包括客户入职和新用户行为. 许多企业组织跟踪和监视他们的新客户如何使用各种 产品和工具, 记录下从电话到投诉的一切, 但这些培训师知道客户真正在纠结的是什么.

在所有主要的设计会议中都安排一名高级培训师，并询问他们是否有任何决定. 问这样的问题:“最严重的三个客户投诉是什么??以及“新客户平均对产品满意吗??以及“你认为什么样的改变会给你和你的团队带来最大的积极影响??“这边走, we all learn about what the happy path is; trainers are our eyes and ears for all the ways 客户 actually use the product.

销售，产品与客户的第一次接触

销售和设计经常是矛盾的. 一些组织是销售驱动型的，而另一些则不是, 但无论如何, 在目标上有明显的不同:销售团队想要增加销售额，而设计团队想要改善用户体验. 它们并不总是一致的.

事实并非如此. 大多数销售人员都有非常合理的抱怨:他们对产品决策几乎没有控制权, 被要求做出他们无法真正承诺的承诺, 不管怎样，他们都被驱使着去实现特定的收入目标. 销售团队和产品团队经常发生激烈的争论，这并不奇怪!

不过, 喜欢运动鞋, 销售组织对客户需求有独特的看法, 而且经常, 这一观点便是创造小额销售与创造鲸鱼用户之间的区别! 了解销售团队努力解决的不同领域. 试着旁听每一种类型的电话，学习这些潜在客户是如何沟通的.

这将开启与销售的对话. It isn’t just about having their needs heard; it’s about improving the experience for potential users at every stage, 从第一次沟通到入职后. 找出销售人员从潜在客户那里听到最多的是什么, 他们在敲定这笔交易时遇到了多大的挑战啊, 关闭后最大的担忧是什么.

企业设计不一定是一场噩梦

作为一个设计师, 所有这些活动部件都很难管理, 尤其是当你不被认为是官方意义上的“经理”时. 作为跨团队沟通的关键利益相关者, 需求的收集, 设计反馈, 你应该在某种程度上接触到所有这些专业人士.

最关键的, 然而,简单的, 做到这一点的方法是倾听各方的意见，并认真对待他们的反馈. 在大多数组织中, 下一步是接受反馈，并与产品经理一起将需求组织成可操作的工作.

从那里，它取决于优先事项和填补空白. 最终, 目标是设计出最好的产品, 我们需要所有产品开发人员的帮助. 认识到每个角色都是重要的，并使这些人员意识到他们在产品开发周期中的价值，使他们能够提供设计师需要的信息，以做出更好的产品设计决策.