昨天把設計系統的變更發布收完了：semver 判準、Changesets、棄用三階段、雙層 changelog。版本推出去、tag 打好、公告發出,發布這條線就算閉環。但發布只是輸出,不是結果。真正的問題在下游：有沒有人升上來、有沒有人在用、還是各團隊繼續在自己的 repo 裡手刻一顆一樣的按鈕。今天就走到這一步——設計系統的採用度量與治理。前者回答「現在到底被用了多少」,後者回答「接下來誰有權決定系統長什麼樣」。這兩件事是一體兩面:沒有度量的治理只是喊口號,沒有治理的度量只是一張沒人負責的報表。
📖 學
先把「採用」這個詞拆開。多數團隊講採用率時腦中只有一個模糊的百分比,但實務上要分兩個維度看:廣度(usage)是有多少團隊、多少產品、多少畫面碰到了系統;深度(coverage)是在碰到的地方裡,系統佔了多少比例。廣度告訴你系統擴散得多遠,深度告訴你擴散得多實。一個系統可能十個產品全都 import 了(廣度 100%),但每個產品都只用了 Button 跟 Icon,剩下全部手刻(深度 15%)。只看廣度會嚴重高估自己。
覆蓋率是最值得投資的指標型態,因為它是比值,任何角色都看得懂。元件覆蓋率定義如下:
元件覆蓋率 = 來自設計系統的元件實例數 ÷ 畫面上所有元件實例數分母怎麼算,決定這個數字誠不誠實。三種算法各有偏誤:靜態掃描數程式碼裡的 import 來源,最便宜、CI 就能跑,但一個 import 被 render 一次還是一千次它分不出來;渲染計數在 runtime 統計渲染次數,最貼近真實使用密度,代價是要埋遙測;視覺覆蓋算畫面上有多少像素面積由系統元件產生,最好拿去給主管看,但實作成本最高。剛開始就用靜態掃描,先有趨勢再談精度。
代幣層也要有自己的比值,而且它比元件更能反映真實紀律:
代幣覆蓋率 = 使用 token 的樣式宣告數 ÷ (顏色 + 間距 + 字級) 全部宣告數
硬編碼債 = 程式碼中寫死的 hex / px / rem 出現次數代幣覆蓋率往上、硬編碼債往下,才叫真的在收斂。硬編碼債好用的原因是不需要任何工具,一行 grep 就能算,只要進 CI 趨勢就存下來了。絕對值不重要,方向才重要。
然後是承昨天發布那條線直接接下來的兩個指標。既然你已經在發版,你就有版號可以量:
版本落後距離 version lag = 各下游目前版號與 latest 之間的 major/minor 差距
升級延遲 upgrade latency = 從發版到「一半的下游」升上該版所經過的天數(P50)這兩個數字是昨天的成績單。棄用公告發了三個月、還有一半產品停在兩個 major 之前,那不是下游懶,是遷移成本被低估了——通常代表 codemod 沒寫,或 breaking 判準太鬆。而且多版本並存會讓 VRT 基準圖分裂,前天那條線也跟著爛掉。
治理面則看貢獻。Nathan Curtis 給了一個很嚴的定義:任何由非核心團隊成員完成、並且透過系統釋出給其他人重用的提案、設計、程式或文件。重點在後半句——在自己產品裡刻一顆好元件不算貢獻,走完釋出流程、變成別人可以 import 的東西才算。所以:
貢獻率 = 非核心團隊完成並釋出的變更數 ÷ 全部已釋出變更數| 指標 | 讀出什麼 | 常見陷阱 |
|---|---|---|
| 元件覆蓋率 | 採用深度 | 分母定義不清,數字無法跨季比較 |
| 代幣覆蓋率 / 硬編碼債 | 樣式紀律 | 只看絕對值不看趨勢 |
| 版本落後距離 | 發布流程健康度 | 只看平均,掩蓋落後最遠的那個團隊 |
| 升級延遲 P50 | 遷移成本是否被低估 | 沒有拆 major / minor 分開看 |
| 貢獻率 | 治理是否真的開放 | 把提 issue 也算成貢獻 |
| 覆寫率 / fork 數 | 系統的缺口在哪 | 當成違規紀錄而不是需求訊號 |
最後一列要特別講。覆寫率(元件被塞 className、style、或被包一層本地 wrapper 的比例)與本地 fork 數量是反指標,但別把它當違規紀錄拿去糾正人。它是全公司最誠實的需求清單:某個元件被覆寫五十次,說明系統缺一個 variant,不說明五十個工程師不守規矩。把覆寫熱點整理成「缺口清單」,下一季的路線圖就自己寫好了。
有了數字之後,治理要決定的是誰有權讓系統長大。常見三種模型:核心團隊獨佔(品質最穩但會變瓶頸)、聯邦式(幾個產品團隊各派代表共同治理)、開放貢獻(任何人都能提)。健康的路徑是從中央走向聯邦,而不是直接跳到全開放——開放貢獻真正的成本不在收下 PR,在收下之後誰維護一輩子。沒有寫明所有權交接的貢獻流程,只會把核心團隊壓垮。
所以貢獻流程至少要有四段:提案(RFC,先講問題不講元件)、準入標準(是否至少兩個產品需要?是否已有近似元件?是否符合現有 API 慣例、代幣、無障礙門檻?)、審核(誰有 merge 權)、以及維護歸屬。搭配分層很有效:核心層(core,有 SLA、有 VRT、有無障礙保證)、社群層(community,可用但品質承諾較弱)、實驗層(lab,隨時可能移除)。分層讓你可以在不稀釋核心承諾的前提下收下貢獻,也給貢獻者一條看得見的升級路徑。
一點產業現實。zeroheight 的 Design Systems Report 2026 結論並不樂觀:高層 buy-in 下滑、採用停滯;56% 的團隊已在用 AI,但只有 15% 覺得它符合期待;只有約 40% 建立了任何形式的 token pipeline。而 Sparkbox 的調查反覆指出:真正追蹤指標的團隊比例極低(2022 年只有 16%),但被自評為成功的系統裡,有 81% 都有明確的維護流程。決定系統活不活的不是元件數量,是有沒有人在看數字、有沒有人負責。
AI 產碼把賭注放大了。當 agent 依現有程式碼的 pattern 複製寫法,硬編碼債會被指數放大——一個寫死 #3B82F6 的舊元件,會變成十個新畫面的範本。反過來說,文件站與 MCP 端點現在也是採用管道:agent 讀得到你的代幣與元件 API,產出的程式碼就會自動落在系統裡。與其追著人開會推廣,不如把系統餵給他們的 agent。
節奏上不用做大儀表板。每月一次 review,固定看三個數字(覆蓋率、硬編碼債、升級延遲)加一份缺口清單,能分群看到哪個團隊落後,就足以支撐下一季的投資決策。唯一紅線:這些數字是路線圖的輸入,不是考核 KPI。一旦拿去打考績,下游第一件學會的事就是把手刻元件改名成看起來像系統元件。
🧠 記
- 發布是輸出,採用才是結果;版本推出去不等於有人升上來。
- 採用分兩維:廣度(多少團隊碰到)與深度(碰到的地方佔多少比例),只看廣度會嚴重高估。
- 覆蓋率是最值得投資的指標型態,因為它是比值,人人看得懂;但分母定義決定它誠不誠實。
- 三種覆蓋算法各有偏誤:靜態掃描便宜、渲染計數貼近真實、視覺覆蓋最好溝通;先求趨勢再求精度。硬編碼債用 grep 就能算,能直接進 CI。
- 版本落後距離與升級延遲 P50 是昨天發布流程的成績單;拉長通常代表 codemod 缺席或 breaking 判準太鬆。
- 覆寫率與 fork 數是反指標,但它是全公司最誠實的需求清單,不是違規紀錄。
- 貢獻的定義是「非核心成員完成、且透過系統釋出給他人重用」;沒寫明維護歸屬的貢獻流程會壓垮核心團隊,分層(core / community / lab)可以收下貢獻又不稀釋核心承諾。
- 度量是路線圖輸入,不是考核 KPI;一旦拿去打考績,數字立刻失真。
✍️ 實踐
挑一個實際在跑的產品 repo,用 15 分鐘算出你的第一版採用基線,不要開任何工具。
- 算元件覆蓋率(靜態版)。在
src底下數兩個數字:從設計系統套件 import 的元件出現次數,以及本地元件的出現次數。rg -o "from '@your-ds/[a-z-]+'" src | wc -l rg -o "from '\./components/[A-Z][A-Za-z]+'" src | wc -l - 算硬編碼債。數寫死的顏色值:
rg -o "#[0-9a-fA-F]{3,8}" src | wc -l。把這個數字寫下來,附上今天日期。 - 抓覆寫熱點。找出被塞
className或style最多次的三個系統元件,這就是缺口清單第一版。 - 查版本落後距離。看
package.json裡的版號,對照最新版差幾個 minor / major。差距大於一個 major,就在旁邊寫一行原因。 - 記成一張表,五欄:日期、覆蓋率、硬編碼數、落後版號、缺口 top 3。存進 repo 的
docs/或系統的文件站。
一個月後再跑一次同樣的指令。有兩個時間點就有趨勢,有趨勢就有討論的依據,這比任何一次性的漂亮數字都有用。
🔗 延伸學習
- Defining Design System Contributions — Nathan Curtis / EightShapes:把「貢獻」定義到可量測的程度,是治理設計的起點。
- Measuring Design System Success — Nathan Curtis / EightShapes:用 OKR 把採用指標接回組織目標,而不是孤立看百分比。
- Design Systems Report 2026 — zeroheight:2026 年的產業現況,buy-in、採用停滯與 AI 使用比例的第一手數據。
- Building a design system adoption metric from production data — Mews:把設計系統當產品經營,從生產資料算覆蓋率的實作紀錄。
💬 問 AI
1. 我要為一個有 8 個下游產品的設計系統建立第一版採用度量。請幫我設計 5 個指標,
每個都要給出精確的分子與分母定義,並說明用靜態程式碼掃描能算到什麼程度、
哪裡必須改用 runtime 遙測。
2. 我要把元件覆蓋率算進 CI。請給我一個 Node 腳本的設計方案:掃描 src 下所有 JSX,
分別統計 @our-ds 與本地元件的實例數,輸出 JSON,覆蓋率下降超過 2% 就讓 job 失敗。
請說明 re-export、alias、動態 import 會造成哪些誤判。
3. 我的系統目前是核心團隊獨佔,想開放成聯邦式治理。請幫我寫一份貢獻流程文件的骨架:
RFC 模板、準入標準檢查表(至少涵蓋需求普遍性、API 慣例、代幣、無障礙)、
審核角色分工、以及 core / community / lab 三層各自的品質承諾與 SLA。
4. 我們某個元件在 6 個產品裡被塞了 40 次 className 覆寫。請設計一個分析流程,
從覆寫反推該新增哪些 variant、哪些該拒絕,並說明「該進系統」與
「產品專屬需求」的界線怎麼判。
5. 我要向不懂設計系統的高階主管報告採用成效,只能用三張圖。請告訴我選哪三個指標、
用什麼圖表形式、每張圖旁邊那一句結論怎麼下,避免變成「我們做了很多元件」的自我陳述。