🌏 Read this article in English
9 個 Preset 的疲勞戰
PM 把 Figma 檔丟給你。
「這個要快。」
打開一看。brand-system-v9-final-final-2.fig。
9 個 Preset。Finance, Healthcare, E-commerce…
每個都長得差不多。
但這次客戶要的是「金融業的嚴肅」加上「科技業的輕快」。
沒有這個選項。
要麼改 Finance 範本（影響所有其他銀行客戶）。 要麼手動複製一份，改名為 Finance-Tech-Style,然後逐個元件調整顏色。
手動複製。
然後在另一個案子裡,客戶要「醫療業的大字體」,但用「電商的高對比色」。
又是手動複製。
翻了一下時間紀錄(這是團隊內部的估算,不是公開研究數據)。
過去半年,光是客製化 Preset 就吃掉 40 小時——複製檔案、改 token、QA 對齊,大概各佔三分之一。
40 小時。
換來 3 個 Figma 檔,差別只在 Primary Color。
這很正常。
可優化的地方是:
我們一直在用「加法」解決「乘法型成本」的挑戰。
扁平 Preset 的邊界
大多數 Design System 的起步,都是扁平的。
Preset 1: Finance Preset 2: Healthcare … Preset N: Startup
每個 Preset 都是一個封閉的盒子。
盒子裡混了:
- 視覺風格(Typography, Spacing, Border Radius)
- 品牌色彩(Primary, Secondary, Semantic)
- 產業模式(Hero 區塊類型、術語、合規需求)
這很正常。
當你的客戶只有 5 個,且需求不重疊時,這是最快的方式。
但隨著客戶超過 10 個,且需求開始交叉,扁平 Preset 的可預測性會下降。
組合爆炸。
Definition:這裡說的「Preset artifact」指一個完整的 Figma 檔(或一份綁定的 token 套組),包含風格、色彩、產業模式三件事綁在一起。
如果你有 6 種視覺風格,10 種產業模式。 扁平架構下,你需要 6 × 10 = 60 個 Preset artifact。
如果再加 10 種品牌色? 60 × 10 = 600 個 Preset artifact。
600 個 Figma 檔案。
維護成本是天文數字。
而且,這還只是「理論值」。
實際情況更糟:
因為顏色和風格是綁定的,你無法單獨替換。
你想把「醫療業的區塊」套上「科技業的配色」?
不行。因為「醫療業 Preset」裡的區塊已經寫死了顏色變數。
你必須手動解耦。
手動。
Key Insight:扁平架構的維護成本是
Style × Color × Industry(乘法)。當任一維度增加,工作量都是按倍數放大,不是按加法。
這就是為什麼 Design System 越做越大,卻越來越難用。
分層:Style × Color × Industry
先拆骨架。
Layer 1: Style (骨架)
Junior 第一次聽到分層,通常會問:「Style 不就是長相嗎?」
不是。Style 是骨架,不是長相。
骨架不含色彩。
它定義:
- Typography(字體、字重、行高)
- Spacing(間距比例、留白策略)
- Border Radius(0px 銳利 vs 24px 圓潤)
- Shadows(無 / 輕 / 重)
- Motion(無動畫 / 微妙 / 活潑)
範例:
Minimal:Inter, 無邊框, 無陰影, 大留白Bold:Roboto Slab, 粗字重, 銳利邊框, 強陰影Playful:Nunito, 大圓角, 輕微彈性動畫
Style 不是長相,是比例與節奏。
它只負責「形狀」和「節奏」,不負責填色。
Layer 2: Color Scheme (皮膚)
Color 是皮膚。
PM 常問:「客戶有自己的品牌色怎麼辦?」
直接餵進去就好,不用重做骨架。
它定義:
- Primary / Secondary / Accent
- Semantic(Success / Warning / Error)
- Neutrals(Background / Text / Border)
這裡的關鍵是:
Color 可以預設,也可以生成。
如果客戶有品牌指南,輸入 HEX 值,生成初版色盤。 需要再驗證 WCAG 對比、深淺色模式與 semantic 狀態。 如果沒有,從 Style 預設的 10 種基礎色盤中挑選。
Color 不影響結構。它只影響「填色」。
Figma Variables 負責儲存與套用 token,色盤生成與 WCAG 驗證需由 plugin、腳本或 theme builder 完成。
Layer 3: Industry Patterns (血肉)
Industry 是血肉。
Industry 不是視覺風格,是內容怎麼排列。
它定義:
- 區塊類型(Hero, Features, Pricing, Testimonials)
- 術語/用語(金融用「申購」、醫療用「掛號」)
- UX 慣例(金融常見數據表、醫療常用大字體)
- 可能需要檢查的合規面向(例如 HIPAA, PCI-DSS——實際適用取決於業務範圍與地域)
Industry 不決定長相。
它決定「內容如何排列」和「如何表達」。
組合爆炸:從 600 個檔案到 28 個模組
現在,我們把三層分開。
| 層級 | 變化選項 | 數量 |
|---|---|---|
| Style | 6 種 (Minimal, Bold, Playful, Corporate, Tech, Elegant) | 6 |
| Color | 10 種基礎色盤 + ∞ 自訂色 | 10+ |
| Industry | 12 種模式 (Finance, Healthcare, E-commerce, SaaS, Education, Media, Non-profit, Government, Startup, Fintech, Edtech, Healthtech) | 12 |
理論組合,6 種風格 × 10 種色盤 × 12 種產業,大約 720 種。
聽起來比 600 多?
是的。但比較口徑不一樣。
扁平的 600 是 600 個要人維護的 artifact。 分層的 720 是 720 個可以即時組裝的結果——背後只有 6 + 10 + 12 = 28 個模組。
關鍵不在組合數量,而在維護成本的計算公式:
- 扁平架構:成本 =
S × C × I(乘法,任一維度 +1 都按倍數爆) - 分層架構:成本 =
S + C + I(加法,任一維度 +1 都只多一個檔案)
扁平架構下,新增一個產業模式,你要複製 6 個 Style,每個 Style 再複製 10 種 Color。 6 × 10 = 60 個檔案。
分層架構下,再加第 11 種產業?Style 和 Color 完全不用動。新增一個 JSON 就好。
因為它們是獨立的。
具體映射:Industry 到底影響什麼?
很多團隊會混淆「Industry」和「Style」。
他們以為「醫療業」就是「用綠色、大字體、圓角」。
這是常見的混淆。
Industry 影響的是內容與 UX 模式,不是視覺骨架。
下面三組是常見的預設組合(不是規定)——Industry 本身只負責中間那塊「Patterns」,Style 和 Color 是另外搭配上去的:
Finance(金融)— 常見組合
- 常搭 Style:Corporate(嚴謹、對齊、無動畫)
- 常搭 Color:Deep Blue(信任、重穩)
- Industry Patterns(Industry 真正定義的部分):
- Hero 區塊:強調「資產規模」與「合規牌照」
- Features:數據表格、利率計算機
- 術語:「申購」、「贖回」、「年化報酬率」
- 合規面向:可能需要檢查 PCI-DSS 標章、隱私政策連結(視業務範圍)
Healthcare(醫療)— 常見組合
- 常搭 Style:Minimal(清晰、無幹擾、大字體)
- 常搭 Color:Teal/Green(健康、平靜)
- Industry Patterns:
- Hero 區塊:強調「預約按鈕」與「醫師介紹」
- Features:症狀查詢、科室分類
- 術語:「掛號」、「就診」、「病歷」
- 合規面向:可能需要 HIPAA 聲明、醫療器材認證標章(視地域與業務範圍)
E-commerce(電商)— 常見組合
- 常搭 Style:Playful(高對比、強陰影、微動畫)
- 常搭 Color:Orange/Red(急迫感、行動呼叫)
- Industry Patterns:
- Hero 區塊:強調「限時優惠」與「購物車」
- Features:商品推薦、評價星星
- 術語:「加入購物車」、「結帳」、「折扣碼」
- 合規面向:Cookie 同意、退貨政策(視地域)
注意:
「常見組合」不是「綁死」。客戶完全可以拿 Healthcare 的 Patterns 套上 Tech 的 Style 和品牌色。
如果你把「醫療業的大字體」寫死在 Style 層,你就失去了彈性。
因為「科技業」也可能需要大字體(例如:針對年長用戶的 App)。
Industry 應該只定義「內容結構」與「UX 慣例」。
Style 定義「比例」。
Color 定義「品牌」。
取捨:什麼情況下不適合分層?
先說清楚,扁平 Preset 在初期是對的。
它有明確的適用邊界。
分層架構不是每個工作流都需要。
如果你的團隊只有兩個人,或許先保留扁平架構。
分層的複雜度,可能高於它帶來的收益。
適合分層的情況
- 客戶多且需求交叉:例如,你有 20 個客戶,每個都要不同的品牌色,但共用相同的產業模式。
- 團隊規模大:設計師、前端、PM 需要獨立工作。分層讓每個人只關注自己的層級。
- 長期維護:Design System 預計使用超過 2 年。分層讓更新成本可控。
不適合分層的情況
- 單一專案:如果你只服務一個客戶,且需求明確,扁平 Preset 更快。
- 需求高度客製化:如果每個專案都需要 80% 的客製化,分層架構的「標準化」優勢就消失了。
- 團隊規模小:如果只有 1-2 個設計師,分層架構的「解耦成本」可能高於「維護成本」。
判斷準則:
如果你的團隊花在「複製 Preset」和「手動調整顏色」的時間,超過「設計新區塊」的時間,分層會是一個值得考慮的方向。
如何開始:三步驟落地
不需要重寫整個 Design System。
從最小可行單位開始。
Step 1: 解耦 Style 與 Color
找出現有 Preset 中,哪些是「骨架」,哪些是「顏色」。
例如,Finance-Preset 中的 Typography 和 Spacing 是骨架。 Primary-Color 是顏色。
將骨架提取為 Style-Corporate.json。 將顏色提取為 Color-DeepBlue.json。
最小 token schema 範例:
// Style-Corporate.json (骨架,無色彩)
{
"typography": { "fontFamily": "Inter", "scale": [12,14,16,20,24,32] },
"spacing": { "base": 4, "scale": [0,4,8,16,24,32,48] },
"radius": { "sm": 2, "md": 4, "lg": 8 }
}
// Color-DeepBlue.json (皮膚,只有顏色)
{
"palette": { "primary": "#0B3D91", "secondary": "#5A8DEE" },
"semantic": { "success": "{palette.green.500}", "error": "{palette.red.500}" }
}
// Industry-Finance.json (血肉,只有內容/結構)
{
"blocks": ["hero.assets","features.dataTable","compliance.badges"],
"glossary": { "subscribe": "申購", "redeem": "贖回" }
}合併 precedence(後者覆蓋前者):
Style → Color(palette)→ 客戶 brand color → Semantic alias
也就是說:客戶輸入的 brand HEX 會覆蓋預設 palette,但 semantic token(success、error)維持別名引用——不要直接被 brand color 覆蓋,否則紅綠燈會錯亂。
Step 2: 定義 Industry Patterns
列出每個產業的「內容區塊」與「術語」。
例如,Industry-Finance.json 定義:
- Hero 區塊結構
- 數據表格區塊結構、欄位語意、資料呈現需求
- 術語庫
不要在 Industry Pattern 中定義顏色。
Step 3: 建立組合器
寫一個簡單的腳本(或 Figma Plugin),將三層組合起來。
輸入:
- Style:
Minimal - Color:
Brand-HEX-#123456 - Industry:
Healthcare
輸出:
- 完整的 Design Token JSON
- Figma 組件連結
- CSS Variables(注意:Figma 本身不會直接吐 CSS Variables——需要透過 Figma plugin、Variables REST API 或 build script(如 Style Dictionary)轉換匯出)
第一版不要寫太完美。但已經夠用了。
賣 Preset 還是賣 Platform
Design System 的終極目標,不是「提供更多 Preset」。
而是「讓客戶自己組合」。
這裡的 Platform 不是行銷詞。具體指三件事:
- 可組合:Style / Color / Industry 三層獨立,客戶能任意挑選與替換
- 可驗證:輸入 brand color 後,系統自動跑 WCAG 對比、semantic token 一致性
- 可重生:同一份組合輸入,任何時候都能重新生成 Figma 檔與 CSS Variables——不是手動複製出來的快照
當這三件事到位後,你不再是「賣 Preset」。
你是在「賣 Platform」。
客戶可以輸入自己的品牌色。 選擇自己的產業模式。 挑選自己的視覺風格。
然後,自動生成完整的 Design System。
這才是 Design 系統的規模化。
分層不是把系統切碎,是把選擇權還回去。
你的 Design System,現在是在賣 Preset,還是賣 Platform?
Sources
- Design Tokens W3C Community Group: Format Module — Design Token 格式與層級組合的官方草案規範
- Brad Frost: Atomic Design — 設計系統分層思維的經典參考(原子/分子/組織/範本)
- Nathan Curtis: Naming Tokens in Design Systems — Token 分層與 semantic alias precedence 的實務討論
- Figma: Variables and Modes — Figma Variables 的儲存與套用機制(待主編補件確認最新文件 URL)
- Style Dictionary — 將 design token 匯出為 CSS Variables / iOS / Android 的 build pipeline 工具