Figma 与生产之间的差距：为何交付失败以及设计系统如何解决

Source: Dev.to

Source: …

设计师‑开发者之间的鸿沟

你一定有这种感觉。过去两周，你在 Figma 中精心打磨了一个新功能：

• 自动布局已经完美。
• 组件状态被细致地组织好。
• 甚至已经为微交互做了原型，准确展示了下拉菜单应该如何弹出。

你满怀自豪，甚至有点兴奋地把它交给工程团队。

现实

两次冲刺后，你在预发布环境中看到实现效果：

• 字体粗细 错误。
• 内边距 不一致。
• 你花了一个小时完善的 悬停状态 完全消失。
• 那个下拉菜单？它直接瞬间出现，根本没有动画。

你提交工单，或在 Slack 上发送带有截图并用红圈标注问题的消息。开发者回复：

“哦，我们使用的库不支持那个动画，”
“我在文件里没看到那个状态。”

感觉自己的工作被扔过墙，途中被弄乱，最后由只能看到你原始设计模糊传真图的人重新构建。

双方为何都感到沮丧

• 设计师 感觉自己像“像素警察”，不断挑剔间距和颜色，渴望拥有技术词汇——或者直接拥有实现的技能。
• 开发者 收到的是静态的动态界面图片。他们必须猜测布局在不同屏幕尺寸下的响应方式，或在数据未加载时会怎样。每个设计文件看起来都有所不同，迫使他们编写临时的 hack 代码，只为把工单交付完成。

问题不在于设计师不会编码，也不在于开发者缺乏审美。问题在于我们在说两种不同的语言。

弥合差距

本文讨论如何超越 handoff 模式，采用设计与代码共享 single source of truth 的工作流。我们将探讨如何构建一个不仅仅是 Figma 贴纸集的设计系统，而是一个工程师真正信赖的可投产库。

传统线性工作流

1. Design happens → stops.
   设计 完成 → 停止。
2. Development starts → ships.
   开发 开始 → 发布。
3. The handoff is the baton pass.
   交接 就是接力棒的传递。

在现代网页开发中，这种模型根本失效。

Why? Because a Figma file is not the truth. It’s a picture of the truth.
为什么？ 因为 Figma 文件并非真实，它只是一幅真实的图像。

在 Figma 中，你可以：

• Detach an instance.
  分离实例。
• Tweak a hex code manually.
  手动微调十六进制颜色码。
• Drag a button two pixels to the right.
  将按钮向右拖动两个像素。

所有这些都不改变底层系统。而浏览器却毫不宽容，它要求逻辑、结构和系统化的规则。

当你把设计系统仅仅视作设计产物时，就会出现 drift——实时产品会逐渐偏离设计文件，因为：

• Developers make undocumented decisions.
  开发者做出未记录的决定。
• Designers make changes that never make it into the code repository.
  设计师进行的更改从未进入代码仓库。

结果如何？代码库充斥着 magic numbers（随意的像素值），而设计团队则感到自己的工作被轻视。

重新思考设计系统

将设计系统视为一个 product，服务于两个客户：

1. Designers using it to prototype.
   设计师 用它来做原型。
2. Developers using it to ship features.
   开发者 用它来交付功能。

介绍设计工程

你不需要成为全栈工程师，但必须了解 UI 如何进入浏览器。

将静态库转化为功能系统的蓝图

1. 建立共享词汇表

• 当前状态：

  • 颜色仅仅是十六进制代码。
  • #0052CC = “Primary Blue”（设计师） vs. 一串字符（开发者）。

• 问题：

  • 如果下个月把这蓝色调暗，开发者必须逐个查找并替换所有十六进制代码——很容易遗漏，导致不一致。

• 解决方案 – 设计令牌（Design Tokens）：

  • 为数值分配 语义化名称。
  • 示例：color-action-primary、spacing-md。

结果： 在 Figma 中编辑一个值 → 脚本自动更新代码仓库中的 CSS 变量或 JSON 文件。
转变： 停止使用原始数值进行设计；改用 意图 进行设计（例如 “标准容器间距” 而不是 “16 px 填充”）。

2. 对齐设计与代码结构

• 摩擦点： 设计师思考 “页面”，开发者思考 “组件”。

• 示例：

  • 设计师创建一个 用户资料卡。
  • 开发者看到 头像、排版、按钮变体 和 容器。

• 问题：

  • Figma 按钮组件有属性 “Type” (Primary/Secondary)。
  • React 组件期望的 prop 为 variant (filled/outlined)。

• 解决方案： 对齐 API（应用程序编程接口）。

  • 设计师将变体结构化以匹配 React 的 props。
  • 开发者构建足够灵活的组件，以在不需要覆盖的情况下处理设计意图。

转变： 设计师学习镜像代码命名；开发者提供清晰、一致的 props。

3. 在开发者工作地点编写文档

大多数设计系统文档最终沦为 墓地（PDF 或陈旧的 Confluence 页面）。
优秀的文档应存在于开发者工作的地方——例如 Storybook。

• 在隔离环境中查看已编码的组件。
• 组件在浏览器中实际表现的唯一真实来源。
• 从代码生成的文档不可能撒谎；废弃的 props 会自动消失。

给设计师： 在 Markdown（或 MDX）中为组件故事一起贡献文档。

综合运用

1. 创建一个令牌管道，将 Figma 同步到代码。
2. 组织 Figma 文件，以反映代码库中使用的组件层级和命名。
3. 在 Storybook 中记录组件，使用 Markdown/MDX 编写设计说明、使用指南和视觉示例。
4. 协作迭代：设计师在 Figma 中微调令牌；开发者即时在实时组件库中看到更改。

当设计和代码共享同一真实来源时，“交付”变成了 动手协作，设计师与开发者之间的差距会显著缩小。

为什么 MDX 是超级力量

MDX 让你可以在开发者复制的代码示例旁边直接编写使用指南（例如，“每页不要使用一次以上的主按钮”）。

设计师的担忧：Git、终端与版本管理

• Figma 有版本历史，但常常混乱。
• Git 提供了一种结构化的方式来提出更改、审查并合并它们。

想象一下这个工作流

1. 设计师想要更新图标集。
2. 与其发送 ZIP 文件，他们在系统中创建一个 分支。
3. 他们更新资产并提交一个 拉取请求。
4. 开发者审查后，自动化测试运行，变更合并。

这就是 治理。它回答：

• 谁被允许更改系统？
• 我们如何进行版本管理，以免破坏旧产品？
• 我们如何传达更改？

转变

从 “我更新了 Figma 文件，希望你能看到” → “我发布了系统的 v1.2.0 版本。”

如果你是一名设计师，心里想着 “我报名是来设计的，而不是写 JSON 和管理 Git 分支的”， 那这是一个合理的担忧。

行业正在转变

当今最有价值的设计师能够 弥合 设计与工程之间的差距。他们通常被称为：

• 设计工程师
• 设计系统负责人

当你了解前端是如何工作的，你就不再设计那些不可能实现或成本高昂的东西。你会开始设计 可扩展的系统，从而赢得工程师的尊重，因为你交付的是解决方案——而不仅仅是图片。

这种专业能力将中级设计师与高级或资深设计师区分开来。
这就是收入从 85 千美元 到 130 千美元以上 的差距。

前端开发者

掌握等式的这一侧同样强大：

• 你不再是“接票员”。
• 你成为产品过程中的 合作伙伴。
• 你可以在写下任何代码之前捕捉到用户体验问题，因为你理解设计意图。
• 你成为设计师们喜欢合作的工程师。

课程介绍

从 Figma 到生产：构建开发者真正使用的设计系统

我创建这门课程是因为在一次又一次的团队中看到同样的脱节。这不仅仅是把漂亮的组件做在 Figma 里或编写 React 组件——更重要的是把它们粘合在一起的纽带。

6 周学习内容

成果： 完成后你将拥有一个已发布的 npm 包、一个文档站点，以及一个作品集案例，向招聘经理展示：“我不仅仅是设计稿，我还能交付系统。”

适合对象

1. 沮丧的产品设计师 – 想要了解决策背后的原因，创建直观的组件 API，并转型为设计‑工程师角色。
2. 对设计充满好奇的前端开发者 – 想学习设计方面的知识，使用与设计师相同的语言，并成为产品开发中的真正合作伙伴。

为什么重要

设计与开发之间的鸿沟是：

• 产品夭折
• Bug 诞生
• 时间线爆炸
• 团队燃尽

但这也是 最大的职业机会。

如果你成为搭建桥梁的人——理解 tokens、governance 和 component architecture——你就会变得 不可或缺。你不再与工具和队友争执，而是开始构建外观和功能都完全符合预期的东西。

准备好停止把设计扔到墙那边了吗？

让我们一起构建真实的东西。

立即报名：
从 Figma 到生产：构建开发者真正使用的设计系统 → (link to enrollment)