4、设计交付：设计标注、切图导出、设计规范文档、与开发协作流程
设计交付，说白了就是设计师和开发之间的「交接棒」。
很多团队死就死在这一步。设计师觉得「我画得这么清楚你看不懂？」开发觉得「这标注跟没有一样，我自己猜吧。」结果呢？还原度一塌糊涂，返工改到吐。
我个人习惯，把设计交付拆成四个核心动作：标注、切图、规范、协作。一个都不能少。
4.1 设计标注：别让开发猜尺寸
标注这件事，我踩过不少坑。早期做项目时，我直接给开发一个 Sketch 源文件，说「你自己量吧」。结果开发量出来的间距跟我设计的差了 2px，整个页面看起来就是不对劲。
后来我学乖了——标注必须明确、完整、无歧义。
4.1.1 标注什么？
- 尺寸标注：元素的宽、高，尤其是图片、按钮、输入框。
- 间距标注：元素之间的 margin、padding，上下左右都要标清楚。
- 字体标注：字号、行高、字重、颜色。别漏了行高，很多开发默认用 1.2 倍，跟你设计稿差很远。
- 颜色标注：十六进制值，或者色板中的命名变量。
- 圆角、阴影、边框：这些细节最容易忽略。
核心原则：标注要「傻瓜化」。假设开发是个刚入职的新人，拿到你的标注就能直接写代码，不需要再问任何人。
4.1.2 用什么工具？
我个人推荐用 Zeplin 或 Figma 的标注功能。Zeplin 可以直接从 Sketch 或 Figma 导入，自动生成标注，开发点一下就能看到尺寸、颜色、字体信息。省时省力。
如果你还在用 PS 手动拉参考线标尺寸……嗯，我建议你赶紧换工具。效率差太多了。
小技巧：标注时把「间距」和「对齐」分开标。间距告诉开发距离多少，对齐告诉开发跟谁对齐。我曾经遇到开发把两个元素居中对齐了，但我要的是左对齐，结果整个布局歪了。
4.2 切图导出：别给开发一张大图
切图这件事，看似简单，其实门道很多。
我记得有一次，我给开发导了一张 2000px 宽的背景图，结果开发说「这图在手机上加载太慢了，你切一下？」我当时就懵了——切图不是应该你来做吗？
后来我明白了：切图是设计师的责任，不是开发的。
4.2.1 切什么？
- 图标、按钮、装饰元素：这些必须单独切出来，不能放在大图里让开发自己抠。
- 背景图、纹理：如果背景是纯色，直接给色值；如果是渐变或图片，切出来并标注平铺方式。
- 多倍图：iOS 需要 @2x、@3x，Android 需要 mdpi、hdpi、xhdpi 等。别只给一张 1x 图。
4.2.2 导出格式怎么选？
| 场景 | 推荐格式 | 说明 |
|---|---|---|
| 图标、简单图形 | SVG | 矢量，无限缩放，文件小。首选。 |
| 照片、复杂渐变 | PNG | 无损，支持透明。注意控制文件大小。 |
| 动画、动态效果 | GIF / APNG | GIF 颜色有限，APNG 更好但兼容性差。 |
| Web 端大量图片 | WebP | 压缩率高，但需要浏览器支持。 |
注意：不要给开发 PSD 源文件让他自己切。开发不是设计师，他可能连图层都找不到。切好图、命名好、打包好，直接给他。
4.2.3 命名规范
切图的命名一定要规范。我见过最离谱的命名是「111.png」「222.png」「最终版.png」……开发拿到手直接崩溃。
我建议用这种格式：模块_元素_状态@倍率.png
例如：home_icon_search_normal@2x.png、home_icon_search_pressed@3x.png
这样开发一看就知道是哪个模块、哪个元素、什么状态。
4.3 设计规范文档：团队的「宪法」
设计规范文档，说白了就是你们团队的「宪法」。所有设计师和开发都得遵守。
我见过很多团队，设计师各画各的，开发各写各的。结果一个页面里用了三种蓝色、四种字号、五种圆角。用户一看就知道这产品不专业。
4.3.1 规范文档包含什么？
- 色彩系统：主色、辅色、中性色、功能色（成功、警告、错误）。每个颜色都要有名称和十六进制值。
- 字体系统：标题、正文、小字、数字。定义字号、行高、字重、字体族。
- 间距系统：4px、8px、12px、16px、24px、32px……定义一套间距倍数，所有元素都按这个来。
- 组件库：按钮、输入框、卡片、弹窗、导航栏……每个组件都要有状态（默认、悬停、点击、禁用）。
- 图标库：统一风格、统一尺寸、统一命名。
核心原则：规范文档要「可执行」。不要写「按钮颜色要好看」这种废话。要写「主按钮背景色 #1890FF，文字白色，圆角 4px，高度 40px」。
4.3.2 用什么工具？
我个人推荐用 Figma 的组件库 或 Storybook。Figma 的组件库可以直接同步给所有设计师，开发也能看到最新的设计规范。Storybook 更适合前端开发，可以直接在浏览器里查看组件和代码。
小技巧：规范文档不是一次写完就完事了。项目迭代过程中，规范也要跟着更新。我习惯每个版本结束后，花半天时间 review 规范，看看有没有需要补充或修改的地方。
4.4 与开发协作流程：别当「甩手掌柜」
设计交付不是把文件丢给开发就完事了。你得跟进、沟通、确认。
我早期犯过一个错误：设计稿交付后，我就去忙下一个项目了。结果开发做出来的东西跟我设计的完全不一样。为什么？因为开发没理解我的意图，自己「发挥」了一下。
从那以后，我定了一个协作流程：
4.4.1 设计评审
设计稿完成后，先内部评审。设计师之间互相挑刺，确保没有低级错误。然后拉上开发一起评审。开发会从技术角度提意见，比如「这个动画效果实现成本太高」「这个布局在低端机上可能卡顿」。这时候就要权衡——是坚持设计，还是妥协技术。
4.4.2 设计交付
评审通过后，正式交付。交付物包括：
- 设计稿（Figma / Sketch 源文件）
- 标注图（Zeplin / Figma 标注）
- 切图（按规范命名、打包）
- 设计规范文档（最新版本）
- 交互说明（动效、转场、状态变化）
4.4.3 开发跟进
开发过程中，设计师要定期检查进度。我一般每周跟开发对一次，看看还原度怎么样。发现问题及时沟通，不要等到最后才说「这里不对」。那时候改起来成本就高了。
4.4.4 验收测试
开发完成后，设计师要做验收测试。对照设计稿，逐像素检查。发现问题就提 bug，开发修复后再验收。直到所有问题都解决，才算交付完成。
注意：验收测试不是走过场。我见过很多设计师验收时随便看一眼就说「没问题」，结果上线后用户吐槽界面丑。设计师要对最终效果负责。
4.5 总结
设计交付这件事，说白了就是「把话说清楚」。标注要清晰，切图要规范，文档要完整，协作要紧密。
我曾经在一个项目里，因为切图命名不规范，导致开发用了错误的图片，上线后才发现。那次事故让我深刻意识到：设计交付不是终点，而是起点。交付的质量，直接决定了产品的还原度。
所以，别偷懒。把每一步做到位，开发会感谢你，用户会认可你。