设计系统真正应该限制的是重复劳动和无意义差异，而不是业务创新。成熟系统通常在基础层保持严格，在业务层保留组合与扩展空间。
01 为什么很多团队会觉得设计系统“越做越没创意”
设计系统刚建立时，团队通常会明显感受到效率提升：按钮不用重画，颜色不用每次重新选，表单、弹窗、表格都能快速复用。但运行一段时间后，另一种声音会出现：“页面越来越像”“设计师只是在拼组件”“新业务也只能套旧模板”。这并不是错觉。有些设计系统确实会把团队带向僵化，只是根源往往不在“系统化”本身，而在于系统把不该锁死的东西也锁死了。
Atlassian 对自己的设计系统有一句很值得参考的原则：不要为了统一而统一，同时也拒绝无限自由。这个表述恰好说明了成熟设计系统的边界——它既不是一套所有人必须机械照抄的模板，也不是只提供几个颜色值、最终什么都能随意改的素材库。系统的价值，是把已经被验证的公共决策沉淀下来，让团队把精力留给真正需要判断的地方。
02 先区分两种设计决策：重复决策与业务决策
一个企业产品里，按钮高度、基础字号、错误色、表单间距、焦点状态、禁用状态等规则，往往会在几十甚至上百个页面里重复出现。如果每个设计师都重新决定一次，这些差异几乎不会创造业务价值，反而会增加开发成本、测试成本和用户学习成本。
但“这个功能应该放在哪里”“一个复杂任务应该拆成几步”“用户先看总览还是先处理异常”“新业务是否需要一种完全不同的信息组织方式”，这些属于业务层设计决策。它们不能因为组件库里已经有某个模板，就被提前决定。好的设计系统应该把前一类问题尽量标准化，把后一类问题留给设计师、产品和业务共同判断。
03 成熟设计系统通常不是一层，而是四层
第一层是基础设计语言，包括颜色、字体、间距、圆角、阴影、动效时长等。现在越来越多团队会把这些规则抽象成 Design Token。Atlassian 将 Token 定义为命名并保存设计决策的“单一事实来源”，其价值不是为了追求技术感，而是让设计与代码共享同一套语义，例如 success 文本色、危险背景色、紧凑间距，而不是到处复制具体色值。
第二层是基础组件，如 Button、Input、Select、Checkbox、Dialog。这一层应该高度统一，因为用户已经形成交互预期。第三层是组合与业务组件，例如订单卡片、审批区块、AI结果模块、风控状态面板。它们应该可以在基础规则上扩展。第四层是页面与任务流程，这一层最需要保留自由度，因为页面要解决的是具体业务问题。
一个常见的失败方式，是直接从“组件统一”跨到“页面统一”：首页必须用某种模板，详情页必须固定三段结构，数据页必须四张指标卡加一张折线图。到这一步，系统就不再只是基础设施，而开始替设计师做业务判断。
04 固定区和自由区应该怎么划
可以用一个简单原则判断：越接近基础层，规范越严格；越接近业务层，允许的组合与扩展越多。颜色语义、字号层级、焦点状态、键盘可用性不应该每次创新；但复杂业务流程、信息优先级、任务路径和页面结构必须允许重新设计。
这也意味着组件不能只提供“用或不用”两个选项。成熟系统需要合理的变体、尺寸、状态、插槽和组合方式。Atlassian 的开发文档甚至明确给出了一个思路：优先使用现成组件，组件不足时先利用已有的定制能力，再通过基础 primitives 与 Token 组合；只有确实存在新需求时才创建自定义组件。这种分层比“组件库里没有，所以不允许做”健康得多。
05 真正会杀死创意的，是把历史方案当成永久答案
很多系统最初的组件是为旧业务设计的。随着产品发展，用户角色变了、数据密度变了、AI能力加入了、移动端场景增多了，如果团队仍然以“以前就是这么做的”为理由强行复用，系统就会变成债务。
设计系统应该存在三个正常动作：复用、扩展、淘汰。复用解决重复问题，扩展处理相近但更复杂的场景，淘汰则负责清理已经不再适合产品的模式。系统治理不是不断把新组件塞进去，而是持续判断哪些规则仍然成立。
06 品牌感不等于每个页面都必须长得不一样
反对设计系统的人有时担心品牌会被“组件化”抹平。但真正稳定的品牌辨识度，往往来自长期一致的视觉语言：字体比例、色彩关系、图形特征、留白方式、动效节奏、语言语气。品牌并不需要靠每个页面重新发明按钮获得辨识度。
事实上，当基础层稳定后，设计师更容易在摄影、插画、图形系统、内容编排和关键场景体验上形成真正有价值的差异。随机变化制造的是“不同”，系统之上的有意识变化才更接近“创意”。
07 如何判断你的设计系统是不是已经过度约束
可以观察几个信号：设计评审中经常出现“因为组件库里只有这个所以只能这么做”；新业务必须先找一个旧页面套结构；大量组件通过新增几十个布尔属性勉强兼容不同需求；设计师频繁 detach 组件才能完成方案；开发为了遵守组件而写越来越多例外代码。
如果这些情况持续出现，问题通常不是团队“不守规范”，而是系统与真实业务之间已经产生断层。与其继续强调执行，不如重新审视系统边界。
08 结论：设计系统应该减少无意义选择，而不是减少思考
衡量一套设计系统是否成熟，不应该看组件数量有多少，也不应该看所有页面是不是足够相似。更值得看的指标是：重复问题是否被稳定解决，新业务能否在系统上快速扩展，设计与开发是否共享规则，产品体验是否保持一致，同时团队是否仍有能力为重要场景做新的设计判断。
当系统做到这一点，它不会让设计师变成“拼组件的人”。相反，它把设计师从大量低价值的像素决策里释放出来，让时间真正回到用户、业务和体验问题上。
常见问题
设计系统是不是组件越多越成熟？
不是。组件数量只能说明覆盖范围，不能说明质量。成熟度更取决于命名、规则、状态、文档、代码一致性、治理方式以及是否能支持真实业务扩展。
业务需要特殊页面时可以脱离设计系统吗？
可以，但应该有原因。优先判断能否通过现有 Token、基础组件和组合能力实现；如果业务确实出现新的通用模式，再考虑沉淀为新组件。
设计系统和组件库有什么区别？
组件库主要解决可复用 UI 元素；设计系统通常还包括设计原则、基础规则、Token、内容规范、无障碍要求、开发实现和治理机制。
设计系统会让品牌失去差异化吗？
不会必然如此。基础交互一致与品牌差异可以同时存在。品牌差异更多来自视觉语言、内容、影像、动效和关键体验，而不是每个基础控件都不同。
什么时候应该淘汰旧组件？
当组件长期需要大量例外、无法覆盖核心业务、与新技术或无障碍要求冲突，或者存在更稳定的新模式时，就应评估迁移与淘汰。
相关服务与进一步咨询
链接复制成功
