跳到主要内容
佳益手记

企业博客

技术专栏 · 发布 2026年8月28日

从设计稿到设计系统:和研发协作的三个约定

间距不一致、状态没覆盖、组件重复实现,往往不是态度问题,而是没有写下共同约定。

设计稿交付之后,真正的协作才刚开始。间距不一致、状态没覆盖、组件重复实现——这些问题很少是态度问题,而是双方没有在交付前写下共同的约定。

约定一:token 先行

颜色、字号、间距、圆角与阴影,先以 token 的形式确定下来。设计稿里出现的每一个值,都应该能在 token 表中找到对应项。这样研发在实现时不需要猜测,后续调整也能一处生效。

约定二:状态与边界一起交付

一个按钮不只是默认态,还有悬停、禁用、加载与错误;一个列表不只是有数据,还有空状态、超长文本与分页边界。把这些状态在交付时一并说明,能减少大量返工。

约定三:变更走同一入口

  • 设计变更统一记录在同一个位置,说明影响范围;
  • 研发实现与设计稿不一致时,先确认是遗漏还是有意调整;
  • 新增组件必须补充使用说明与可访问性要求。
设计系统真正的产出,不是一套组件,而是一种“下一次不用重新讨论”的协作习惯。

当约定被写下来并持续执行,设计与研发的关系会从“交付与验收”,变成共同对体验负责。

返回博客列表

想把文章里的方法用到您的项目里?

我们乐于分享更多实施细节,也欢迎您带着具体问题与我们交流。

开始一次对话 →
— 编辑部 · 佳益方圆EST. 2019 · JYFY