准备交接！如何确定开发支持？

编辑导语：设计交接是产品设计落地流程中的一个重要环节，它关系到产品的最终落地效果，也关系到最终的用户使用体验。那么在这一环节中，团队人员应该如何协作，以保证最终的方案实现？本文作者针对该问题做了解答，一起来看一下。

设计交接可能是产品开发过程中最关键但又令人沮丧的环节之一。此时，长时间的研究、设计和再制作工作已经结束，您的设计和高保真原型已准备好供工程师实施。

与任何其他流程一样，设计工作流程也有其缺陷。设计师有时会在发现和开发阶段的中间环节工作。因此，当设计交接发生时，完美设计稿的设计背景和设计意图对于开发团队来说通常是模糊的。

为了确保创意和创意愿景被准确转化为一种功能或产品，设计师最好在整个项目中与跨职能团队密切合作。

与所有垂直团队的沟通和协作是将风险和错误降至最低的关键。每个团队成员都必须同步了解该功能或产品的外观、感觉和工作方式。说来容易做来难。设计交接是贯穿整个设计过程的合作。它需要大量的时间、资源和迭代才能正确实现，以便在团队中建立跨职能协作文化。

现在，让我们深入探讨设计师——开发人员交接期间的一些最常见的陷阱，并回顾一些策略，您可以采用这些策略来确定这一阶段的开发支持。

一、这不是交接，这是协作

交接是一个棘手的词，它意味着单向通信。在项目团队中，它经常被误用为“摆脱”，在我们的案例中，这很重要，因为它意味着剥离责任。

当设计被移交给开发人员后，就认为他们就有责任将产品实现的这种想法是错误的。作为设计师，我们需要投身于产品开发，并确保在交接后不会产生丢失或误解上下文和设计意图等问题。这种疏忽可能导致功能或产品不能完全达到预期目的，这是每个设计师的噩梦。

最好的情况是，设计和开发团队在开发过程中的每一步都密切合作和协作。有时，这意味着频繁的创意会议，需要和工程师坐在设计台前就设计理念提供指导和反馈。

无论您选择哪种方法，这种双边协作对两个团队都是有利的。设计师将更好地了解产品技术细节，并评估其设计的哪些部分可以被实施。另一方面，开发团队也能了解到正在进行的工作以及需要哪些准备才能正确执行任务。

尽管设计和开发团队不同，但可以将其视为同一硬币的两面。两个部门有着相同的最终目标：创建一个尽可能为用户服务的产品。最终，产品的外观和感觉，与其功能和性能同等重要。

开发产品是一项团队运动。它需要多学科团队中所有专家的能力来激发创意并持续前进。设计-开发合作是双向的，交接后应继续进行。两个部门需要了解彼此的内部机制，以建立健康的工作动力。毕竟，三个臭皮匠顶一个诸葛亮。

技巧

• 在构思阶段召开设计评审会议。与您的团队一起决定开会频率。通常每周1到2次就够了。

• 在与队友合作时，鼓励分享想法和开放沟通。

• 确定您和您的队友在协作时将使用的工具和软件。每个人都需要信息对齐，并对他们将要使用的工具感到舒适。

• 保持开放心态。事情并不总能按计划进行，限制总在拐角处等待着。准备好使用你所拥有的，并充分利用。

• 准备好妥协——不是消极的意思。在产品开发中，每个团队成员在谈话中都可能输出有效观点，因此，固执己见不会给产品带来任何好处。在出现分歧时，请确保您是在为用户辩护，并确保他们的体验不会被忽视。

• 当涉及到工作和协作流程时——试错是必经之路。尝试和试验不同方法和框架，直到找到最适合您和团队的那一个。

• 请别孤军奋战——您需要有人来帮助您。

二、工程师们想看什么？有意义的可交付物

当涉及到可交付成果及其演示时，一个好的做法是提前考虑您的受众。想想谁将使用您正在创建的交付物，以及哪些内容对他们来说是重要的。设计师的一个常见问题是，把大量时间和精力花在跨功能团队中没人使用的交付物上。如果问自己”为什么”，您得到的最直接答案是——因为它没用。那么，该如何让它有用呢？

让我们退一步，想想设计交接会议是怎样进行的。通常，设计师会展示设计/原型的最终版本，然后解释整体愿景、功能和设计选择。之后，轮到开发团队提出澄清性问题，有时这些问题会变成一整套不确定因素，如：

• 这个返回按钮会跳到哪里？

• 如果用户没有管理员权限会怎么样？他们能看到这个选项吗？

• 如果我们将来引入更多菜单选项会怎么样？我们如何在 UI 中兼容它？

这样您就明白了，有用的设计交付物的关键，是覆盖整个用户/客户体验。但是，我们如何确保设计涵盖一切？说实话，您可能不会覆盖所有用例，尤其是边缘用例，只要弄弄清楚主流程即可。

开发团队是分析型结构。他们依赖信息和事实，对于他们来说，拥有无需解释的可交付物至关重要。为了清楚地理解设计交付物背后的设计理念和基本原理，它需要具体且切中要害。

1. 端到端用户故事

您需要弄清楚的第一件事，是端到端用户故事或设计计划。端到端用户故事的范围比 Jira 的发展故事更广，后者通常针对较大流程中的特定功能或小型任务。它通过为特定用户角色遵循的用例、边缘案例和分步场景提供线索，从而提供整个用户体验的视图。这意味着UX 包含在早期产品概念定义阶段，并确保作品中的功能/产品能够使用户实现其目标。

2. 快乐和不快乐的道路

工程师们正在寻找的另一件事是快乐和不快乐的道路。作为需求收集和 IA 阶段的一部分，在项目开始时就规划可交付物是有好处的。快乐路径可以用作检查表，以查看设计中是否涵盖了所有用例。而不快乐路径通过提供错误状态和替代或恢复行程，来帮助开发产品的错误处理策略。

不用担心，这并不意味着您需要映射设计中的每一个错误状态，只需确保精确定位影响用户任务完成的关键路径即可。

3. 资产和组件

设计交接的另一个重要部分是资产和组件规范。现在，可以通过像 Figma 这样的端到端设计平台来轻松管理。

允许您使用同一工具进行资产交付、线框图和原型设计。组件和资产易于管理，工程师可以直接从设计文件/库中下载。

不要忘记列出组件度量、填充、大小、状态和使用规则，以便开发团队能够明确说明如何开发它们。FigmaTokens 是一个有用的插件，它可以显示边框半径、颜色、间距单位等，并且可以动态更新您的设计。

4. 原型和动画

最后但并非最不重要的是，不要忘记原型和动画（如果有的话）。

在模拟功能或产品开发后的行为时，原型非常有用。这也是测试您的假设和设计假设的好方法。一个好的方法是通过为每个功能制作动态流程，使原型基于功能。您还可以提供有关用户及其角色、假设和场景的一些上下文。这样，您将确保涵盖所有用户用例，并且您已经提前回答了工程师的大部分问题。

5. 技巧

• 尽量不留任何解释——为使用您设计交付物的受众提供足够多的上下文和明确的指导。

• 可以向您的团队询问有关可交付物的反馈，并找出哪些最有用，集中精力提供这些。

• 了解您的产品。作为产品设计师，您有时需要身兼数职并兼顾各种责任。您拥有的跨职能部门的背景越多，您就可以做出更好、更明智的决策。

• 出具需要提供给团队的设计交付品清单，同时制作一些模板，这样，您就可以重复使用并保持一致。

• 明确区分已准备好开发的设计和正在进行的工作。在您使用的设计工具中放置一些状态和信息丰富的缩略图就可以。

三、总结

设计交接不仅仅是敏捷工作流程中的一次性仪式，这是一个协作的过程。设计和开发之间应建立良好的沟通方式，以减少误解和错误。尽管两个团队不同，但他们有共同的目标——那就是有一个有效且有意义的产品。产品目标是通过所有垂直团队的协作努力来实现的。请记住，工作团队就是工作产品。

为实现这一目标，工程师应参与设计流程，设计师应跟进其设计的开发实现，并协助工程团队为开发过程中可能出现的问题创建有意义的解决方案。

原文链接：https://medium.com/vmwaredesign/prepare-for-hand-off-how-to-nail-that-development-support-4317a69e0010

作者 @HitomiBot 翻译

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！