初创公司的设计系统：我如何反向构建我的设计系统

我反向构建了我的设计系统。大多数建议说”等到产品市场契合再说”。我从第一天起就使用CSS自定义属性，因为个人网站上的一个CLS错误让我认识到跳过令牌的代价：累积布局偏移高达0.493，经过两次调试才追溯到一个不一致的间距值。修复只花了15分钟，但调查花了3个小时。令牌本可以完全避免这个错误。¹

TL;DR

设计系统解决的是协调问题。独立开发者在单个项目中不存在人与人之间的协调问题，但存在过去的自己与未来的自己之间的协调问题。在为blakecrosley.com构建设计令牌系统——10个颜色令牌、13个字体大小级别、8个间距值——之后，我总结出正确的顺序是：令牌立即开始（第一天），模式在重复三次时提取，正式系统永远不做（对于独立项目）。令牌的投入在第一次因间距不一致导致布局错误时就能收回成本。

我的设计系统：只有令牌，别无其他

非调色板的颜色方案

我的整个网站基于10个CSS自定义属性运行，没有品牌色：

:root {
  --color-bg-dark:        #000000;
  --color-bg-elevated:    #111111;
  --color-bg-surface:     #1a1a1a;
  --color-text-primary:   #ffffff;
  --color-text-secondary: rgba(255,255,255,0.65);
  --color-text-tertiary:  rgba(255,255,255,0.4);
  --color-border:         rgba(255,255,255,0.1);
  --color-border-subtle:  rgba(255,255,255,0.05);
  --color-accent:         #ffffff;
}

四个透明度层级（100%、65%、40%、10%）承载了整个视觉层次。每个文本层级在#000000背景上都通过了WCAG AAA对比度标准。没有渐变，没有语义化颜色，没有深色/浅色模式切换。这种约束产生了一个连贯的系统，组件库无法进一步改进。²

跳过品牌色是一个设计决策，而非技术决策。在我的16个产品设计研究中，我注意到我最尊敬的产品（Linear、Vercel、Raycast）都使用克制的调色板，让排版来完成层次表达的工作。

8点间距系统

每个间距值都基于8点基数派生：

:root {
  --spacing-xs:  0.5rem;  /* 8px */
  --spacing-sm:  1rem;    /* 16px */
  --spacing-md:  1.5rem;  /* 24px */
  --spacing-lg:  2rem;    /* 32px */
  --spacing-xl:  3rem;    /* 48px */
  --spacing-2xl: 4rem;    /* 64px */
  --spacing-3xl: 6rem;    /* 96px */
  --spacing-4xl: 8rem;    /* 128px */
}

没有任意值。系统包含八个级别。如果某个布局需要系统中不存在的间距值，那是设计的问题，而不是系统的问题。

--spacing-2xs错误

我是通过惨痛教训学到这个规则的。我为副标题的margin-top使用了--spacing-2xs。这个令牌在我的:root定义中并不存在。CSS自定义属性会静默失败——浏览器应用了零间距而不是抛出错误。副标题与标题贴在一起，页面加载时布局发生偏移，累积布局偏移分数飙升至0.493。³

调试路径：Lighthouse标记了CLS问题。DevTools识别出偏移的元素。检查计算样式发现margin-top: 0，而预期值是4px。在样式表中搜索--spacing-2xs，发现一处使用但零处定义。

修复方案：将--spacing-2xs改为--spacing-xs。更广泛的修复：严格遵守令牌系统，不做任何例外。

字体大小级别

从12px到80px的13个级别，使用系统字体：

:root {
  --font-family: -apple-system, BlinkMacSystemFont, "SF Pro Text",
                 "SF Pro Display", "Helvetica Neue", Arial, sans-serif;
  --font-size-xs:      0.75rem;   /* 12px */
  --font-size-sm:      0.875rem;  /* 14px */
  --font-size-base:    1rem;      /* 16px */
  --font-size-lg:      1.125rem;  /* 18px */
  --font-size-xl:      1.3125rem; /* 21px */
  --font-size-2xl:     1.5625rem; /* 25px */
  --font-size-3xl:     1.875rem;  /* 30px */
  --font-size-4xl:     2.25rem;   /* 36px */
  --font-size-5xl:     2.7rem;    /* 43.2px */
  --font-size-6xl:     3.25rem;   /* 52px */
  --font-size-7xl:     3.875rem;  /* 62px */
  --font-size-display: 5rem;      /* 80px */
}

系统字体完全消除了字体加载延迟。没有FOIT（不可见文本闪烁），没有FOUT（无样式文本闪烁），零字体网络请求。这一选择为我的Lighthouse性能满分100/100做出了贡献。⁴

时机问题

太早：过度抽象陷阱

种子轮初创公司面临着产品最终形态的极大不确定性。设计系统编码了关于交互模式、组件层级和视觉语言的假设。当产品转型时，设计系统就变成了抵制变化的负债。⁵

一个由三名工程师和一名设计师组成的团队不需要一个带有文档、版本控制和Storybook实例的组件库。协调的开销超过了需要协调的问题本身。

但令牌不同。令牌不是抽象——它们是值。颜色令牌不会强加组件结构。间距令牌不会约束交互模式。令牌能在产品转型中存活，因为它们在组件层之下运行。

太晚：设计债务螺旋

B轮公司拥有30名工程师却没有共享的设计模式，面临着相反的问题。每个功能团队都发明自己的按钮样式、表单布局和间距值。产品看起来像三个不同的应用拼接在一起。⁶

我在自己的项目中也看到了同样的模式，只是规模更小。当我开始一个新项目而没有复制:root令牌时，不一致性在第一周内就会出现。令牌是防止债务螺旋的廉价保险，而债务螺旋一旦形成，偿还代价极其高昂。

渐进式投入框架

阶段1：仅令牌（第一天，任何团队规模）

只定义和共享基础值。我的实现：

总共41个令牌。零组件。零文档站点。目标是在值的层面防止分歧，同时为实验保留最大灵活性。⁷

阶段2：模式提取（当模式重复3次时）

当同一UI元素出现在三个不同的功能中时，提取该模式。我的网站已经提取的模式包括： - 卡片布局（项目卡片、博客卡片、社交卡片）：一致的内边距、圆角、悬停状态 - 导航下划线（导航链接、面包屑）：悬停时scaleX(0) → scaleX(1)过渡效果 - 毛玻璃效果头部：backdrop-filter: blur(20px)配合border-bottom

每个模式的存在，都是因为我构建了同样的东西三次并注意到了重复。我从生产代码中提取模式，而不是提前设计它们。生产模式编码了真实需求。⁸

阶段3：正式系统（25+工程师，独立项目永远不需要）

在大规模团队中，协调问题的规模足以支撑组件库、Figma镜像、贡献流程和版本化变更日志。我的个人项目从未到达这个阶段，也不预期会到达。对于独立开发者，令牌加提取的模式提供了足够的结构，而不需要承担正式系统的维护开销。

我完全跳过的部分

文档站点

面向公众的设计系统文档站点消耗的工程时间对于独立项目来说产生零用户价值。我的”文档”就是critical.css中的:root块。任何开发者（或AI代理）阅读该文件就能立即理解整个系统。

多框架支持

我的网站使用纯CSS。没有React组件，没有Vue封装，没有Web Components。令牌在任何框架中都能工作，因为CSS自定义属性本身就是框架无关的。抽象层就是CSS本身。

过早的无障碍表演

无障碍性很重要——我的网站在每个文本层级都达到了WCAG AAA对比度标准。但我是先构建对比度系统（具有已知比率的令牌），然后再验证合规性。从内置无障碍性的令牌开始（每个文本层级都超过7:1的对比度）比事后审计任意选择的颜色更为有效。⁹

核心要点

对于独立开发者： - 从第一天起就为颜色、字体、间距和过渡效果定义CSS自定义属性；41个令牌的投入能防止后续花费数小时调试的错误和不一致性 - 跳过组件库、文档站点和Storybook；对于独立项目，维护开销超过了协调收益 - 当同一元素出现在三个地方时，从生产代码中提取模式；过早提取会浪费精力在可能无法存活到下一次迭代的模式上

对于初创公司设计负责人： - 在产品市场契合之前就开始使用令牌；令牌能在产品转型中存活，因为它们在组件层之下运行 - 在25+工程师产生真正的协调问题之前，抵制建立正式系统的冲动；过早的正式化会产生减缓迭代速度的维护开销

参考文献