Figma Config 2023 大会上最大的新闻莫过于 Dev Mode 的推出，这是一个以开发者为中心的界面，为工程师在 Figma 中访问构建产品所需的设计规范提供了全新的体验。自发布以来，很多人一直在问 Dev Mode 和 Zeplin 是否相同。

简短的回答是“否”。

Dev Mode 和 Zeplin 在某些方面有重叠，但它们是功能不同的工具。Zeplin 是一个独立平台，旨在帮助产品团队的所有成员在产品开发生命周期内进行协作。Dev Mode 是 Figma 设计工具中的一个界面，可帮助开发人员查看构建产品所需的一些规格。

为了进一步比较 Zeplin 和 Dev Mode 之间的差异，我们逐点比较了每种工具如何帮助您的团队完成从设计到开发工作流程中的关键步骤：

• 定义哪些设计已准备好进行开发
• 管理和跟踪设计版本
• 组织设计文件以进行设计到开发的协作
• 表面规格和设计系统
• 记录完整的用户旅程

在深入研究比较功能之前，让我们先明确一下 Zeplin 和 Figma 的开发模式是为谁设计的以及为谁设计的。

Figma 是一款设计工具，而 Dev Mode 是该设计工具中的一个界面。它专门用于增强设计工具的功能，以便开发人员可以查看他们需要构建的设计的技术规格。

Zeplin 则是一个协作中心。Zeplin 旨在支持每一位团队成员和利益相关者，帮助他们将产品设计愿景转化为最终产品——包括产品负责人、质量保证、市场营销、法务等。您可以查看可构建的设计、获取技术规格、以结构化和一致性的方式在整个团队中记录设计意图和行为、管理任务和审批等等。

我们还应该指出一个常见的误解，即 Zeplin“只是一个交接工具”。在当今复杂的产品开发工作流程中，传统的交接和瀑布式开发流程已经过时了。Zeplin 专为改进我们称之为“设计交付”的持续设计和开发流程而构建——整个产品团队之间的持续协作对于打造卓越产品至关重要。

如果您有兴趣了解更多有关 Zeplin 的产品理念，请阅读我们的设计交付原则。

现在，开始比较……

目前，大多数 Figma 用户将画布既视为迭代工作区，又视为开发者蓝图。在实际构建时，一个用于两种用途的共享文件会造成混乱，因为团队必须反复沟通要构建哪些设计、在哪里找到它们，以及哪些更改应该或不应该纳入产品中。

开发模式针对这个问题的解决方案是“Ready for dev”（准备开发）按钮，它允许设计师为画布上已准备好构建的部分添加标签。这样一来，开发者就可以在画布上快速浏览这个“Ready for dev”标签，找到他们需要的界面。

存在以下几个挑战：

Figma 中的“Ready for dev”标签并没有完全区分正在进行中的设计和准备构建的设计。它只是在活动、正在进行的画布的子集上贴上标签，然后——如果你有 Dev Mode 的付费席位——你就能够看到这些带标签的设计的视图，从而隐藏文件中可能已经过时的其他页面。

虽然这在正在进行的内容和已准备好开发的内容之间产生了一些区别，但它并不能阻止设计师在部分被标记为准备好开发后对设计进行编辑。

你那套设计图真漂亮，干净利落，可以直接用来制作。如果有人……修改它……那就太可惜了。

Zeplin 的方法承认了一个基本事实：设计师和开发人员的工作流程和需求完全不同。设计师需要一个灵活的空间来迭代设计，而开发人员需要一组可靠的、锁定的设计快照来进行构建。

借助 Zeplin，设计师可以通过将 Figma 中的屏幕发布到 Zeplin 来定义哪些设计已准备好进行开发，这些设计随后会在 Zeplin 中锁定并记录。这些设计与正在进行的设计相互独立，从而避免了混淆和意外更改。

与 Figma 的“准备开发”标签相比，始终存在这样的风险：即使部分内容已被标记为准备开发，设计师仍会继续进行编辑。

那么对于开发人员来说，哪个更好：画布上的标签还是单独空间中的锁定设计？

开发模式以及整个 Figma 中的版本管理都以版本历史记录为中心——文件所有更改的连续自动保存日志（参见下图左侧）。

它的工作原理如下：Figma 会捕捉文件上任何位置所做的所有设计更改，设计师可以为这些日志命名，从而创建不同的版本。这些自动保存功能对设计师来说非常有用，因为他们不会丢失任何设计更改。但请注意，这些自动保存的是整个文件，这意味着 Figma 中没有屏幕版本控制功能。

而且由于文件版本是默认自动生成的，而不是故意捕获的，因此开发人员需要对不相关的版本进行分类。

用户可以有意在 Figma 中保存设计的明确版本，但该过程通常意味着每当设计有新的变化时（包括重命名、设计复制和文件重新组织），都需要进行细致的链接跟踪和文件管理。

开发模式还有一个比较更改选项，这是一个令人兴奋的概念。不过，由于它是基于 Figma 的自动版本历史记录，开发人员很难知道他们实际比较的是哪个版本。

在比较设计时，Figma 用户必须对整个画布所做的每一个更改进行排序，以找到他们想要比较的内容。

Zeplin 的设计版本管理采用了截然不同的方法。Zeplin 并非在文件级别自动保存，而是在屏幕级别捕获预期版本。

Zeplin 中的 Dev Mode 比较变化功能可能会让您想起版本差异，它围绕 Zeplin 独有的两个产品功能构建：锁定屏幕和屏幕级版本。

版本差异记录的是屏幕锁定版本之间的差异，而不是设计更新屏幕过程中进行的迭代更改。而开发模式则会跟踪整个设计画布上所有手动和自动保存的更改，开发者需要自行对更改日志进行分类，找到所需的内容。

假设你的设计师制作了一个新的屏幕版本。在开发模式下，开发人员在导航到正确的部分或比较更改时必须格外小心，不要引用错误的文件版本。相比之下，在 Zeplin 中，开发人员可以快速找到之前的设计屏幕、新的设计屏幕，以及清晰地突出显示在屏幕上的两次提交之间的差异日志。

版本差异仅显示与构建相关的更改。对正在进行的设计所做的任何更改都将保留在设计工具中，这是它们所属的位置。

哪个对开发人员的设计版本控制更有帮助：文件的自动保存还是每个屏幕的有意提交？

设计文件组织在任何设计到开发的工作流程中都扮演着重要的角色，但当你拥有多个开发人员、大量设计或复杂产品时，这一点尤为重要。

Figma 没有标准化的组织系统或文件层级结构，因此团队必须自行开发组织系统。虽然设计师通常都接受这种灵活性（Figma 的魅力之一就在于它的灵活性，不是吗？），但现实情况是，由于 Figma 缺乏跨项目或跨团队的统一组织，其他人的团队协作都会受到影响。

最终会发生一些事情：

• 随着越来越多的设计被添加到无限画布中，文件变得越来越难以导航
• 非设计师必须经常寻求帮助才能找到他们想要的东西
• 当事情变得繁忙，设计师优先处理其他任务而不是管理 Figma 文件时，其他团队成员将依赖过时的设计，从而导致返工

这个无限画布组织得非常好，但是如果没有任何组织基础设施，就无法保证您的团队会像这个一样整齐地组织起来。

设计文件组织是 Zeplin 解决的设计到开发挑战之一，而 Dev Mode 没有解决。

Zeplin 具有内置结构来支持标准化组织，您的团队可以将屏幕排列成逻辑组和标签，以便开发人员（以及所有需要访问设计的人）可以对屏幕进行排序、过滤和搜索，而不必尝试浏览打开的画布。

在 Zeplin 中，屏幕可以按逻辑归档并单独排序为部分和子部分，从而促进异步工作

Zeplin 中的部分不仅仅是视觉边界分组 - 它们是设计文件组织系统的核心部分，您可以在其中创建相关屏幕的类别和子类别。

Zeplin 中的标签功能提供了另一个强大的组织层，支持从设计到开发的工作流程，而这在 Figma 中并非原生功能。您可以创建并添加自定义标签来对屏幕进行分类，或者使用常用标签来标记状态（例如，“已阻止”、“开发就绪”、“已发布”）、受让人和审批状态（例如，“待处理”或“已批准”）。

除了章节和标签之外，Zeplin 还能让您轻松找到所需内容。借助全局搜索功能，您可以搜索整个工作区，找到所需的精确资源，包括屏幕、项目、文本样式、组件，甚至项目注释。

那么，对于开发人员来说，哪种体验更好：DIY Figma 文件组织实践还是跨所有项目和团队的标准化文件组织？

Zeplin 和 Dev Mode 都提供组件值和属性，并允许用户直接从设计中复制它们，因此开发人员只需单击他们正在构建的设计的任何部分即可立即访问其规格。

您还可以使用代码生成插件来呈现设计系统组件的自定义代码。Zeplin 对开发者而言，其强大之处在于能够将所有 UI 库和文档连接并集中到一处：样式指南，让开发者可以轻松找到所需的一切。

在 Zeplin 中，单击某个组件会显示其规格，还会显示大量有关其在项目中的使用情况、其属性以及与团队样式指南的相关性的信息。

因此，当开发人员点击某个设计元素时，他们将能够看到字体、大小、颜色和间距等常用组件规格。他们还可以点击每个值旁边的箭头，查看这些值以及样式指南中随附的任何说明。

通过将样式指南直接集成到设计中，开发者可以查看关键的上下文信息，例如字体层次结构和跨平台的样式变体。组件状态在设计中也清晰可见。

无需离开屏幕即可查找组件状态 - 单个热键快捷键即可显示设计中的组件变体。

组件版本

Zeplin 还提供了对组件版本控制的更多控制，这在您改进设计系统时将发挥巨大的作用。毕竟，设计系统是一个活生生的文档体系，Zeplin 可以帮助您在所有团队之间传递有关如何以及何时更新设计系统的信息，以便您能够齐心协力，共同实现设计系统的采用目标。

许多产品团队面临的另一个难题是难以完整传达整个用户旅程的设计意图。仅仅让开发人员查看一些屏幕、提供一些文档和规格说明是不够的——他们还需要了解用户在产品中移动的“整体情况”。

在 Figma 中，创建用户流程的主要方式是直接在设计画布上绘制，或者直接进行原型设计。在画布上，设计师可以使用手动绘制的形状来创建单独的流程图来表示屏幕，或者构建一个原型来尽可能地展现最佳路径。对于任何包含多个条件路径的产品来说，这很快就会变得难以管理。

Figma 引入了一种创建原型流程的新方法，但是当涉及到用户旅程时，除了最简单的流程之外的任何流程都会很快变成意大利面条。

Zeplin 的 Flows 功能使设计人员能够使用实际的设计屏幕来映射完整的用户流程，从而为开发人员提供全面的用户体验图景，而不仅仅是参考的快乐路径。您还可以直接从 Zeplin 中的任何流程点击进入屏幕，这意味着所有相关信息（属性、值和行为）都会显示在单个屏幕的上下文中以及更广泛的用户流程图中。

Zeplin 的 Flows 功能让设计师能够构建清晰、全面的用户旅程，方便开发人员轻松浏览。

当所有功能都连接起来并处于正确的上下文中时，开发人员不太可能误解 Zeplin 中预期的用户旅程。如果他们有疑问，可以直接在屏幕或用户流程中使用评论进行提问。

Figma 可以用于设计协作吗？当然可以。如果你的项目规模较小，截止日期比较宽松，那么在 Figma 的开发模式下完成所有工作应该就足够了。开发模式和 Zeplin 都提供了设计规范和设计系统信息（不过 Zeplin 将其更紧密地集成到开发工作流程中）。

但是，当你的产品体验至关重要，并且精准度和效率是组织优先考虑的因素时，厨房里（或者画布上）人手过多，就会导致混乱、头痛和延误。相比 Figma，开发者模式确实为开发者提供了更大的喘息空间，但它仍然是设计师专属的模式。

而 Zeplin 则专为您的团队将产品设计愿景转化为大规模优秀产品过程中的复杂过程而设计。相比之下，Zeplin 在以下方面比 Dev Mode 提供了更多功能：

• 明确要构建的内容，将准备构建的屏幕与正在进行的设计分开
• 设计版本控制 - 具有屏幕级版本跟踪和类似 Git 的提交
• 设计文件组织的标准化和一致性
• 记录和集中设计行为、用户流程和产品需求

想了解更多？您可以与团队成员讨论 Zeplin 如何为您的团队服务，或者试用 Zeplin 30 天，亲自体验一下。