UI设计切图规范：从命名到交付的全流程工程化实践

1. 项目概述为什么“切图规范”是UI设计师的必修课在任何一个移动端或Web端产品从设计稿到最终上线的漫长链路中UI设计师与前端工程师之间的协作往往是最容易“扯皮”的环节。设计师精心打磨的像素级视觉效果到了开发手里还原度可能大打折扣而开发工程师则常常抱怨设计师给的资源“没法用”不是尺寸不对就是格式混乱或者命名让人一头雾水。这个矛盾的根源很大程度上就出在“切图”这个看似简单、实则暗藏玄机的环节上。UI设计切图规范正是为了解决这一核心协作痛点而生的“工程化语言”和“协作契约”。它绝不仅仅是把设计稿上的图标、按钮“切出来”那么简单。一套完善的切图规范定义了从资源命名、尺寸规格、文件格式、输出目录到状态管理的完整标准。它确保了设计师的视觉意图能被无损、高效地传递给开发也保证了开发同学能快速、准确地获取所需资源避免在沟通和返工上浪费宝贵时间。尤其是在如今多端适配iOS、Android、Web、小程序、多分辨率屏幕1x、2x、3x、4x成为标配的背景下没有一套清晰的切图规范项目几乎寸步难行。这不仅是提升个人专业度的体现更是保障团队协作顺畅、项目质量稳定的基石。2. 切图前的核心准备工作从源文件到思维框架很多新手设计师拿到设计稿后会迫不及待地开始用切片工具“框选”这是最大的误区。切图不是体力活而是需要精密规划的技术活。在动刀之前必须完成以下几项关键的准备工作这直接决定了后续所有工作的效率和准确性。2.1 设计稿的“清洁度”检查与图层管理一个混乱的源文件是灾难的开始。在切图前你必须像外科医生术前准备一样对设计稿进行彻底的“消毒”和整理。首先是图层的规范化命名与分组。杂乱无章的图层名称如“图层1 拷贝3”会让后续的查找和导出变得极其困难。你需要为每一个可交互或独立的视觉元素如按钮、图标、卡片的图层或图层组进行清晰的命名。命名应遵循“模块_组件_状态”的逻辑例如btn_primary_normal按钮_主要_常态、icon_search_active图标_搜索_激活态。同时将相关的图层进行编组并隐藏或删除所有在最终界面上不可见的辅助线、参考图层和废弃设计稿保持画布的整洁。其次是确保所有元素的矢量化与栅格化边界清晰。对于图标、Logo等元素应尽量使用矢量形状图层Shape Layer或智能对象以保证在任何缩放倍数下都能输出清晰的图像。对于必须使用位图如图片背景的地方要确保其原始分辨率足够高避免放大后模糊。一个关键技巧是在Sketch或Figma中使用“设置为导出项”或“创建组件”功能来预先标记需要导出的元素这能极大提升后续批量导出的效率。最后是建立统一的样式库和组件库。在开始具体页面设计前就应该定义好项目的色彩体系、文字样式字体、字号、行高、投影、圆角等基础样式并创建按钮、输入框、导航栏等高频组件的SymbolSketch或ComponentFigma。这不仅保证了设计的一致性在切图时你只需要切出这些基础组件一次开发即可通过代码复用无需为每一个按钮单独切图这是现代UI设计工作流的核心效率来源。2.2 明确适配策略一稿适配多端的核心逻辑“这个图要切几倍”这是前端工程师最常问的问题。答案取决于你的产品需要适配哪些平台和屏幕。iOS平台通常需要 1x、2x、3x 三种倍率的切图。在750*13342x为基准的设计稿中1x的图就是缩小到50%3x的图就是放大到150%。但注意有些纯矢量的图标如用代码实现的SVG或系统提供的SF Symbols可以只提供一份由系统自动缩放。Android平台的密度体系更为复杂有ldpi、mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi等。目前最主流的做法是以xxhdpi通常对应1080p屏幕缩放倍率3x作为设计基准然后按比例生成其他密度的资源。许多设计工具和插件可以自动完成这个缩放过程。Web端的适配则更灵活。对于需要保持清晰度的图标可以准备多倍图如icon.png和icon2x.png通过CSS的image-set或srcset属性让浏览器根据设备像素比选择加载。而更多的背景、装饰性图形则可以使用CSS3属性如渐变、阴影或SVG矢量格式来实现减少对位图的依赖。关键决策点在于哪些资源需要切图哪些可以用代码实现一个简单的判断原则是带有复杂渐变、纹理、特殊形状或动态效果的图形需要切图而纯色填充、简单圆角矩形、单色线条图标应优先考虑用CSS或平台原生控件绘制。与前端工程师提前沟通这个边界能节省双方大量时间。3. 切图实操详解工具、流程与核心参数设置准备工作就绪后我们进入具体的切图操作环节。这里以目前主流的Figma/Sketch工具为例详解每一步的操作要点和背后的原理。3.1 切片工具的使用与导出区域设定在Figma或Sketch中切片工具Slice或Export是你的手术刀。选中一个图层或编组后右侧面板会出现导出Export的设置区域。第一步正确框选导出范围。对于图标通常需要紧贴图标内容边缘不留多余透明像素这有助于减少文件体积也方便开发进行对齐。但有一个重要例外当图标需要与文字或其他元素保持固定间距时有时需要保留一定的“安全内边距”Padding这时导出的切片范围就需要包含这部分空白。最佳实践是与开发约定一个统一的Padding规则例如所有图标都导出为实际尺寸外增加2px透明边距的正方形画布。第二步处理包含背景的组件。对于一个按钮你可能需要导出整个按钮的图形也可能只需要导出按钮上那个小小的“”图标。这里涉及到“合并导出”与“单独导出”的选择。如果按钮的背景是简单的圆角矩形完全可以用代码实现那么你只需要导出中间的“”图标通常是SVG格式。如果按钮有复杂的渐变、内阴影或纹理那就需要将按钮作为一个整体切片导出。在切片时务必隐藏掉不必要的文本图层文字通常由代码渲染只保留图形部分。3.2 文件命名规范让机器和人都能读懂混乱的命名是协作的噩梦。一套好的命名规范应该做到“见名知意”并且便于工具自动化处理。基本结构建议采用组件_类型_状态_描述倍数.格式。组件 (Component):指明元素所属的模块或大类如nav导航栏、btn按钮、icon图标、tab标签栏、bg背景。类型 (Type):在组件内进一步分类如btn_primary主要按钮、btn_secondary次要按钮。状态 (State):描述元素的交互状态这是最容易被忽略但至关重要的部分。常见状态有normal常态、pressed/active按下/激活、disabled禁用、selected选中。例如btn_primary_pressed。描述 (Description):可选用于进一步区分同类型元素如icon_search、icon_close。倍数 (Scale):如2x,3x。对于SVG或PDF等矢量格式通常不加倍数后缀。格式 (Format):如.png,.jpg,.svg。示例btn_primary_normal2x.png主要按钮-常态-2倍图icon_back_disabled3x.png返回图标-禁用态-3倍图bg_home_header.jpg首页头部背景图必须遵守的规则全小写避免因系统大小写敏感问题导致资源找不到。使用下划线_连接不要使用空格、横线-在部分脚本中横线可能有特殊含义下划线是兼容性最好的分隔符。语义化优先名称应准确描述内容而不是“image1”、“pic2”这样的无意义字符串。3.3 输出格式选择PNG、JPG、SVG与WebP的适用场景选择正确的格式能在视觉效果和性能之间取得最佳平衡。PNG支持透明通道Alpha通道的位图格式首选。适用于图标、Logo、带透明背景的UI组件。导出时务必注意颜色模式选择RGB而非CMYK用于印刷。位深度选择“24位 PNGRGB”加上“8位 Alpha通道”即通常工具中的“PNG-24”选项以确保色彩和透明度质量。优化勾选“导出为Web所用格式”或类似选项工具会进行无损压缩大幅减小文件体积。对于简单图形也可以考虑PNG-8索引256色体积更小但需检查色彩过渡是否出现断层。JPG/JPEG适用于色彩丰富、没有透明需求的照片、渐变背景或复杂纹理。它是一种有损压缩格式可以通过调整压缩比质量通常60%-80%即可在画质和体积间权衡。绝对不要用它来保存带纯色边缘或文字的图形会产生难看的噪边。SVG矢量图形的王者。适用于图标、简单插画。它由数学公式定义无限缩放不模糊且文件体积通常极小。在Web和现代移动开发中SVG的使用越来越广泛。导出SVG时要注意在设计工具中确保图形是真正的矢量路径而不是栅格化后的位图。导出前执行“轮廓化描边”Convert Strokes to Outlines避免在某些环境下描边显示异常。清理不必要的元数据使用工具或在线服务如SVGO进行优化删除隐藏图层、冗余节点。WebP谷歌推出的现代图像格式在同等质量下体积比PNG和JPG小很多同时支持透明度和动画。它是Web性能优化的利器。虽然部分老旧浏览器不支持但可以通过picture标签提供兼容方案。在设计工具中直接导出WebP可能选项有限通常由前端通过构建工具如Webpack进行自动转换。格式选择决策流需要透明吗需要 - PNG 或 WebP。是图标或简单图形吗是 - 优先考虑 SVG。是照片或复杂图像吗是 - JPG 或 WebP。追求最佳性能和兼容性提供 PNG/JPG 后备主推 WebP。4. 多平台与多状态资源的特殊处理规范现代UI设计充满动态交互一个按钮有常态、按压、禁用等多种状态一个应用需要适配iOS、Android、Web等多个平台。如何高效、清晰地管理这些资源是规范的高级课题。4.1 交互状态切图不仅仅是换颜色一个按钮的“按压”状态可能不仅仅是颜色变深还可能伴有轻微的位移、阴影变化或微妙的纹理改变。切图时必须为每一种明确定义的交互状态输出对应的资源。常见状态包括Normal (默认状态):元素的初始外观。Pressed / Active (按压/激活状态):用户点击或按住时的反馈。Disabled (禁用状态):元素不可交互时的外观通常降低透明度或变为灰色。Selected (选中状态):用于标签栏、单选按钮等表示已选中的情况。Hover (悬停状态):主要用于Web端鼠标悬停时的效果。Focus (聚焦状态):获取键盘焦点时的状态对于可访问性至关重要。实操要点在设计稿中最好使用组件变体Figma Variants或符号覆盖Sketch Overrides来管理这些状态。切图时通过切换组件的状态分别对每个状态进行切片和导出。命名上必须清晰体现状态如btn_submit_normal.png和btn_submit_pressed.png。千万不要只提供一个状态图然后告诉开发“按下时把颜色值改成#XXXXXX”对于带有复杂背景、边框或内部图形的按钮这种做法无法实现设计效果。4.2 多平台适配iOS、Android与Web的差异化输出不同平台有其特定的设计语言和技术实现方式切图也需要“因地制宜”。对于iOS (iPhone/iPad):格式偏好PNG是绝对主流对于App Icon等也需要提供特定尺寸的PNG。图标资源通常放入.xcassets素材目录中系统会自动管理1x, 2x, 3x。命名规范除了通用的语义化命名有时需要遵循苹果的特定命名例如启动图LaunchScreen.png应用图标AppIcon.png实际上一组不同尺寸的图。切片注意iOS的导航栏、状态栏、标签栏图标有标准的尺寸要求如44pt点击区域切图时需要遵守。对于Android:资源目录结构资源按密度分目录存放drawable-mdpi/,drawable-hdpi/,drawable-xhdpi/,drawable-xxhdpi/,drawable-xxxhdpi/。你需要将不同倍率的图放入对应文件夹。格式与命名PNG同样首选也支持WebP。命名规则与通用规范一致但不能使用大写字母不能使用横线-横线在Android资源命名中用于分隔资源类型和配置限定符容易冲突坚持使用小写字母和下划线。.9.png 点九图这是Android独有的伸缩位图格式用于聊天气泡、按钮背景等需要水平和垂直拉伸的区域。它通过图片四条边上的1像素黑线来定义可拉伸区域和内容填充区域。虽然现在更多使用矢量图或代码实现但在处理复杂背景拉伸时它仍是重要工具。导出时需要专门工具生成。对于Web:灵活性最高格式上PNG、JPG、SVG、WebP均可。命名规范主要服务于前端工程目录结构。雪碧图 (CSS Sprite) 的考量为了减少HTTP请求可以将多个小图标合并到一张大图上通过CSSbackground-position来定位。虽然HTTP/2普及后其必要性降低但在某些场景下仍有价值。如果需要提供雪碧图除了提供合并后的大图还必须提供一份详细的坐标文档通常由自动化工具生成。响应式图像对于重要图片可能需要提供不同尺寸非仅不同倍率的版本以适应从手机到桌面的不同视口。这通常通过img srcset...或picture标签实现设计师需要提供至少两到三个不同宽度的图片版本。4.3 可拉伸元素的处理.9图与矢量方案的抉择前面提到的.9.png是Android处理可拉伸背景的传统方案但它有几个缺点制作稍复杂多倍图需要分别制作且不适用于非矩形拉伸。现代更优的解决方案是使用矢量图形。SVG (Web):在Web端SVG可以完美实现任意形状的缩放且体积小。矢量绘图指令 (iOS/Android):在移动端可以使用平台提供的矢量绘图API。例如在iOS中你可以用代码描述一个带圆角、渐变和阴影的矩形在Android中可以使用XML定义的shape或矢量图vector。作为设计师你的职责是向开发提供精确的图形参数如圆角半径、渐变色标和位置、阴影的X/Y偏移和模糊度、边框粗细和颜色等。这些参数应详细记录在设计文档或标注工具中。决策路径如果背景极其简单纯色圆角矩形直接给参数让代码实现。如果背景复杂但形状规则带线性渐变和阴影的圆角矩形优先提供参数代码实现性能更好。如果背景是复杂的、不规则的图案纹理如布纹、水彩边缘那么使用.9.png或直接输出一张足够大的位图是更现实的选择。5. 标注与交付确保设计意图的精准传递切图文件本身只是原材料没有准确的“说明书”开发仍然可能用错。标注Specification就是这份说明书它告诉开发每个元素的尺寸、间距、颜色、字体和状态变化规则。5.1 设计标注的核心内容不止于尺寸和色值传统的标注工具如蓝湖、Zeplin、Figma自带标注可以自动生成很多信息但设计师需要有意识地检查和补充关键内容尺寸与间距元素自身的宽高以及元素与元素之间、元素与屏幕边缘之间的间距。特别注意对齐方式左对齐、居中对齐、右对齐。颜色提供HEX十六进制色值对于透明度Alpha提供RGBA或HSLA值。标注出所有用到的颜色并最好附上全局色彩样式表。文字样式字体、字重Regular, Bold等、字号、行高、字间距、对齐方式。行高Line Height尤其重要它直接影响多行文本的排版效果。圆角与边框圆角半径是统一值还是单独设置边框的粗细、颜色和类型实线、虚线。阴影与模糊阴影的X/Y偏移、模糊半径、扩散范围和颜色含透明度。对于背景模糊毛玻璃效果需要标注模糊度。交互状态说明这是标注中最容易遗漏的部分。必须在标注中清晰地展示不同状态如按下、禁用下上述所有属性颜色、阴影等发生了哪些具体变化。可以用页面链接或状态切换的方式呈现。5.2 交付物清单与目录结构规范将一堆散乱的文件扔给开发是不负责任的行为。专业的交付应该是一个结构清晰、内容完整的“资源包”。标准的交付物应包含设计源文件最新版的Sketch/Figma/XD文件链接或存档。切图资源文件夹这是核心交付物。目录结构示例assets/ ├── icons/ # 图标类资源 │ ├── common/ # 通用图标 │ │ ├── ic_add2x.png │ │ └── ic_add3x.png │ └── tab/ # 标签栏图标 │ ├── ic_home_normal2x.png │ └── ic_home_selected2x.png ├── images/ # 图片类资源 │ └── bg_login.jpg ├── components/ # 组件切片如按钮背景 │ └── btn_large_normal2x.png └── splash/ # 启动图等特殊资源 └── launch2x.png可以按平台再分一级目录如assets/ios/,assets/android/。设计标注链接/文档提供蓝湖、Zeplin的在线链接或导出的PDF标注文档。确保开发团队所有成员都有访问权限。设计规范文档 (可选但推荐):一个独立的PDF或Notion页面系统性地阐述项目的设计语言包括色彩体系、字体阶梯、间距系统、组件库使用说明、动效原则等。这对于大型项目或长期迭代至关重要。更新日志 (Change Log):如果本次交付是版本更新应附带一个简单的文本说明列出新增、修改和删除的资源清单帮助开发快速定位变更。交付流程建议使用协同工具如Figma、蓝湖进行实时交付和更新是最佳实践。如果必须发送文件包请使用压缩包并确保包内结构清晰。在交付时通过团队协作工具如Slack、钉钉、飞书明确告知开发同学并附上关键变更点的简要说明。6. 版本迭代与协作流程中的规范维护设计不是一锤子买卖产品会持续迭代。如何在高频的修改中保持切图规范的效力避免资源混乱是更大的挑战。6.1 资源更新与删除的规范流程“只增不改”是理想状态但现实是资源经常需要更新甚至删除。更新资源当某个图标或图片需要修改时务必保持文件名不变只更新文件内容。这样开发同学只需要替换旧文件而不需要修改代码中的引用路径。如果视觉变化巨大需要更改命名则应视为“新增废弃”流程。删除资源绝对不要直接从共享文件夹或协同工具中悄无声息地删除一个旧资源。正确的做法是在设计标注中将该元素标记为“已废弃”或“待删除”。与前端负责人沟通确认该资源在代码中已无引用。双方约定一个清理周期如下个版本迭代然后在周期内由开发移除代码引用设计师再移除设计稿和资源文件。在交付清单的更新日志中明确记录“删除icon_old_feature.png”。新增资源严格按照既有的命名规范和目录结构存放新文件。在更新日志中记录新增项。6.2 使用协同工具固化规范现代设计协作工具Figma, Sketch with Abstract等本身就能成为规范的载体。组件库与样式库将颜色、文本样式、组件全部建立在团队的共享库中。当库更新时所有使用该库的设计文件都会收到更新通知。这从源头上保证了设计元素的一致性也间接保证了切出资源的规范性。自动标注与切图蓝湖、Zeplin等插件可以自动从设计稿生成标注和切图并保持与源文件的同步。当设计师更新主组件并发布库后标注和切图资源可以一键更新极大地减少了手动操作的错误和沟通成本。设计评审流程利用工具的评论和审批功能建立设计评审流程。在评审环节就可以检查切图规范、标注完整性将问题前置而不是等到交付开发时才暴露。6.3 建立团队共识与文档规范的生命力在于执行。再好的规范如果只有你一个人知道也形同虚设。团队内宣导在项目启动初期召集所有相关的UI/UX设计师和前端开发共同评审并确认这份切图规范。让大家理解每一条规则背后的原因例如为什么命名要用下划线而不是横线这比强制要求更有效。创建活文档将最终的规范整理成一份团队共享的文档如Confluence、Notion、语雀页面。这份文档应该包含所有细节命名公约、目录结构、格式标准、标注要求、交付流程、工具设置指南等。并且随着项目演进和技术变化及时更新这份文档。设立质量检查点可以在设计评审的checklist中加入“切图规范符合性”这一项。或者在将设计稿交付开发前由资深设计师或设计负责人进行一次快速的规范符合性检查。从我过去在多个跨端项目中协作的经验来看前期在规范制定和沟通上多花一天时间往往能在后期节省掉数十天因资源错乱、沟通返工所浪费的时间。切图规范本质上是一种预防性的工程思维它把设计师从重复、低效的“切图民工”角色中解放出来让其更专注于创造性的设计工作同时也为开发同学构建了一条清晰、可靠的“生产线”。当团队每个人都习惯并信任这套规范时整个产品研发的流水线就会变得顺畅而高效。