许多持久的开发问题隐藏在“就是这样”的背后。这些是感觉本质上就很慢的流程，总是需要过度沟通的步骤，以及不可避免地有时顺利有时不顺的工作流程。

人们感到沮丧，但很难退一步说，“我们可以怎么做得更好？”当流程足够好用时，很难认识到流程可以从“足够好”变得很优秀。

这就引出了设计交接。

当设计师完成设计并将设计规范交给开发团队构建时，经常会产生相互的挫败感。设计团队担心开发团队无法实现他们的愿景，而开发团队担心为了确保他们实际构建的是所需的东西，需要进行大量的来回沟通。

思想领袖和供应商有关于“设计运营”或完全消除交接的想法，但我们首先希望专注于相互理解。许多设计交接问题源于设计师往往不知道开发人员想要什么。因此，我们花时间询问了他们。

开发人员在接收设计时会遇到哪些痛点？

对于 Donnie D’Amato，Design Systems House 的创始人和首席架构师来说，设计交接往往会立即产生摩擦，因为工作意义在过程中丢失了。很少有足够的上下文，他总是有问题：“我做这项工作的目的是什么？为什么我们决定朝这个方向走，而不是显然正确的方向？”

设计师，可能无意中，让开发人员感觉像只是接单并按指示操作的短订单厨师。D’Amato 说：“有时，我觉得我们被排除在外。作为开发人员，我们不知道这个设计来自哪里。”

当开发人员被排除在外时，很难将上下文反馈给设计师。

Daniel Vaughn，NextEra Mobility 的高级平台工程师，解释了在UI经过初始状态后考虑每种变化是多么繁琐。“交接可能会向我展示1280px和480px屏宽的布局，但我不知道布局在它们之间的变化方式，”他说。“或者交接可能会向我展示如何设置博客文章标题的样式，但没有说明当标题长于其容器的宽度时会发生什么。是换行还是用省略号截断？”

这种繁琐比最初看起来的问题更大。当效率低下时，士气可能会下降，开发人员越是即兴填补空白，设计师对结果不满意的可能性就越大。

Invision 的工程师 Ben Nadel 解释说，设计通常“不会说明设计某个功能的原因，或在过程中考虑的权衡，或客户当前正经历的真正痛点。”他写道，工程师“在过程中不得不做出很多有依据的决定”，而他们“没有所有事实就无法做出有依据的决定。”

开发人员希望设计师对设计交接中的开发方面有更好的理解？

在设计交接前后有很多希望。设计师希望开发人员拥有所需的所有信息，开发人员希望设计师在构建这些设计时考虑他们的需求。

然而，理想的交接不应依赖于希望——设计师应该确切知道开发人员需要什么，或者知道要问哪些问题以确定这些需求。

对于 Vaughn 来说，他希望设计师更好地理解的主要事情是好的交接全在细节上。“对我们来说，” Vaughn 说，“具体细节是最重要的。十六进制值、图像资产、像素尺寸——交接只需包含这些细节，我们仍然能够正确实现设计。”

“设计师越了解开发，即使只是小部分，越有益。”

• Donnie D’Amato, Design Systems House 的创始人和首席架构师

开发人员读到这里可能会回应：“当然！”但设计师并不总是觉得这种细粒度是直观的，因为他们中的许多人不编写代码。

关于这个主题有热烈的讨论——有些人认为设计师应该是熟练的程序员，有些人认为设计师应该专注于他们的专业，还有一些人介于两者之间。

然而，D’Amato 的论点很简单：“理解艺术或设计媒介的人比不理解的人做得更好。”就像画家需要知道选择哪种颜料以及每种颜料将如何影响他们的画布，设计师也需要对手头的材料和资源有所了解。

也就是说，设计师不需要是专业级别的程序员。正如 D’Amato 所说，“设计师对开发了解得越多，即使只是小部分，也越有益。”

通过对代码有一点了解，设计师可以更好地理解开发人员需要什么，并且更好地看到每个设计和代码更改如何链接到一个更大的图景。从这个角度来看，设计师可以从有时将开发人员视为扫兴的人转变为将他们视为系统思考者。

“这并不是说我们不想做那些酷炫的、有趣的东西，” D’Amato 解释道。“这是一个系统地思考事物的问题。这就是开发人员所做的。”

当开发人员收到一个雄心勃勃或复杂的设计时，他们必须同时考虑构建和维护它。设计师可能在前者方面考虑周到，但在后者方面则不然。

例如，如果一个设计师想在同一页面上加载六种不同的字体，开发人员可能会支持这个酷炫的设计，但对性能影响持怀疑态度。“页面加载的字体越多，你需要为不同的资产发出的请求就越多，页面就越重，” D’Amato 说。

通过了解细节、代码和系统思维，设计师可以更好地理解开发人员试图达到的平衡。“你总是必须注意平衡，” D’Amato 说，“我希望设计师理解我们正在尝试的就是这种平衡。”

使用设计工具时，开发人员的体验如何？

当人们批评设计交接体验时，他们往往关注设计师和开发人员之间的沟通，但这种沟通中的许多问题被工具所阻碍。

即使是通常是设计团队默认选择的 Figma，也只是在2024年1月引入了开发模式。这不是对公司或工具的批评，而是一个例子，说明设计师经常尝试在工具不是真正为此目的而设计的情况下将设计交给开发人员。

Vaughn 直言不讳地说，“我认识的大多数开发人员在使用设计工具时都不太舒服。”因此，他说，“我不确定我是否曾有过一次交接，我在导航交接工件时感到完全舒服。”

开发人员经常迷失在设计文件的荆棘丛中，难以确定何时该参考哪个文件。Vaughn 认为，“设计工具应该赋予设计师明确区分‘真相来源’和‘虚假来源’的能力，即固有于创意过程中的大量小实验和草稿。”

这是一个重要的瓶颈。开发人员不是这些设计工具的主要用户，但如果在交接开始时工作停滞不前，那么工具就没有发挥作用。毕竟，目标是构建产品，而不是设计。

D’Amato 明确表示，开发人员在这方面也有一些工作要做。“开发人员需要能够浏览文件。他们需要能够看到即将构建的内容和他们需要了解的规范以正确构建它。”

Vaughn 进一步类比，“如果建筑师在 CAD 中建造了一些东西，并将其打印成蓝图并交给施工人员，施工人员不需要知道如何使用 CAD 才能完成工作。”

“我在设计工具中不舒服，这是正常的，” Vaughn 解释道。“你应该知道如何浏览 Figma。你应该知道如何放大和缩小。你应该能够发表评论。”

设计师和开发人员越能在中间见面，交流他们的需求和工具熟悉度，就越能弥补沟通或经验上的差距。

什么是理想的设计交接？

设计和开发团队越了解对方的需求，就越能开始讨论什么是一个真正伟大的设计交接。

对于 Vaughn 来说，理想的设计交接过程是一个“使开发人员能够尽可能少的劳动力忠实地实现设计师的愿景”的过程。虽然目标是方程两边的赋权，但实现这一目标的过程不需要过于繁重或复杂。正如 Vaughn 所说，“过程应该尽可能隐形。”

他将其比作一个有效的 CI/CD 系统，该系统允许开发人员进行更改并信任这些更改会自动测试和部署，而几乎不需要手

动干预。这种自动化和信任的程度是理想的设计交接的关键。

一个好的设计交接能让开发人员感觉他们有足够的上下文来做出明智的决定，并确保他们构建的东西符合设计师的期望。

D’Amato 强调，设计交接应该是一个对话，而不仅仅是一个单方面的传递。他建议设计师和开发人员一起工作，从而确保开发人员理解设计的意图，并能够提出他们的疑虑或建议。

设计师和开发人员之间的这种协作和沟通不仅可以提高设计交接的效率，还可以增强双方的信任和理解，从而最终导致更好的产品。

结论

设计交接是设计师和开发人员之间的关键环节，它影响到最终产品的质量和团队的工作效率。通过了解彼此的需求和挑战，并通过改进沟通和工具使用，设计师和开发人员可以共同创造更好的设计交接体验，最终提高产品的质量和用户体验。