🌏 Read this article in English
Figma 裡那個「順手」的按鈕
Sandy 是剛進團隊的 UI 設計師。
她在 Figma 裡拖曳了一個非標準按鈕。
看起來很順手。
沒有選 Button 元件。沒有套 primary 樣式。只是手動拉了一個 Frame，填了個色碼 #1A2B3C。
效率很高。
三個月後，這個色碼散落在 12 個專案裡。
資深工程師花了一整天，修補 Design System 的樣式衝突。
這就是規模化的代價。
我們以為 Design System 是「元件庫」。
其實，它是「邊界」。
邊界太窄，產品長不出來。
邊界太寬，維護成本會吃掉團隊。
91 個元件夠嗎？
9 種品牌預設夠嗎？
答案是：不夠，但也沒那麼不夠。
關鍵是：下一步該補什麼？
Mockup 階段，元件庫不是第一優先
先說清楚。
在 Mockup 階段使用標準元件，不是壞事。
它讓視覺溝通更一致。
讓設計師不用擔心色碼對不對。
但問題是：在 Mockup 階段把元件當主角，探索就會變慢。
大多數團隊在 Mockup 階段，都在做邊際效益遞減的勞動。
設計師在 Figma 裡拖曳 Button、Input、Modal。
看起來很專業。
但這些元件在低保真 Mockup 階段，價值有限。
因為 Mockup 的目的是「視覺溝通」。
溝通需要靈活性。
你需要快速嘗試三種不同的佈局。
你需要手動調整一個按鈕的陰影。
如果你強迫設計師使用「標準元件」：
- 他們要 detach instance。
- 他們要手動對齊。
- 他們要擔心顏色變數有沒有綁對。
最後，設計師還是會手動改顏色。
因為標準元件的 primary 藍色，不符合他們當下的視覺構圖。
所以，低保真 Mockup 階段真正需要的只有一樣東西：
Design Tokens。
不是元件，而是 Tokens。
--color-primary-500
--spacing-md
--radius-lg
設計師只需要知道這些變數的名稱。
他們可以在 Figma 裡自由組合。
只要最終匯出時，透過 variables/style mapping 或 handoff 規範確認 token 對應即可。
具體來說，Mockup 階段的分層應該是：
| 層級 | 定義內容 | 低保真 Mockup | 高保真 Prototype / Implementation |
|---|---|---|---|
| Presets | Design Tokens | ✅ 需要 | ✅ 需要 |
| Constraints | 設計規則 | ✅ 需要 | ✅ 需要 |
| Components | 元件規格 | ⚠️ 看保真度 | ✅ 需要 |
低保真 Mockup 只需要 Presets + Constraints。
到了高保真 prototype，或要 handoff 給工程的階段，Components 才開始派上用場。
Implementation 階段，整套元件樹才會跑滿。
把元件庫強加給低保真 Mockup，就像試菜時逼廚師只用調味包。
味道當然會一樣。
但你嘗不出他想做什麼菜。
商用級 Design System，需要多少種品牌預設？
目前我們的 brand-presets 有 9 種。
default, tech, finance, healthcare, ecommerce, luxury, playful, minimal, creative。
看起來不少。
但讓我們看看市場。
如果你接一個政府標案。
你的 corporate 預設夠嚴肅嗎？
不夠。
政府網站需要更高的對比度，更保守的字體比例。
如果你接一個醫療 App。
你的 healthcare 預設夠溫暖嗎？
不夠。
醫療需要信任感，但不能太冷硬。
現況：9 種。
商用建議：12 種產業預設（Industry）打底，再加 3-6 個 mood modifier 疊加層。
為什麼是這個區間？
太少，覆蓋不到主流產業情境。
太多，維護成本會壓過品牌切換的便利性。
每個預設要定義 8-12 個核心 Tokens，加上範例截圖、Demo 頁面、持續更新。
從跟過幾個內部團隊的經驗看，能持續維護的合理上限大約落在 15-18 個常用組合。
再往上，Design System 慢慢就變成檔案管理系統，而不是設計工具。
產業別預設（Industry）- 12 種
這 12 種預設，大致覆蓋多數常見的 B2B 與 B2C 情境（最終覆蓋率取決於你的 client portfolio）。
| 預設 | 覆蓋產業 | 關鍵差異 |
|---|---|---|
corporate |
一般企業、B2B | 標準商務藍，穩重 |
finance |
銀行、保險、投資 | 高對比，嚴謹，信任感 |
healthcare |
醫療、藥品、健康 | 溫暖綠/藍，易讀性優先 |
ecommerce |
電商、零售 | 高轉化色調，強調 CTA |
tech |
科技新創、SaaS | 漸層，霓虹色，現代感 |
luxury |
高端品牌、時尚 | 低飽和度，高對比，留白 |
playful |
App、遊戲、兒童 | 圓角，鮮豔色，動畫友好 |
minimal |
日系、北歐、藝術 | 極簡，單色，大量留白 |
creative |
設計公司、藝術家 | 非對稱，實驗性排版 |
warm |
社群、公益、家庭 | 暖色調，柔和陰影 |
bold |
運動、音樂、年輕 | 粗體，高對比，衝擊力 |
government |
政府、公共建設 | 嚴謹，無襯線，高可讀 |
Mood Modifier — 疊加層
Mood 不是獨立的預設，是疊在產業預設上的修飾層。
例如 corporate + bold 用在企業內部活動頁，healthcare + warm 用在小兒科 App。
3-6 個 modifier 通常就夠用了，再多會跟產業預設互相幹擾。
但關鍵在於：
你不需要一開始就建齊 12 個產業預設。
你可以先建 corporate 與 tech。
當第二個產業需求來臨時，再複製並微調。
漸進改善 > 英雄式重構。
不要試圖一次預測未來五年的品牌需求。
市場訊號尚未明朗。
可以先處理今天最明確的需求，等市場訊號累積後再擴充。
91 個元件，真的夠嗎？
Leo 是我們團隊的工程師。
他問了一個很常見的問題：「我們有 91 個元件，還缺什麼？」
91 個元件覆蓋情況：
| 類別 | 狀態 | 範例 |
|---|---|---|
| 基礎 UI | ✅ 完整 | Button, Input, Select, Checkbox |
| 佈局 | ✅ 完整 | Grid, Space, Divider, Layout |
| 導航 | ✅ 完整 | Menu, Breadcrumb, Pagination, Tabs |
| 資料展示 | ✅ 完整 | Table, List, Card, Tree |
| 資料輸入 | ✅ 完整 | Form, Upload, DatePicker, Transfer |
| 回饋 | ✅ 完整 | Modal, Message, Notification, Progress |
| Pro 進階 | ✅ 完整 | ProTable, ProForm, ProLayout |
91 個元件 = 企業應用大多數場景足夠。
剩下的部分呢？
專業領域元件。
| 類別 | 元件 | 建議方案 |
|---|---|---|
| 資料視覺化 | Charts, Graphs | 整合 ECharts / G2 |
| 富文字 | Rich Text Editor | 整合 TipTap / Quill |
| 拖放 | Drag & Drop, Kanban | 整合 dnd-kit |
| 時程 | Gantt, Calendar | 整合 FullCalendar |
| 地圖 | Map | 整合 Mapbox / Leaflet |
| 程式碼 | Code Editor | 整合 Monaco / CodeMirror |
核心元件可自建或包裝，專業領域元件應優先整合。
這不是技術選擇，是資源分配的取捨。
工程師想：「我們能不能自己寫一個 Chart 元件，完全符合 Design System 的風格？」
答案是：可以，但代價很高。
Chart.js, ECharts, G2 這些庫，累積了多年社群使用、issue 修補與瀏覽器相容性處理。
成熟圖表庫在效能、可訪問性、瀏覽器相容性上，通常高於兩週自建初版。
取捨很明確：
- 核心 UI 元件（Button, Input, Modal）：可自建或包裝 headless/unstyled/成熟庫，但 API 與 tokens 由系統統一。
- 專業領域元件（Chart, Map, Editor）：優先整合第三方。因為這關係到效能與專業度。
具體來說，你的 Design System 應該提供「整合指南」。
而不是「整合元件」。
整合指南告訴工程師：
- 如何安裝 ECharts。
- 如何設定主題變數（Theme Tokens）。
- 如何處理響應式佈局。
- 如何確保無障礙（Accessibility）。
這樣，你既保持了品牌一致性，又避免了維護龐大的第三方程式碼。
分層設計：Presets → Constraints → Components
Design System 的規模，取決於你的分層策略。
最底層是 Presets（Design Tokens 的集合）。
數量建議 12 種產業預設加上 3-6 個 mood modifier。
目的是快速切換品牌風格。
每個預設需要 8-12 個核心 Tokens。
再上一層是 Constraints（設計規則）。
定義元件的使用邊界。
什麼情況下用 Primary Button？什麼情況下用 Text Button？
目的是讓自由探索有清楚邊界，減少跨角色理解落差。
維護以文件為主，程式碼為輔。
最上層才是 Components（可運行的 UI 組件）。
數量約 91 個核心元件。
目的是加速開發，確保一致性。
維護以程式碼為主，文件為輔。
這三層是分開的。
Presets 可以獨立更新。
Constraints 可以獨立修訂。
Components 可以獨立升級。
不要把它們混在一起。
不然改一個顏色，要回頭測 50 個元件。
我看過團隊在這上面卡兩週。
規模化的瓶頸不是元件數量，是邊界清晰度。
邊界，畫在哪？
Design System 不是專案。
它是基礎設施。
基礎設施的好壞，不會在第一天顯現。
但會在第一年顯現。
當你的團隊從 5 人成長到 50 人。
當你的產品從 1 個擴展到 10 個。
當你的品牌從 1 個擴展到 5 個。
你會感謝當初做了正確分層的自己。
Design System 不是為了讓今天更快。
而是為了讓明天的擴張仍有可維護的邊界。
但維護壓力的臨界點，每個團隊不同。
你的 Design System 今天還在加元件，還是在畫邊界？
Sources
- Ant Design Component List — 企業級 UI 元件庫參考
- Brad Frost: Atomic Design — 設計系統分層理論基礎
- Design Tokens W3C Community Group — Design Tokens 社群技術報告
- Spotify Design: Scaling our Design System — 大型團隊設計系統規模化實戰