视觉交付基础：设计规范、组件库、设计系统与交付物类型
在UI视觉交付链路中，设计师交付的绝不仅仅是“一张好看的图”。开发团队能否高效还原、测试团队能否精准验收、产品迭代能否保持一致性，都取决于视觉交付物的标准化程度。本章聚焦视觉交付的四大基础认知——设计规范、组件库、设计系统、交付物类型，帮助学员建立从“设计产出”到“工程落地”之间的桥梁思维。
2.1 设计规范：视觉一致性的基石
核心原理：设计规范是视觉交付的“宪法”，它定义了产品界面中所有视觉元素的使用规则。规范不是设计稿的附属品，而是独立于具体页面之外的、可长期维护的视觉标准文档。它回答的是“我们的产品看起来应该是什么样”以及“为什么这样设计”这两个根本问题。
设计规范的核心构成：
| 规范维度 | 包含内容 | 典型示例 |
|---|---|---|
| 色彩系统 | 主色、辅助色、功能色、中性色、渐变色 | 主色 #1677FF，成功 #52C41A，警告 #FAAD14 |
| 字体系统 | 字体族、字号阶梯、字重、行高、字间距 | PingFang SC，14px/22px，Medium 字重 |
| 间距系统 | 基础间距单位、间距阶梯、栅格规则 | 4px 基准，8/12/16/24/32/40 阶梯 |
| 圆角与边框 | 圆角等级、边框宽度、边框样式 | 小圆角 4px，中圆角 8px，大圆角 16px |
| 阴影与层级 | 阴影等级、透明度、模糊半径、扩展方向 | 卡片阴影 0 2px 8px rgba(0,0,0,0.08) |
| 图标规范 | 图标尺寸、笔画粗细、视觉重量、网格对齐 | 24px 基准，2px 笔画，统一圆角端点 |
判断方法：评估一份设计规范是否合格，可以从三个维度检验：完备性——是否覆盖了产品中所有高频视觉元素；可执行性——开发人员能否不依赖设计师解释直接按规范编码；可维护性——当业务扩展时，规范能否平滑扩展而非推翻重来。
2.2 组件库：从“画页面”到“搭积木”
核心原理：组件库是将设计规范实例化的产物，它把按钮、输入框、弹窗、导航等高频UI元素封装为可复用的代码组件或设计组件。组件库的价值在于：一次设计、多处复用；统一交互、降低认知成本；批量修改、提升迭代效率。
组件库的分层结构：
- 基础组件：按钮、输入框、单选框、复选框、下拉选择器、标签、提示条等原子级元素。
- 复合组件：搜索栏、筛选面板、分页器、步骤条、表单校验、日期选择器等由多个基础组件组合而成的中粒度组件。
- 业务组件：用户卡片、订单状态标签、数据统计块、审批流程条等与具体业务场景绑定的高阶组件。
操作流程：组件库的搭建应遵循“从下而上”的路径。首先梳理现有页面中重复出现的UI元素，统计出现频次；然后对高频元素进行抽象和归纳，去除不必要的样式差异；接着按照设计规范统一视觉表现；最后封装为组件并编写使用文档。组件入库前必须经过设计评审和技术评审双重把关。
2.3 设计系统：规范、组件与流程的有机整体
核心原理：设计系统不是“设计规范 + 组件库”的简单叠加，而是将设计原则、视觉规范、组件实现、使用文档、代码示例、版本管理、贡献机制整合为一个完整的生态系统。设计系统解决的是“多人协作时如何保持一致性”和“产品演进时如何有序迭代”这两个组织级问题。
设计系统的成熟度模型：
| 成熟度等级 | 特征描述 | 组织表现 |
|---|---|---|
| L1 无序阶段 | 无规范、无组件库，每个设计师按个人风格输出 | 页面风格割裂，开发返工率高 |
| L2 规范阶段 | 有设计规范文档，但组件化程度低 | 视觉基本统一，但开发效率提升有限 |
| L3 组件阶段 | 有可用的组件库，设计规范与组件对应 | 开发效率明显提升，但跨团队复用仍困难 |
| L4 系统阶段 | 设计系统完整运作，有治理机制和反馈闭环 | 多产品线共用一套系统，迭代有序 |
| L5 生态阶段 | 设计系统对外开放，支持插件、主题定制 | 形成内部开源文化，驱动行业标准 |
判断方法：评估一个团队的设计系统成熟度，可以观察三个信号：新页面上线时，设计师是否还需要从零开始画基础组件；跨团队协作时，不同项目组是否使用同一套组件命名和版本；设计变更时，修改一个全局颜色变量能否自动同步到所有相关页面和代码。
2.4 交付物类型：切图、标注、动效与原型
核心原理：视觉交付物是设计师与开发、测试之间的“契约文件”。不同类型的交付物承载不同的信息维度：切图解决“用什么资源”，标注解决“怎么摆放”，动效解决“如何变化”，原型解决“整体流程”。四者缺一不可，共同构成完整的视觉交付包。
各类交付物的详细说明：
| 交付物类型 | 核心内容 | 格式/工具 | 验收要点 |
|---|---|---|---|
| 切图 | 图标、图片、背景纹理、插画等静态资源 | PNG、SVG、WebP、Base64 | 尺寸是否为偶数倍、是否包含@2x/@3x、透明背景是否正确 |
| 标注 | 尺寸、间距、颜色、字体、圆角、阴影等参数 | Zeplin、Figma Inspect、Markly | 标注是否完整覆盖所有状态、是否包含Hover/Active/Disabled |
| 动效 | 过渡动画、微交互、加载反馈、页面转场 | After Effects、Principle、Lottie | 时长是否合理（200-400ms）、缓动曲线是否明确、是否提供可用的导出文件 |
| 原型 | 可交互的页面流程、状态跳转、逻辑演示 | Figma、Axure、ProtoPie | 是否覆盖主流程和异常分支、交互逻辑是否与PRD一致 |
操作流程：标准视觉交付包的输出顺序应为：先完成设计规范核对 → 再输出标注图 → 同步导出切图资源 → 制作动效演示 → 最后组装可交互原型。每个环节都要经过自检和互检，确保交付物之间没有信息冲突。
login_input_icon_default_24x24.png。避免使用“未命名-1.png”“最终版.png”这类无法追溯的命名。同时，所有切图资源应统一存放在项目的 assets 目录下，按模块分子文件夹管理。
2.5 交付物验收清单与质量复盘
核心原理：视觉交付的终点不是“设计师提交文件”，而是“开发还原度达标”。建立标准化的验收清单，可以大幅减少设计、开发、测试三方之间的沟通成本。验收清单应覆盖视觉还原的各个维度，并且每个维度都要有可量化的指标。
视觉交付验收清单：
- 尺寸与间距：所有元素尺寸是否为偶数像素（避免半像素渲染模糊）；间距是否符合 4px 基准网格。
- 色彩还原：开发实现的颜色值与设计稿的色值偏差是否在 ΔE ≤ 2 范围内（专业显示器目测即可）。
- 字体渲染：字体族、字号、行高是否与标注一致；中文是否使用正确的字重。
- 状态覆盖：每个可交互元素是否包含默认、悬停、按下、禁用、聚焦五种状态。
- 响应式行为：在不同屏幕尺寸下，布局是否按栅格规则自适应，是否有断点设计说明。
- 动效实现：动效时长、缓动曲线、触发条件是否与设计稿一致。
- 资源引用：切图是否被正确引用，路径是否规范，是否存在多余未使用的资源。
复盘方法：建议每个迭代周期结束后，设计、开发、测试三方共同进行一次“视觉还原走查”。选取 3-5 个核心页面，逐项对照验收清单打分，将发现的问题分为“阻断类”（必须修复）、“建议类”（可以优化）、“记录类”（后续版本处理）三个等级。走查结果应形成书面记录，作为下一轮迭代的输入。