作为一个团队的设计:跨职能协作的实用指南

我们相信跨职能的协作能够加速为我们的用户提供更好的结果。然而，这到底是什么样子并不总是显而易见的。团队的成功需要哪些实践?团队应该体现什么价值观?

我们是谁?我们是一个喜欢跨功能配对的开发人员(Valerie)和设计师(Christopher)。在一个分布式团队中，在高压、时间敏感的环境中，我们已经将以下建议付诸实践，在客户组织中没有设计能力。即使在交付时间紧迫的情况下工作，我们也找到了一种优先学习和试验的方法。在设计为团队指南，我们也会向你展示如何做到这一点。

我们将提供跨职能合作的具体例子，同时分享一些激励我们的价值观和原则。我们希望这可以为您的团队提供灵感，并拓宽您对设计如何在业务过程中提供更大价值的认识。

你应该阅读以下内容:

• 您是一名设计师，试图定义从策略到执行的设计敏捷性是什么样子
• 你是一个产品经理，需要清楚地说明你的角色和设计师的角色之间的区别
• 您是一个交付团队成员(开发人员/质量分析师/项目经理/等等)，想知道“设计到底是什么?”我为什么或者应该如何参与?”
• 你是一个团队的领导者，试图弄清楚如何做正确的事情，并把事情做对
• 您正在寻找一些具体的示例，以了解如何打破产品开发中的竖井，并为用户快速交付新功能

断开连接的工作流

克服组织惯性很难。设计，商业和技术之间的筒仓促进了发现和交付之间的更长的反馈循环。如果没有跨职能合作的文化，我们努力跟上商业和用户需求所需的变化步伐。

在技术开发中引入以人为中心的方法并不缺乏——比如精益用户体验、敏捷体验设计、平衡团队、以人为中心的设计、设计和设计思维——等等。除了以人为本，这些战略还强调了成果的重要性，而不是产出的重要性，这是衡量成功的关键指标，并强调了跨职能或跨学科合作是实现这些成果的关键驱动力。

如果你在筛选所有这些方法时感到不知所措，你不是一个人。如果没有将战略转化为战术的模型，你可能会发现自己在质疑自己做的事情是否正确。

也许你当前的设计实践是这样的:

• 产品经理从业务主题专家那里收集需求列表，然后将其传递给设计人员
• 设计师在没有任何真实用户反馈的情况下，独自绘制高保真模型。设计师将模型上传到故事卡片上，然后就再也不会重新访问这些模型了
• 开发人员使用模型作为像素完美的规范，如果不理解潜在的交互设计以及如何将其融入用户旅程，就很难提出正确的问题
• 质量分析在不理解预期结果的情况下测试应用程序的行为，比如这些功能将如何解决用户的问题并支持业务需求
• 如果提供的是用户实际增加的价值，则没有人措施

在上面的场景中，这些角色彼此具有最小的互动，并且通常不在同一支队上。但是，他们可能会说他们在合作环境中工作。他们并不完全错误，因为最终结果来自努力的组合。但是这个不是当我们谈论跨职能配对的协作时，我们的意思是什么。这个断开连接的工作流是面向移交的。交接是合作的对立面。

创新和同理心的关系

打造伟大的以人为本的产品，首先要与用户建立同理心，以及彼此之间的同理心，并迅速适应我们发现的他们的需求。我们可以把这个观点映射到创新的三个视角：

• 我们想要满足的需求是什么?(是我们的解决方案有价值的？)
• 我们如何交付?(是我们的解决方案可行的？)
• 我们能保持这种势头吗?(是我们的解决方案可行的？)

同理心是在三个镜头上传播我们的研究和理解的原因。我们使用我们的同情与用户达到价值和可行性的理解。我们使用同理心来互相建立信任并更好地合作。通过通过合作相互信任，我们寻求了解我们产品市场中有价值和可行的关系的可行性。所有这些都是设计工作。我们都有很多学习的用户，彼此，这就是为什么我们相信设计为团队的力量。

创新的三个视角:我们的目标是创造出有价值(可取)、可行和可行的东西。我们通过在我们的团队和我们服务的社区中支持同理心和信任来做到这一点。

在我们的方法中，设计是一个共同的责任。这意味着建立对用户旅程的共同理解，并并肩工作，利用每个人带来的不同技能和观点。这项工作的结果代表了我们的假设，即什么是可行的，可行的，有价值的，这需要在生产中进一步测试。如果没有这一点，产品经理就只能猜测用户的需求，设计师在没有解释的情况下就交出UI规范，而开发人员在没有理解的情况下编写代码。

平衡的团队构成对于有效的跨职能合作至关重要，因为它开启了我们原本不会考虑的潜在学习机会。设计师/开发者组合(就像我们!)往往会推动以这种方式组建的团队的动力，因为我们从这种特殊的组合中获得的价值是最明显的，但我们还有更多的可能性。如果质量分析师和设计师配对，我们能学到什么?产品经理和开发人员?设计师和现场可靠性工程师?开发人员和客户支持人员?

当设计成为一个团队实践时，我们也开始重新审视我们角色的责任，以及每个人的工作是如何对我们所知道的用户旅程做出贡献的。

我们的方法:最小可行实践

将这一愿景转化为行动需要将行为与团队的价值观和需求相一致。在我们的团队中，我们通过头脑风暴和原则投票，以及起草团队章程来明确这些原则。这使我们能够不断地问自己，我们需要添加或改变什么实践来实现我们的愿景，并在设计空间中积极协作。

我们认识到，形成新的习惯需要深思熟虑的努力，所以我们总是试图把任何新的实践视为“最小可行实践”。最小可行实践是我们获得所需学习的最简单的方法，需要尽可能少的参与者来获得学习。我们使用实时反馈和回顾来改进我们的实践，并确保它们的目的仍然有效。最坏的情况是，我们只是浪费了30分钟到一个小时的时间来尝试一些我们立即放弃的东西。最好的情况是，我们学到了一些有价值的东西，并为下一次迭代做准备。

通过使用旨在解决我们面临的实际问题的最小可行实践，我们没有在无效的新实践上浪费时间。我们的团队总是尝试不同的实验，因为活动总是有时间限制和结果导向的。

跨职能实践的例子

你将在《设计团队指南》中找到超过20种跨职能协作的实践，以及激励我们的一些价值观和原则。我们希望这些例子能给你一些思路，帮助你将策略转化为解决问题的策略。

以下是我们如何配对的几个例子:

设计和技术债务审计

大多数团队都熟悉技术债的概念，但很少有团队跟踪设计债。设计债是与内容是否可感知、可操作、可理解、健壮和一致有关的可用性问题集。在最好的情况下，这是UI的一个有点恼人的怪癖;在最坏的情况下，它可能会阻止用户完成他们的目标。设计债的积累可能会削弱用户对系统的信心，或者更糟的是，削弱用户对自身的信心，因为他们无法找到解决问题的方法。

我们团队的开发人员已经很熟练了管理技术债务从以前的经验来看，所以在现有习惯中引入新维度的努力是相当低的。开发人员、质量分析人员和设计人员将在他们观察技术债和设计债时捕获它们，并且作为一个小组将根据他们对工作和影响的理解定期检查和优先化收集的项目。

配对解决方案探索

像Thoughtworks的许多团队一188bet宝金博app下载样，我们习惯了“结对”的想法，即除了编程之外，还包括其他角色和活动。一个常见的组合是设计师和开发人员，活动取决于谁在推动探索。

例如，设计师和开发人员一起绘制草图，以便在考虑技术可行性的同时快速头脑风暴设计方案。开发人员和设计人员一起编码，验证在实现，并被授权在发现约束时动态地进行权衡。这些类型的探索增加了团队成员对技术和设计观点的共鸣，并培养了用户体验的共享所有权。

使用我们的作为Team索引网格进行设计为您的团队确定最佳的配对技术。