如果你在團隊裡做過中大型專案，一定體會過這種痛苦：每個設計師的按鈕長得不一樣、間距沒有統一的規則、改一個品牌色要打開二十幾個檔案一個一個改。設計系統就是為了解決這些問題而存在的。而 Atomic Design 是我認為最適合在 Figma 裡建立設計系統的方法論——它有清晰的層級結構、容易理解、也容易維護。今天就來完整走一遍。

Atomic Design 方法論快速理解

Brad Frost 提出的 Atomic Design 把設計元素分成五個層級：Atoms（原子）、Molecules（分子）、Organisms（組織）、Templates（模板）、Pages（頁面）。在 Figma 裡我們主要處理前三層——Atoms、Molecules、Organisms——因為 Templates 和 Pages 通常就是用這些元件組合出來的具體設計稿。

用白話來說就是：按鈕是原子、搜尋列（輸入框 + 按鈕）是分子、整個導航列（Logo + 選單 + 搜尋列 + 使用者頭像）是組織。每一層都是由下一層的元件組合而來的。這樣做的好處是，當你改了按鈕的圓角，所有包含按鈕的分子和組織都會自動更新。

Atoms 原子層：基礎設計 Token

色彩系統

色彩是設計系統最底層的原子。我的建議是用 Figma 的 Variables 功能（而不是傳統的 Color Styles）來管理色彩。先定義一組語意化的色彩名稱——Primary、Secondary、Surface、OnSurface、Error、Success 等——然後為每個名稱設定 Light Mode 和 Dark Mode 兩組值。這樣切換深淺色主題只需要切換 Variable Mode 就好。更深入的 Variables 用法可以參考Figma Variables 與 Design Tokens 教學。

字型比例

定義一組字型比例（Type Scale），我推薦用 Major Third (1.25) 或 Perfect Fourth (1.333) 的比例關係。實際的設定大概是：Display（36px）、H1（28px）、H2（24px）、H3（20px）、Body（16px）、Caption（14px）、Overline（12px）。每個層級都要定義好 font-family、font-weight、line-height 和 letter-spacing。在 Figma 裡用 Text Styles 來管理。

間距與網格

間距用 4px 為基準單位，建立一組間距 token：4、8、12、16、20、24、32、40、48、64、80。不要用任何不在這組數值裡的間距。這聽起來很嚴格，但它能保證整個產品的視覺節奏是一致的。

Atoms 元件：按鈕、輸入框、圖示

有了設計 Token 之後，就可以開始做原子級元件了。按鈕的 Component 我會設定這些 Properties：Variant（Primary / Secondary / Ghost）、Size（S / M / L）、State（Default / Hover / Pressed / Disabled）、有沒有 Icon、Icon 在左邊還是右邊。用 Figma 的 Component Properties 搭配Auto Layout，可以讓一個 Component 涵蓋所有變體。

輸入框也是類似的邏輯：Size（S / M / L）、State（Default / Focus / Error / Disabled）、有沒有 Label、有沒有 Helper Text、有沒有前綴或後綴圖示。這些 Properties 設定好之後，使用的人只需要在右側面板切換就能得到正確的版本，完全不需要手動調整。

Molecules 分子層：組合出實用模組

分子是由兩個以上的原子組合而成的。常見的分子元件有：搜尋列（輸入框 + 按鈕）、表單欄位（Label + 輸入框 + Error Message）、導航連結（圖示 + 文字）、卡片標頭（頭像 + 名稱 + 時間標籤）。

做分子元件的重點是保持彈性。不要把尺寸寫死——用 Auto Layout 的 Fill Container 讓元件能自適應寬度。間距使用前面定義好的間距 token，不要手動輸入數值。每個分子元件裡面嵌套的原子元件，一定要使用 Instance（實例）而不是 Detach 後的普通圖層，這樣原子層的修改才能正確傳遞下去。

Organisms 組織層：完整功能區塊

組織是最複雜的元件層級，它組合了多個分子和原子來完成一個完整的功能。舉例來說：Header 組織（Logo + 導航選單 + 搜尋列 + 使用者選單）、卡片組織（卡片圖片 + 卡片標頭 + 卡片內容 + 卡片操作按鈕）、表單組織（多個表單欄位 + 提交按鈕）。

在 Figma 裡做 Organism 時，我建議善用 Section 功能來組織圖層結構。一個 Header 組織裡面可能有十幾個圖層，如果沒有好的命名和分組，三個月後連你自己都看不懂。我的命名慣例是：[Layer Type] / [Function] / [Detail]，比如 Icon / Navigation / Menu。

元件庫發布與團隊協作

元件做好之後，要發布為 Team Library 讓整個團隊使用。發布前的幾個檢查重點：每個元件都要有清楚的描述（Description）、每個 Property 都要有合理的預設值、元件的命名要遵循一致的規則（我用 Category / Component Name 格式，比如 Button / Primary）。

發布後的維護同樣重要。建立一個 Changelog 頁面，記錄每次更新的內容。當你修改了某個元件，Figma 會自動通知使用這個元件的設計檔案——但你需要在 Changelog 裡說明「為什麼改」和「可能的影響」，這樣團隊成員才知道要不要更新。和工程師的交接則可以善用Figma Dev Mode 來確保設計稿的還原度。

設計系統的治理與演進

設計系統不是做完就不管了。我建議建立一個簡單的治理流程：有人想新增元件時，先在 Slack 頻道提出需求和使用場景；團隊討論是否需要新元件還是可以用現有元件組合；決定新增的話，指定一個人負責做，做完後由至少一個人 Review；通過後發布到 Library 並更新文件。更完整的設計系統建立方法論可以參考這篇深度指南。

另外，每個月做一次「設計債務清理」——檢查有沒有 Detached 的 Instance、有沒有用到不在系統裡的顏色或字型、有沒有重複的元件可以合併。這些小事積少成多，不處理的話設計系統會慢慢失去它的價值。一個好的設計系統應該是活的、持續演進的，而不是一次性的交付物。