设计稿交付的终点不是发出一个链接,而是让研发能从同一份文件找到页面、状态、尺寸、资源和交互规则。使用墨刀设计整理页面与标注,并在交付前按真实任务走一遍,能减少口头补充和返工。

一、交付包应包含哪些内容
| 内容 | 至少写清 | 研发如何使用 |
|---|---|---|
| 页面与流程 | 入口、返回、分支和权限 | 按路径实现页面和路由 |
| 组件状态 | 默认、悬停、禁用、加载、错误 | 映射组件状态和逻辑 |
| 尺寸与响应式 | 容器、栅格、断点、最小宽度 | 实现不同屏宽布局 |
| 资源 | 图片、图标、字体、格式 | 下载并核对命名与尺寸 |
| 交互规则 | 触发条件、反馈、接口依赖 | 拆分事件和数据处理 |
| 验收标准 | 关键任务、异常和完成条件 | 自测后回到同一条清单 |
二、用“订单取消”示范标注
订单取消页至少要标出订单状态、取消原因、二次确认、接口等待、成功和失败。不要只标“按钮点击跳转”,应写明:订单已发货时按钮隐藏;提交后按钮进入加载;接口成功展示退款说明;失败保留表单并提示重试。这样研发无需猜测状态切换。
- 给每个状态命名,并标注出现条件和可恢复动作。
- 长文案、超长订单号和空数据都用真实或接近真实的内容检查。
- 把接口字段、枚举值和权限限制链接到对应文档,不在图片里藏规则。
- 在页面旁附一份变更记录,写清本次新增和废弃的状态。

三、交付前十项检查
- 所有入口都能从流程起点走到终点,返回和取消行为明确。
- 按钮、输入框、弹窗和列表都有正常、禁用、加载和错误状态。
- 标注单位、字体、颜色和命名与组件规范一致。
- 移动端或窄屏下没有溢出,点击区域满足产品约束。
- 资源能下载,文件名和页面使用位置对应。
- 研发能在一分钟内找到页面、组件和接口依赖。
四、建立交付后的验收回路
开发联调时由产品按任务脚本验收,设计检查视觉与状态,研发确认实现边界。问题直接在原型节点评论并标注版本,不用聊天记录作为唯一依据。结论分为通过、需修改、暂不实现,并写清复验时间。
五、标注不是越多越好
标注应回答研发在实现时必须知道、但无法从视觉上推断的信息:触发条件、状态转换、数据格式、权限和异常处理。颜色、字号和间距等可被组件库读取的内容不必在每个页面重复标注。对同一组件,优先在组件说明中写规则,页面只标出本次特殊用法。
把主流程和异常路径跑通后,再把本页的复现记录与交付结果放在同一份版本记录中,后续评审可以直接追踪。
案例:后台数据看板的交付包怎么写
假设页面包含筛选、表格和导出操作,交付前先选定一个研发能独立复现的场景:管理员按日期筛选订单,查看空数据、加载失败和权限不足三种状态。把这条场景写在交付说明第一段,研发拿到链接即可开始核对。
- 为页面、弹窗和组件建立稳定名称,截图只作为辅助,不能代替可编辑稿。
- 在标注中写清尺寸、间距、字体、颜色和交互触发条件;长文案用真实内容测试换行。
- 列出默认、悬停、禁用、加载、成功和错误状态,并标明状态切换来源。
- 附上接口字段、占位数据、权限规则和资源下载路径,缺失项直接标“待确认”。
- 让研发按交付包独立实现一个小页面,再回收无法理解的说明。
| 交付项 | 研发要回答的问题 | 验收记录 |
|---|---|---|
| 页面与组件 | 改哪个实例、复用哪个组件? | 页面路径与组件名 |
| 状态与规则 | 什么条件触发变化? | 状态表与示例数据 |
| 资源与权限 | 从哪里取资源,谁能看到? | 链接、角色和负责人 |
以“订单取消”制作一份研发交付包
研发最常缺的不是一张漂亮页面,而是状态和规则。以订单取消为例,交付包应让研发在不找设计师补充说明的情况下,知道页面尺寸、组件状态、事件、资源和验收结果。
| 交付项 | 示例内容 | 验收方式 |
|---|---|---|
| 页面与尺寸 | 订单详情、取消弹窗、成功、失败;标注 390px 与桌面断点 | 按页面编号逐一打开 |
| 组件与状态 | 默认、悬停、禁用、提交中、成功、失败重试 | 用示例数据走完状态 |
| 事件与规则 | 点击取消后校验原因;重复提交时锁定按钮 | 对照事件名和触发条件 |
| 资源与权限 | 图标、图片、文案、角色权限和空值处理 | 检查资源路径与角色结果 |
| 验收记录 | 问题编号、截图、负责人、截止时间和结论 | 逐项标记通过、阻塞或待确认 |
交付前可复制的五步
- 给每个页面、组件和状态编号,删除研发无法判断的占位词。
- 在墨刀设计中整理页面、组件和尺寸标注,再在原型中连接取消、确认和失败路径。
- 补真实长度的订单号、金额和错误文案,检查长文本、空值和窄屏折行。
- 把点击事件、接口字段、权限条件和异常恢复写在同一份交付说明中。
- 让研发按正常取消和网络失败各走一遍,记录问题后再冻结版本。
交付完成的判断是:研发能复现核心任务,测试能从状态表生成用例,产品能从评论记录定位问题。做到这一点,设计稿才真正成为可实现、可验收的工作文件。