星期二早上 8:00，一位开发人员给你发来消息。他们刚刚花了四个小时编写一个弹窗组件的代码，却突然发现自己是根据一个名为 "Exploration_v3_temp" 的草稿页面开发的，而不是最终定稿的版本。
当我们把交付当成一种“驱逐通知”时，这种情况就会发生。我们打包好设计，把它们扔过围墙，然后寄希望于工程团队自己去搞清楚。在 Northwind Studio，我们很早就意识到，混乱的 Figma 文件就是一份迟早要偿还的债务。如果你的开发人员害怕打开你的链接，那么是时候改变你构建和交付文件的方式了。
交付是一场对话，而不是单向投递
把设计稿扔过墙并假定自己的工作已经完成，是导致布局错乱和沟通受挫的根源。优秀的交付不会在冲刺结束时的一次会议中凭空发生。只有当设计和工程从第一天起就建立起共同语言时，它才会实现。
当我们启动一个项目时，甚至在还没有高保真原型之前，我们就会把开发人员拉进文件里。我们希望他们看到线框图——对布局逻辑提出疑问，并尽早指出潜在的技术障碍。这种持续的合作意味着，当我们正式交付文件时，开发人员已经知道该应用程序应该如何运行。他们已经对那些棘手的交互给出了反馈。他们确切地知道在哪里可以找到唯一可信源。
为人类视觉组织你的 Figma 文件
开发人员应该能够在打开你的 Figma 文件后，在五秒钟内了解每个屏幕的状态。如果他们必须去猜测哪个框架是准备好构建的，哪个是半成品的头脑风暴，那么这个系统就是失效的。
我们用清晰、可预测的页面结构来组织 Figma 的侧边栏。我们使用 emoji 作为视觉路标，将进行中的工作与已批准的规范区分开来。
以下是我们组织典型项目文件的一个实际示例：
--- 🟢 READY FOR DEV ---💻 Desktop - Dashboard📱 Mobile - Dashboard--- 🟡 IN PROGRESS ---🧪 Layout Explorations🎨 Brand Assets & Moodboards--- 🔴 ARCHIVE ---📦 Old Iterations
在 "Ready for Dev" 页面中，我们按照用户流程，从左到右、从上到下组织框架。我们还使用 Figma 的 Section 工具将相关的屏幕组合在一起，并将整个区域标记为 "Ready for development" 状态徽章。这个简单的视觉提示告诉开发人员，这些设计已经锁定，可以安全构建。
像开发人员一样命名组件，而不是像艺术家
如果你的 Figma 文件中充斥着名为 "Group 412"、"Rectangle 12" 或 "Button-New-Final-v2" 的图层，你就是在让开发人员做他们本不该做的翻译工作。你的设计组件应该镜像实际代码库的结构。
不要根据元素的外观来命名，而是要根据它们的功能和所处的位置来命名。使用与现代前端框架一致的、系统化的、用斜杠分隔的命名规范。
例如，不要将一个按钮变体命名为 Red-Button-Large。相反，使用结构化的命名系统：
Button / Primary / Danger / Large
当你使用结构化命名和 Figma 的组件属性（Component Properties）时，你就与工程团队使用了相同的语言。当开发人员检查组件时，他们会看到直接映射到其 React 或 Vue props 的属性。这消除了猜测，并保持了设计文件与线上应用之间 UI 的一致性。
知道什么不需要过度死磕
静态设计是一种幻觉。网页不是海报——它会根据用户的视口、浏览器设置和字体偏好进行拉伸、收缩和重排。如果你花几个小时在静态的 1440px 框架上微调单个像素值，你就是在把时间浪费在上线后就会失效的细节上。
与其死磕静态框架的像素，不如专注于定义系统的规则。
- 一切皆用自动布局 (Auto-layout)： 不要手动绘制按钮或卡片的边框。使用 Figma 的自动布局来定义内边距 (padding)、间距 (gap) 和对齐方式。如果按钮的标签从 "Submit" 变为 "Create Account"，按钮应该会自动变宽。
- 定义约束和调整大小规则： 向开发人员展示当屏幕尺寸变化时，元素应该如何表现。卡片是应该填满容器，还是保持固定宽度？
- 记录边缘情况： 当文本内容比预期多出三行时，文本块会发生什么？是用省略号截断，还是将下方的推开？设计师应该设计系统的行为，而不仅仅是它的理想状态。
用设计 Token 说同一种语言
设计与工程之间最常见的摩擦源于任意值的使用。如果一个屏幕使用 #F3F4F6 背景，而另一个屏幕使用 #F9FAFB，仅仅是因为设计师使用了吸色工具，代码库很快就会变得臃肿且不一致。
设计 Token (Design Tokens) 通过将原始十六进制代码、字体大小和像素值替换为命名变量来解决这个问题。你不需要告诉开发人员在链接中使用 #3B82F6，而是告诉他们使用 Token color-brand-primary。
我们的设计系统直接在文件中包含开发就绪的 Token，确保 Figma 中的变量直接映射到代码库中的 CSS 变量。这种方法确保了如果你需要更新品牌的主色，你只需在一个中心 Token 文件中进行更改。更新将自动同步到设计库和线上网站，无需手动更新代码。
建立明确的边界和反馈循环
即使有完美的文件结构和强大的 Token 系统，在构建阶段仍然会出现问题。你需要一个清晰的流程来处理反馈和后期修改，而不会在代码库中引起混乱。
一旦设计被移动到 "Ready for Dev" 部分，我们就建立起严格的“冻结”规则。如果客户在开发期间要求修改，我们不会直接编辑现有的交付框架。相反，我们会将该框架复制到 "In Progress" 部分，进行调整，并首先与开发人员一起评估修改。通过后，我们再替换框架，并在版本日志或简单的 Figma 评论中记录这一更改。
使用 Figma 的开发模式 (Dev Mode) 也能帮助开发人员检查布局、测量距离并复制 CSS 代码，而不会意外移动图层或更改字重。通过尊重这些边界，你可以保护开发人员的专注力，并确保最终产品看起来与定稿的设计完全一致。
我们相信，优秀的设计系统取决于它们被构建得有多好，而不仅仅是在演示中看起来有多美。如果你想优化团队的设计流程，并构建一个工程团队乐于使用的凝聚力视觉系统，我们可以帮助你搭建起实现这一目标的结构、Token 和工作流。
常见问题
如何在不设计每个屏幕尺寸的情况下处理响应式设计规范？
你不需要为每个视口都做设计。相反，设计最小和最大的断点，使用 Figma 的自动布局来演示元素如何拉伸或收缩，并记录中等屏幕尺寸下的折行行为。
在 Figma 中将设计标记为“准备好开发”的最佳方式是什么？
在 Figma 文件中使用专门的 "Ready for Dev" 区域或页面，并使用 Figma 内置的状态徽章标记已批准的框架。千万不要让开发人员从包含活跃草稿或探索方案的页面中进行构建。
设计师是否应该学习代码以改善交付流程？
设计师不需要编写生产环境的代码，但必须了解浏览器的工作原理。了解 CSS 盒模型、Flexbox 和 Grid 的基础知识有助于你设计出技术上可行且易于构建的布局。
如何为开发人员记录微交互和动画？
使用 Figma 原型来展示流程，并辅以书面规范或简单的屏幕录像。记录具体的过渡曲线、延迟和触发状态，这样开发人员就不必去猜测动画数值。