入职 Meridian 的第一周，我打开设计系统文档，看到四百个组件。第二周我了解到，大约三分之一的新页面在用它们。第三周，我不再感到惊讶。
组件库不是问题所在。组件做得不错，文档也很完整，显然有人认真写过空状态指引。问题是，从来没有人就「这个库到底为了什么」达成共识。每个团队都有自己的答案，而所有人都忙着交付。
库是产物，契约才是产品
设计系统不是一堆组件，而是设计师和工程师之间一份长期有效的约定：哪些决定是政策，哪些是共享的默认值，哪些属于本地。组件只是这份约定显形的地方。
这个区分听起来很学术，直到你看见两个团队为了一颗按钮争论。一方说，按钮归系统管；另一方说，按钮归系统管，直到某个流程需要按钮做不到的事——而大多数流程都需要。争论底下其实是一个契约问题：谁有权力决定，以及当答案是「不是你，也不是现在」时怎么办。
成熟的设计系统会明确回答这个问题。不成熟的系统会在每个迭代里反复回答，每次的答案还都不太一样。
契约里写了什么
一份有用的契约，条款比组件库多，而且几乎都是散文。
命名。 我们同意管它叫 chip，不叫 pill，不叫 tag，也不叫 badge。这不是咬文嚼字；共享的语言是我们能买到的最便宜的互操作性。名字有争议，组件就有争议，而这场争论会在每一次评审里重演。
归属。 谁能改 token，谁评审组件变更，什么算破坏性改动，都要写下来。如果平台团队可以悄悄重命名一个 prop，那不叫系统，那叫一个带漂亮官网的依赖。
版本。 版本号是承诺。补丁修复，次版本增加，主版本破坏。大多数团队对 API 这么做，却忘了对行为这么做——而设计师真正感受到的，是行为。
偏离的权利。 一个团队要做系统不支持的事，必须有一条被记录在案的路径。书面的例外、经过评审，是系统在健康地呼吸；无声分叉，是同一个团队在黑暗里另建了一套系统。两者的差别完全是社会性的。
维护，而不是发布。 设计系统上线的那一刻，才是困难开始的那一刻。废弃需要通知，迁移需要日期，文档需要一个日历上有时间的主人。
设计系统成功的标志，不是组件被使用了，而是一个新来的工程师不用问任何人也能做出一个好页面。
它们真正的死因
设计系统很少死于组件做错了，它们死于社会性的欠债。
第一种是委员会评审：八个人，四种关于圆角的意见，每个 PR 六周。系统比本地复制一份还慢，于是本地复制变得理性。
第二种是没有答疑时间。如果问问题的唯一方式就是提 PR，人们就会停止提问，开始分叉。
第三种，也是我见过最多的：就这一次。我看过的每一个腐烂的系统，都是一次一个例外烂掉的。每个例外单独看都合理，没有一个人被记录。系统不是死于某个糟糕的决定，而是死于一千个没被讨论过的决定。
解法一点也不光鲜：每周留半小时，任何人都可以带一个问题来；一本在例会上翻开的例外记录；以及一条规矩——做出的偏离，谁上线，谁负责写下解释。
该测量什么
真正重要的指标是社会性的。一个新团队要多久才能做出一个一致的页面？界面工作里有多大比例用了系统组件，这个比例是否诚实？我们每个月批准的例外有多少，它们是否在向同一个缺失的组件收敛？
如果例外总是聚集在同一个缺失的东西周围，那这个系统不是在执行标准，它是在替你们提交需求。这是信息，不是失败。
契约会被重新谈判
「契约」这个词让系统听起来很硬，事实恰恰相反。契约只是一场对话被写了下来，好让它以后可以被重新打开，而不是每个迭代都从零开始重吵一遍。
把「为什么」写进文档。废弃旧组件时大声一点，给出日期和迁移指南。把争论排进日历，而不是等它自己找上门。并把这个库当作它本来的样子：共识的证据，而不是共识本身。
我合作过的最好的设计系统，组件比最差的那个更少。它每月开一次会，有一份非常无聊的更新日志，以及一个共享的理解：重点从来都不是那些按钮。