figma开发模式：构建一个对开发人员来说更有用的设计工具

如何在设计工具中为开发人员创建一个家？Dev Mode 团队分享了他们早期从代码生成优先方法的转变、加速他们工作的收购，以及打破交接墙的意义。

即使在早期，我们也希望 Figma 成为产品设计团队的空间，而不仅仅是设计师。Figma 的多人游戏技术将画布扩展到任何拥有链接的人，以便产品经理、开发人员和其他协作者可以共同解决问题，这是我们让所有人都能访问设计的愿景的核心。为此，我们认真倾听用户的意见，提供满足用户需求的功能，同时为他们提供推动工作所需的工具。

桥接设计和代码是我们早在引入开发模式之前就一直在努力的事情。2017 年，Figma 联合创始人兼首席执行官 Dyan Field 介绍了原型设计以及“Figma 2.0”如何简化设计师和开发人员之间的工作流程。

对于开发人员来说，早期就是这种情况。我们看到设计师邀请他们的开发人员同行进入 Figma 来探索正在进行的工作。尽管 Figma 没有完全针对开发人员的工作流程进行优化，但这种共享视图允许他们尝试不同的方法来“移交”文件。我们知道有很多机会可以为 Figma 的开发人员提供更好的体验，因此我们一直在稳步地为他们开发我们的产品。最近，我们推出了 Dev Mode，这是 Figma 中面向开发人员的新工具。

如今，开发人员占我们用户的三分之一。因此，当我们着手构建开发模式时，我们知道我们仍然需要从这些用户那里学到很多关于开发人员工作流程、工具链和偏好的细微差别的知识。“我们与大量开发人员交谈，但这与直觉完全不同，”产品副总裁 Sho Kuwamoto 说。“你必须让自己沉浸在那个世界里。”我们需要一个像设计一样在开发中生活和呼吸的团队，因此在 2021 年，我们收购了 Visly——八位设计师和工程师，他们构建了一个在 React 中开发 UI 组件的工具。Visly 团队带来了数月对开发人员工具的研究和多年的实践经验——换句话说，就是我们一直在寻找的开发人员的“直觉”——这有助于加快我们在 Figma 中为开发人员所做的工作。“很明显，Figma 的每个人都关心开发人员，”Visly 联合创始人 Emil Sjölander 说。“当我们加入时，我们带来了开发人员的观点。”

为每个人制作产品制作设计工具

Visly 团队立即为开发人员如何在各种环境中工作带来了新的视角，并深入了解了他们自己的团队如何使用 Figma。虽然大多数开发人员使用设计工具的体验都遵循类似的弧线——他们通过设计团队的协作被带入 Figma，但他们并不觉得这个工具是为他们“量身定做的”——但 Visly 团队提出了一个关键的反驳：“开发人员不需要担心在 [设计模式] 中学习所有交互，”Joel Miller 说。 Visly 团队的产品设计师。“这更多的是为他们量身定制 Figma 体验。”

该团队着手在 Figma 中创建量身定制的体验，让开发人员成为核心用户，而不是次要用户。他们没有考虑以设计为中心的工具，而是考虑了 Figma 的新功能，例如组件游乐场、代码片段、GitHub 和 Storybook 等应用程序的插件以及特定于开发人员的资源。“我们问自己，'如果设计工具是以开发人员为中心从头开始构建的，它会是什么样子？'”Emil 说。“他们不会生活在设计工具中。

更好、更快地将设计转化为代码

Codegen 是根据一组定义的规则或规范自动生成代码的过程。

尽管方向很明确，但团队仍然需要弄清楚如何在 Figma 中将其变为现实。在早期的迭代中，他们将开发模式想象成一个代码生成工具，认为这将是最实用的方法。“设计越容易转化为代码，迭代速度就越快，”Emil 说。最初，codegen 方向是有效的，当它运行良好时，它可以将项目缩短数小时甚至数天。

在“代码生成（实际上）有什么好处”中阅读更多 Emil 对 codegen 的看法。

但是，让 codegen 在测试场景中工作与让它在现实生活中工作是不同的。团队和公司是独一无二的，具有不同的结构和工作流程。“你假设，'有大公司也有小公司，我明白大公司的需求是什么，小公司的需求是什么，'”埃米尔说。“但 Meta 与富国银行截然不同。他们都是大公司，但他们在截然不同的空间中运营，受到截然不同的限制。从不同的安全需求到不同的代码库结构和成熟度，团队必须了解不同用户需求的细微差别。例如，一些团队使用不适用于生成代码的现有代码，一些设计人员可能会共享更多的手势草图，这些草图并不意味着从字面上翻译成代码。团队还使用语言、平台和内部框架的独特组合，我们无法始终考虑这些因素。

从codegen作为开发模式的主要功能是一个重大的支点。虽然 codegen 可以继续在开发人员的工作流程中发挥重要作用，但实际上将设计转化为代码仍然需要人性化。“我们退后了一步，开始尝试以一种不那么直白的方式将代码翻译成代码，”Emil 说。这意味着通过构建差异支持等功能来更多地关注支持工作流，以便开发人员可以在设计人员将某些内容标记为“准备开发”时在检查设计时比较更改，或者使用 Figma for VS Code 与他们会面，这允许他们查看通知和评论，而无需离开他们的编码环境。

“每个人都希望这个过程感觉像魔术一样——如果你按下一个按钮，它就起作用了，那不是很好吗？现实情况是，这个神奇的按钮并不存在;在这个过程中需要做很多工作，“Sho 说。“我们很少考虑让事情自动化。现在，它是关于公司如何定制从设计到代码的体验，以便它对他们来说尽可能好。

开发人员模式的强大功能

在了解开发人员的独特需求和挑战后，该团队转向了产品体验的另一个关键功能：开发模式的外观和感觉应该是什么样子？“我们可能花了一年半的时间来解决这个问题，”埃米尔说。“我们对此进行了一百万次迭代，全部分散在孤立文件和集成文件之间。”最孤立的版本模仿了传统的交接流程，在这种流程中，抛光的设计从设计到开发并独立构建。在这种情况下，开发人员甚至无权访问原始设计文件。“这是一种静态的世界观，超级孤立，”埃米尔说。在集成方面，开发人员和设计师将使用 Figma 中以开发人员为中心的工具在一个集成空间中共同创造。

为了确定该工具在频谱上的位置，该团队使用了一系列问题来帮助指导这项工作。当信息从设计人员转移到开发人员时：

• 它应该是时间的快照，还是一个活生生的、不断发展的文件的一部分？

• 开发人员是想感觉自己跳进了别人的文件，还是想要自己的体验？

• 专注于单个屏幕有意义吗？

• “交接”文件与设计文件相同吗？

一个想法是创建一个开发文件，这种格式使设计人员能够将相关信息从 Figma 复制到开发人员的专用文档中。另一种方法是专注于逐屏幕界面，类似于 Figma 的当前模式。虽然有帮助，但它还不够丰富，不能成为唯一的景观。该团队最终放弃了“单屏”的方向，因为感觉开发人员从根本上说与设计师处于一个不同的空间。更重要的是，“设计师在画布上布置东西的方式对于理解设计的用户体验和流程至关重要，”Joel说。“你需要把所有的碎片放在一起，而不是孤立地看。

结果呢？一种模式，允许开发人员在设计和开发空间之间切换，而无需完全切换工具或文件。“最初，该模式不是开关;它更接近 Figma 的原型设计功能，您可以在其中以'当前模式'打开，“Joel 说。很快，团队就调整了切换开关，允许开发人员将 Figma 编辑器切换到开发模式。该解决方案使他们能够两全其美——足够孤立，他们可以创建针对开发人员需求进行优化的工具和功能，但作为 Figma 中的一个空间进行集成，以便开发人员从他们的设计同行那里获得重要的背景信息。

打破交接墙

与了解用户需求的细微差别同样重要，该团队希望确保他们也了解团队如何协同工作。“重要的是要考虑开发人员如何摄取信息，同时专注于改善设计师和开发人员之间的沟通和整体工作流程，”Sho 说。毕竟，我们希望从一开始就让开发人员能够协作、迭代和协同工作，而不仅仅是在工作准备好进行开发时。有机会促进整个产品开发过程中的协作。“设计和开发之间是需要最多迭代且缺乏最多协作的关键部分之一，”Emil 说。

如果设计师勾勒出一些在实践中不起作用的东西，那么尽早了解实现挑战会更有帮助。将交接视为持续的对话，而不是一次性的接力棒传递，可以提高迭代速度，进而改进产品。“质量来自迭代，”Emil 说。“开发模式在设计时就考虑到了协作交接，这就是我们认为团队想要的工作方式，”Joel 说。“我们想摆脱这堵交接'墙'。”

这延伸到更广泛的产品开发团队——产品经理、研究人员、营销人员和许多其他人。Emil 说：“产品是由整个产品团队设计的。