使用开发模式一年：一位工程经理的10条经验教训

编译整理｜TesterHome社区

作者｜Laurent Thiebault

大家好，我是Laurent Thiebault，在Decathlon（迪卡侬）担任工程经理。在将开发模式融入我们的设计系统工作流程之后，我总结了一些见解，以帮助团队更好地驾驭这个强大的工具。以下是我的主要收获。

当 Figma 在 2023 年配置大会（Config 2023）上宣布开发模式时，我既感兴趣又持怀疑态度。一方面，作为迪卡侬（一家户外和体育用品零售商）的工程经理，我热衷于尝试新工具。另一方面，我见过很多有潜力的工具在真正整合设计和开发工作流程方面不尽人意。然而，经过一年的实践经验，我发现开发模式对我们的团队具有变革性的影响。

其中最突出的功能是代码连接（Code Connect），它极大地提升了我们的设计系统工作流程。通过将 Figma 组件直接链接到我们实际的组件代码，代码连接解决了设计和开发之间在属性对齐、命名规范以及状态管理方面长期存在的挑战。在处理代码结构与设计结构可能不同的复杂组件时，这一点尤其有价值。以下是我学到的关键经验教训：

1. 从小处着手，着眼大局

开发者有他们习惯的工作流程，再增加一个工具可能会令人沮丧。可以理解的是，一些团队成员对认真尝试开发模式犹豫不决。我们没有试图彻底改革我们的工作流程，而是从小处着手，专注于通过 Figma 变量在设计令牌方面取得一些快速的成果。

提示：使用 Figma 的变量别名在设计令牌中建立清晰的层次结构。这种方法通过语义结构便于实现主题化，使团队成员更容易理解和应用系统框架。

变量的作用域功能允许进行精确控制，防止诸如将背景色用于文本或间距值用于边框半径等错误应用。我们已经定制了代码语法，使变量名在不同平台上符合我们开发者的惯例。当我们更新一个颜色令牌时，我们的开发者可以立即看到相应的代码变化。

2. 利用高级检查功能

Flexbox 是一种 CSS 布局模型，它允许你为网页创建灵活且响应式的一维布局。它能够在容器内的项目之间轻松实现对齐和空间分配，即使它们的尺寸未知或动态变化。

开发模式的检查功能显著改善了我们的工作流程，因为它们能够高效地处理复杂布局（包括 Flexbox），并生成既优雅又易于实现的代码。

这些功能使我们的设计系统团队能够深入检查 UI 组件，直接在开发环境中检查诸如 CSS、iOS（SwiftUI、UIKit）或 Android（XML、Compose）样式等属性。通过这种方式，设计师可以确保组件是按照精确的规格构建的。借助 Figma 的 VSCode 扩展，我们可以使用自动补全功能快速浏览 CSS、Compose 或 SwiftUI 的实现。

3. 明确 “完成” 的定义

维护最新的设计系统文档一直是一项挑战。它本身常常感觉像是一份全职工作。根据我的经验，设计意图和具体要求在设计师和开发者之间传递时经常丢失。开发模式的文档和注释功能改变了我们维护和分享信息的方式。

注释允许设计师在文件内直接定义设计属性和其他重要信息。他们可以将自由文本与定义的值（如对齐或尺寸）混合，并快速添加测量值以帮助开发者可视化间距和尺寸。在与开发者合作时，设计师可以直接链接到注释以提高清晰度。

我们已经实施了一个系统，其中每个组件都包含全面的文档：指向 GitHub 源代码、自述文件和相关 playground 的链接。这种方法确保每个团队成员都能持续获取最新信息，并显著减少了搜索相关资源所花费的时间。我们现在有一个规则：如果在 Figma 中没有链接，它就不存在。

代码连接的影响尤其显著。通过将我们实际的组件代码映射到 Figma 组件，我们看到产品团队对设计系统的采用率显著提高。我建议将其纳入每个组件的 “完成定义” 中，以便将正确的代码文档直接链接到设计。

4. 通过插件增强功能

虽然开发模式本身功能强大，但插件使我们能够根据自己的特定需求对其进行定制。以下是一些对我们工作流程有重大影响的插件：

• GitHub 和 Jira 集成：这些插件允许我们将问题和拉取请求直接链接到组件，提高跟踪和实施的准确性。

• Figma for VS Code：这个扩展使我们的开发者能够从 Visual Studio Code 中访问和检查 Figma 设计。
  不要犹豫开发自定义解决方案。我创建了变量转换器插件（Variables Converter），用于将 Figma 变量转换为各种代码格式，目前已有超过 5000 名 Figma 用户使用。

对于更高级的定制，可以探索 Figma REST API。它提供了广泛的自动化和集成能力，特别是与新的变量相关的 API。Figma 变量 GitHub Action Example 仓库展示了如何在 Figma 变量和设计令牌之间建立双向同步，展示了 API 的强大和灵活性。

5. 玩转组件 playground

多变体芯片组件（multi - variant Chip component）在设计系统中就像一个多功能的积木，可以根据不同目的改变形状，从过滤内容到标记项目，同时保持一致的外观和感觉。
开发模式中的组件 playground 是一个用于实验的优秀工具。当选择一个组件或实例时，可以在检查面板中访问它。当我们引入一个新的多变体芯片组件时，使用 playground 允许我们测试各种配置并识别在初始设计中未考虑到的边缘情况。

使用 playground 可以在不改变实际设计的情况下尝试组件的不同属性。

代码连接与组件 playground 无缝集成，当参数调整时实时更新。在我们的案例中，设计中的一个芯片组件在网页开发中转化为三个不同的组件。这种集成使我们能够在修改属性时看到实时的代码更新。

6. 接受版本控制和视觉比较

比较变化的功能对我们的设计系统团队来说是无价的。我们可以轻松跟踪组件随时间的变化，并排比较不同版本，如果需要还可以恢复到以前的迭代。这种能力使我们有信心更快地对设计系统进行迭代，并且与分支配合良好，允许团队并行进行更新而不干扰主系统。

当我们更新按钮组件以提高可访问性时，我们使用视觉比较功能向整个产品组织清晰地传达了这些变化。这种透明度有助于顺利过渡，并增加了对更新的接受度。

7. 聚焦视图精准定位

开发模式的聚焦视图是我们工作流程中使用的另一个强大功能。聚焦视图旨在帮助你聚焦于准备好进行开发的特定设计。通过这个视图，我们可以访问所有开发模式的工具（如检查和插件选项卡），同时对设计有一个清晰、独立的视图。这对于检查单个图层、跟踪特定于设计的版本历史以及确保在将设计标记为完成之前所有必要的变化都已完成特别有用。

当完成我们的按钮组件更新时，这个功能被证明特别有用。聚焦视图使我们能够仔细审查设计，确保没有遗漏任何细节，并促进与开发者的无缝沟通。

8. 培育协作文化

为了最大限度地发挥开发模式的潜力，我们实施了协作会议，设计师和开发者在项目的每个阶段都汇聚在一起。我们在每个项目开始时都进行协作的 FigJam 会议，在那里团队可以自由地起草和完善组件属性、变体和行为。随着想法逐渐成形，无缝过渡到开发模式，利用这个共享空间来可视化进展、统一期望并庆祝里程碑。这种在构思和发展之间的流畅转换不仅打破了部门壁垒，而且确保在整个过程中充分利用每个团队成员的专业知识。

9. 保持迭代思维

我们将开发模式视为我们设计过程的一个动态组成部分，需要定期迭代和改进。随着我们的设计系统演变，我们使用开发模式的方法也在演变。

定期通过诸如季度系统可用性量表（SUS）调查等方法收集反馈。这些评估可以提供关于设计师和开发者如何与你的库交互的有价值见解，帮助识别优秀区域和改进机会。利用这些发现为下一次迭代提供动力，创建一个良性的改进循环。

10. 保持好奇心并持续学习

我们一直在探索开发模式的新功能和更新。紧跟其发展有助于我们不断改进我们的流程。我们投入时间进行培训和个人发展，并将这些元素纳入我们的常规日常工作中。

我鼓励探索 Figma 提供的所有资源，包括文档、网络研讨会和社区论坛。通过致力于持续学习并通过关键绩效指标跟踪我们的进展，我们不断提高我们的技能并适应新的工具和技术。

回顾使用开发模式的一年

经过一年使用开发模式，很明显这个工具显著改善了我们的设计系统工作流程。虽然仍然存在挑战，特别是在处理复杂组件方面，但开发模式弥合设计和开发之间差距的能力使我们的团队更加紧密，从而带来了更具凝聚力和高质量的用户体验。对于在设计系统采用和设计师 - 开发者协作方面存在困难的团队，我建议尝试一下开发模式。从小处着手，准备好应对一些初始挑战，并且不要犹豫根据自己的需求对其进行定制。在一致性、效率和协作方面的潜在好处是显著的。展望未来，我很期待看到开发模式将如何继续塑造我们的设计系统实践。（原文链接：https://www.figma.com/blog/10-lessons-from-an-engineering-manager/）