从零搭建一套可复用的设计交付清单(含文件命名与标注规范)

为什么需要“交付清单”

很多返工并不是设计不好,而是交付信息不完整:研发不知道哪些是可复用组件、哪些是临时图;切图缺少 2x/3x;文字样式在不同页面不一致;状态说明只写在脑子里。做一套可复用的交付清单,相当于把“每次都要解释一遍的事”固化成流程,省掉沟通成本,也能让新人更快上手。

交付前的三件准备事

1)统一画布与栅格:先定屏幕尺寸(如 iOS 390x844 或 Android 360x800)、栅格(8pt/4dp)和安全边距。所有页面共享同一套规则,后面才不会出现“这个页是 375,那个页是 390”的灾难。

2)建立样式资产:把常用字号、行高、颜色、投影、圆角做成样式(Figma Styles / Sketch Symbols / PS 组件)。交付时研发只需要对照一张样式表,不需要在 20 个页面里逐个抄数值。

3)定义组件边界:提前想清楚哪些是组件(按钮、输入框、卡片),哪些是页面内容(文案、图片)。组件要可复用,页面内容可以变化。边界清晰,研发实现也更快。

文件与页面命名规范(可直接套用)

推荐用“产品-端-模块-页面-版本”的结构,做到一眼可定位:

示例:shop_app_home_v1shop_app_pay_confirm_v2shop_web_admin_order_v1

页面内 Frame/Artboard 命名建议包含状态:首页/默认首页/空状态首页/网络异常。这样导出标注或截图时不会混。

图层结构:让研发一眼看懂

常见问题是图层乱:同一层级里既有背景又有文字,命名还是“Rectangle 123”。建议按“容器-内容-装饰”分组:

Card(容器)→ Sub Price(内容)→ ShadowDivider(装饰)。

命名尽量使用语义:Button/Primary、Icon/Search、Tag/New。语义命名比“蓝色按钮”更经得起改版。

文字样式与排版:交付要包含“规则”

交付不要只给尺寸,还要给规则:

字号与行高:例如 14/20、16/24,避免研发用默认行高导致视觉偏差。

字重:Regular/Medium/Semibold 明确写清,尤其是标题层级。

截断规则:一行省略、两行省略、最多展示 N 行;超过时用“…”还是换行。

中英文与数字:数字是否用等宽、金额是否保留两位、英文是否全大写。把这些写在交付说明里,能少很多“看起来不对但说不出哪里不对”的返工。

颜色与状态:别只交付一个“正常态”

建议至少覆盖:默认、按下/点击、禁用、加载、错误、空状态、成功提示。尤其是表单与按钮,状态不完整会直接影响开发排期。

颜色交付时最好给出:色值(HEX/RGBA)、使用场景、对比度注意点(例如浅灰文字仅用于辅助信息)。

切图导出:最容易被忽视的细节

1)优先用矢量:图标能用 SVG 就不要导 PNG,减少包体并保证清晰。

2)需要位图时:明确 1x/2x/3x(或 mdpi/hdpi/xhdpi/xxhdpi)。命名示例:icon_search@2x.png。

3)透明边与对齐:导出前检查是否有多余透明边,避免开发对齐困难。尤其是带发光、阴影的图,透明边会把视觉中心“挤偏”。

4)可拉伸资源:如果有背景气泡、按钮背景,说明是否可九宫格拉伸,或者用 CSS/代码实现。

标注交付:用“最少但够用”的方式

标注不是越多越好,重点是让研发能还原规则:

间距:模块内间距、模块间距、页面边距、列表行高。

尺寸:按钮高度、圆角、图标尺寸、卡片最小高度。

对齐:左对齐/居中/基线对齐,尤其是图标+文字组合。

组件约束:宽度自适应还是固定;文本变长时按钮是否增宽;列表项是否允许换行。

交付说明模板(可复制到文档)

交付范围:本次包含首页、搜索、商品详情、下单确认 4 个页面。

适配规则:以 8pt 栅格为基准,边距 16,列表间距 12;最小点击区域 44x44。

交互说明:按钮按下态透明度 0.8;加载中显示骨架屏;错误态提示文案可点击重试。

资源说明:图标使用 SVG;需要位图的图片已按 1x/2x/3x 导出。

验收要点:对齐、文字行高、状态覆盖、空/错态一致性。

交付前自检清单(建议打印贴墙)

1)标题与页面命名是否统一、可检索?

2)组件是否都有默认/按下/禁用/加载等必要状态?

3)文字样式是否都来自样式库(而非临时手调)?

4)切图是否去掉多余透明边,尺寸与命名是否正确?

5)关键间距是否标注齐全,是否符合栅格规则?

6)空状态/错误态是否覆盖,提示文案是否合理?

7)是否有需要研发特别注意的规则(截断、对比度、动效)并写清?

常见坑与解决办法

坑 1:标注只给了“结果”,没给“规则”。解决:补充约束和自适应策略,例如“左右边距固定 16,内容区自适应”。

坑 2:组件拆得不清楚。解决:用组件名表达用途(PrimaryButton/SecondaryButton),并在页面上复用同一组件实例。

坑 3:状态缺失导致研发临场发挥。解决:最少覆盖默认/按下/禁用/错误/空状态,交互规则写在说明里。

结语

交付清单不是形式主义,它是让团队协作变顺滑的“共同语言”。第一次搭建可能要花一两个小时,但一旦形成模板,后续每个项目都能复用,返工会明显下降。你也可以从最痛的环节开始:先把命名、样式、状态补齐,再逐步完善标注和自检。

用户评论 (0)

登录后参与讨论

立即登录 注册账号

暂无评论,快来抢沙发吧~

操作成功