Figma 設計系統是什麼？它和 UI Kit 差在哪？
Figma 設計系統是在 Figma 中管理樣式、變數、元件、文件與協作規則的一套工作系統；UI Kit 通常只是其中的視覺元件集合。真正可維護的 figma設計系統，要能支援設計交付、前端元件庫對接、版本控管與治理。
設計系統不只是 UI Kit
UI Kit 會提供按鈕、輸入框、卡片、色票與版型範例，但它通常不會回答「這個元件什麼時候能用」、「狀態怎麼命名」、「變更後誰要同步工程端」。設計系統要多一層規則，讓團隊在做新畫面時不必每次重新判斷。
| 比較項目 | UI Kit | Figma 設計系統 |
|---|---|---|
| 核心內容 | 視覺元件與範例畫面 | Foundations、Components、Patterns、Documentation、治理規則 |
| 使用者 | 多半是設計師 | 設計師、PM、前端工程師、Design Engineer |
| 維護重點 | 外觀一致 | 命名、狀態、Token、使用情境、版本控管一致 |
| 交付價值 | 加快畫面產出 | 降低重工，讓設計與開發共用同一套規則 |
Figma 在設計系統裡扮演什麼角色
Figma 是設計系統的工作空間與協作介面。它可以承載 Color Styles、Text Styles、Effect Styles、Grid Styles、Variables、Component、Variants、Properties、Instance 與文件頁，也能透過 Library 發布給其他檔案使用。
我的判斷是，Figma 最適合當「設計端的單一事實來源」，但不應該被當成工程端唯一來源。當 Design Tokens 要進到 CSS Variables、Tailwind Config 或 React Components 時，還是需要工程端有對應規則。
什麼情況下團隊真的需要設計系統
只要同一產品有多人維護、同一按鈕出現不同高度、不同頁面的錯誤訊息顏色不一致，或設計交付常被工程師追問狀態規則，就代表團隊已經需要設計系統。小團隊不一定要做企業級規格，但需要一套最小可用規範。
- 同一類元件在不同頁面被重複設計。
- 設計稿和前端元件庫命名不同步。
- 新設計師加入後，需要大量口頭說明才能接手。
- 改品牌色、文字尺寸或間距時，需要逐頁人工修改。
建立 Figma 設計系統前，先決定系統成熟度
Figma 設計系統建立前，最重要的決策不是先做幾個元件，而是先決定成熟度。個人 UI Kit、小型團隊元件庫、跨產品設計系統與企業級系統，所需的治理深度完全不同。
Level 1 個人 UI Kit
Level 1 適合個人作品、單一網站或早期產品。重點是整理常用顏色、文字樣式、Button、Input、Card，先讓自己不重複畫同一套東西。
Level 2 小型團隊元件庫
Level 2 適合 2 到 5 人的設計或產品團隊。此時要開始建立命名規則、Library 發布方式、元件修改權限與基本 Changelog，避免每個人各自拉出一份元件改版。
Level 3 跨產品設計系統
Level 3 適合多條產品線或多個功能團隊共用同一套 Figma Library。重點會轉向語意 Token、主題模式、前端元件庫對接，以及跨產品 Pattern 的一致性。
Level 4 企業級設計系統
Level 4 需要專職維護、版本策略、Design Tokens 管線、文件站與更正式的治理流程。台灣多數團隊不需要一開始就做到這個層級，過早追求完整，反而容易讓系統變成沒人敢改的展示品。
| 成熟度 | 適用情境 | Figma 產出物 | 治理深度 |
|---|---|---|---|
| Level 1 個人 UI Kit | 個人、單一作品、早期原型 | 基礎樣式、少量元件 | 低，靠個人習慣維護 |
| Level 2 小型團隊元件庫 | 小型產品團隊 | Library、命名規則、常用元件 | 中，需要修改規則 |
| Level 3 跨產品設計系統 | 多產品、多設計師、多工程端 | Variables、Patterns、文件頁、Changelog | 高，需要版本控管 |
| Level 4 企業級設計系統 | 大型組織或多品牌平台 | Design Tokens 管線、文件站、完整治理 | 很高，需要明確負責人 |
Figma 設計系統的 5 個基礎模組
一套可用的 Figma 設計系統至少要包含色彩系統、文字系統、圖示系統、元件系統、文件與使用規範。少了文件與規則，元件再漂亮也很難被團隊長期採用。
色彩系統
色彩系統要包含品牌色、語意色、狀態色、背景色、文字色與邊框色。不要只放一排色票，還要寫清楚使用情境，例如 primary/action/default、text/primary、background/surface。
文字系統
文字系統要定義標題、內文、輔助文字、表單提示、按鈕文字等層級。Text Styles 適合管理字級、行高、字重與段落規則；當團隊有多品牌或多模式需求時，可再搭配 Variables 管理字體相關 Token。
圖示系統
圖示系統要先統一尺寸、線寬、填色規則與命名方式。圖示不只是在 Figma 裡好找，也要方便前端轉成 icon component 或對接既有 icon package。
元件系統
元件系統是 Figma Component、Variants、Properties、Instance 與 Override 的集合。好的元件要能處理狀態、尺寸、圖示位置、文字長度與禁用情境，而不只是畫出一個預設外觀。
文件與使用規範
文件要回答三件事：什麼時候用、怎麼用、什麼時候不要用。我的經驗是，很多設計系統失敗不是因為元件不夠多，而是文件沒有把限制寫清楚，導致大家回到舊習慣。
| 模組 | 主要產出物 | 維護重點 |
|---|---|---|
| Color System | 品牌色、語意色、狀態色、文字色、背景色 | 語意命名與主題模式 |
| Typography | 標題、內文、輔助文字、按鈕文字 | 字級、行高、字重一致 |
| Icons | 圖示尺寸、命名、狀態 | 與前端圖示來源同步 |
| Components | Button、Input、Select、Modal、Card | 狀態、屬性、限制與範例 |
| Documentation | 使用情境、錯誤用法、Changelog | 讓團隊知道何時該用哪個規則 |
從 0 到 1 建立 Figma 設計系統的建議順序
Figma 設計系統建立的建議順序是：盤點現有畫面、建立 Design Tokens、設定 Styles 與 Variables、製作高頻元件、補文件、發布 Library，最後用 Audit 維護。
Step 1 盤點現有畫面與重複樣式
先從現有產品畫面抓出重複出現的顏色、字級、按鈕、表單、卡片與導航。不要憑想像建立系統，因為系統要服務真實畫面，而不是只服務理想版型。
- 整理所有常見按鈕樣式與狀態。
- 找出重複文字層級，例如 H1、H2、body、caption。
- 標記重複色彩與不一致色碼。
- 記錄工程端已存在的 CSS Variables 或元件命名。
Step 2 建立 Design Tokens 與命名規則
Design Tokens 是設計決策的命名資料，例如 color.action.primary、space.4、radius.md。先命名 Token，再建立 Figma Variables，後續才有機會和 CSS、React、Tailwind 對上。
Step 3 建立 Styles 與 Variables
Styles 適合設計師直接套用固定視覺樣式；Variables 適合管理語意值、模式切換與工程對接。兩者要一起規劃，不要把所有東西都塞進 Styles，也不要為了新功能而把 Figma 檔案弄得難懂。
Step 4 建立高頻元件
第一批元件應該從高頻、低爭議、跨頁面重複出現的元件開始，例如 Button、Input、Checkbox、Radio、Select。這些元件最能快速降低重工，也最容易暴露命名與狀態規則是否合理。
Step 5 補上文件與使用情境
每個核心元件至少要有用途、屬性、狀態、限制、範例與錯誤用法。文件越接近實際決策，越能減少 Slack、會議與設計交付中的來回確認。
Step 6 發布 Library 並建立維護節奏
完成第一版後，透過 Figma Library 發布給其他檔案使用，並建立固定維護節奏。小團隊可以每兩週檢查一次元件需求，大團隊則需要更正式的版本控管與 breaking change 流程。
Styles 和 Variables 怎麼分工？
Styles 適合管理設計師常套用的視覺樣式，Variables 適合管理可被命名、切換、對接工程的語意值。Figma Variables 更接近 Design Tokens，常用於色彩、間距、尺寸與模式切換。
什麼情況用 Styles
Color Styles、Text Styles、Effect Styles、Grid Styles 適合用在設計師需要快速套用、視覺上相對固定的規則。例如 body text、card shadow、desktop grid 都適合保留為 Styles。
什麼情況用 Variables
Variables 適合用在需要語意命名、主題切換或工程對接的值，例如 color/text/primary、color/bg/surface、space/16、radius/sm。深色模式、品牌主題、狀態色切換也適合用 Modes 管理。
色彩、間距、尺寸、主題模式的命名範例
| 需求 | 建議使用 | 命名範例 | 原因 |
|---|---|---|---|
| 固定文字樣式 | Text Styles | text/body/md | 方便設計師套用 |
| 語意色 | Variables | color/action/primary | 可對應 Design Tokens |
| 深色模式 | Variables Modes | light、dark | 可同名切換不同值 |
| 間距系統 | Variables | space/4、space/8、space/16 | 可與 CSS Variables 或 Tailwind spacing 對應 |
| 陰影 | Effect Styles | effect/shadow/card | 設計端使用直覺 |
不要用視覺名稱當長期 Token 名稱
blue-500、gray-100 這類名稱適合當原始色階，不適合直接當產品語意。當 primary action 從藍色改成綠色時，color/action/primary 不需要改名；blue-500 卻會讓設計與工程都陷入語意混亂。
Color System 要怎麼設計，才不會只是色票？
Color System 要把品牌色、語意色、狀態色、文字色、背景色與邊框色分開命名，並在 Figma Variables 中標註用途。只列色碼不能支援設計交付，也很難和前端元件庫對接。
品牌色與語意色要分開
品牌色是品牌識別的一部分，語意色是產品操作規則。品牌主色可以叫 brand/primary，但按鈕主操作應該叫 action/primary。兩者可能同色，也可能在不同主題下分開。
狀態色要對應成功、警告、錯誤、提示
狀態色要能支援成功、警告、錯誤、提示，也要包含文字、背景、邊框的不同使用位置。只定義一個 error red，到了表單錯誤、toast、alert、inline message 時就會不夠用。
深色模式與主題切換的變數結構
深色模式建議用同一組語意 Token 搭配不同 Modes。設計師在畫面上仍使用 color/bg/surface、color/text/primary，切換 light 或 dark 後，底層值由 Variables 控制。
常見錯誤：直接用 blue-500 當產品語意
blue-500 可以存在於 primitive token，但不應該直接成為按鈕、連結、提示訊息的長期命名。產品語意要回答用途，不只是描述顏色。
| 分類 | 命名範例 | 使用情境 |
|---|---|---|
| 品牌色 | color/brand/primary | 品牌識別、重點視覺 |
| 操作色 | color/action/primary | 主要按鈕、主要連結 |
| 文字色 | color/text/primary | 主要內容文字 |
| 背景色 | color/bg/surface | 卡片、面板、彈窗背景 |
| 狀態色 | color/status/error/text | 錯誤訊息文字 |
從哪些元件開始建立你的第一套設計系統？
第一套 Figma Component 應從 Button、Input、Form Controls 開始，再往 Card、Modal、Navigation 擴充。優先處理高頻元件，才能最快改善設計一致性與開發交付效率。
先做 Button、Input、Form Controls
Button、Input、Checkbox、Radio、Select 是多數產品最常出現的元件，也最容易因狀態不清造成重工。先把 default、hover、pressed、disabled、error、focus 等狀態整理好。
再做 Card、Modal、Navigation
第二批可以處理 Card、Modal、Tabs、Breadcrumb、Pagination、Navigation。這些元件通常牽涉版面結構與內容密度，最好等基礎 Token 和表單規則穩定後再建。
用 Variants 管理狀態
Variants 適合管理同一元件的狀態、尺寸、類型與互動樣式，例如 Button 的 type、size、state。Variant 命名要讓 Instance 使用者看得懂，不要只對建立元件的人有意義。
用 Properties 降低 Variant 爆炸
Properties 可以管理文字、圖示開關、Instance Swap、布林切換與內容替換。當按鈕有 icon left、icon right、loading、full width 等變化時，用 Properties 通常比新增大量 Variants 更好維護。
Instance Swap 適合用在哪些場景
Instance Swap 適合用在圖示、Avatar、Badge、表格 cell 內的小元件。設計師可以在不 detach Instance 的情況下替換局部內容，主元件也能保留一致規則。
| 優先順序 | 元件 | 先處理的屬性 | 原因 |
|---|---|---|---|
| 1 | Button | type、size、state、icon | 跨頁面高頻使用 |
| 2 | Input | state、label、helper text、error | 表單一致性最常出問題 |
| 3 | Form Controls | checked、disabled、error | 互動狀態需要清楚 |
| 4 | Card | padding、media、content density | 影響資訊層級 |
| 5 | Modal、Navigation | layout、action、responsive | 牽涉流程與版面規則 |
Figma 頁面結構與命名範本
Figma 頁面結構建議從 00 Cover、01 Foundations、02 Colors、03 Typography、04 Icons、05 Components、06 Patterns、07 Documentation 到 08 Changelog。清楚的頁面與命名規則，是設計系統可維護的基礎。
建議頁面架構
- 00 Cover：系統名稱、版本、負責人、更新日期。
- 01 Foundations：Token 原則、間距、圓角、陰影、Grid。
- 02 Colors：品牌色、語意色、狀態色、主題 Modes。
- 03 Typography：文字層級、字重、行高、使用情境。
- 04 Icons：圖示規則、尺寸、命名、替換方式。
- 05 Components：Button、Input、Select、Modal 等核心元件。
- 06 Patterns：表單、列表、空狀態、錯誤狀態等組合規則。
- 07 Documentation：使用規範、限制、錯誤用法。
- 08 Changelog：版本控管、breaking change、更新紀錄。
Layer、Component、Variable 命名規則
命名要讓設計、PM、工程都能理解。Component 可以使用 Button/Primary/Medium，Variable 可以使用 color/action/primary，Layer 則要避免 Rectangle 123、Frame 99 這類無意義名稱。
| 類型 | 建議格式 | 範例 |
|---|---|---|
| Component | 元件/類型/尺寸 | Button/Primary/Md |
| Variant Property | 屬性和值 | type=primary、state=disabled |
| Variable | 分類/用途/層級 | color/text/secondary |
| Layer | 內容角色 | Label、Icon left、Helper text |
文件頁要寫使用情境、限制與錯誤用法
文件頁不要只放元件展示。每個元件都應寫出適用情境、內容限制、可調整屬性、常見錯誤與交付注意事項。這些內容會直接影響團隊是否願意使用 Library。
Changelog 要記錄 breaking change
只要元件結構、Token 名稱、Variant 屬性或前端對應規則被改動，就要記錄在 Changelog。breaking change 要寫清楚影響範圍與替代方式，否則舊檔案很容易被更新破壞。
Figma 設計系統如何對接前端元件庫？
Figma 設計系統對接前端元件庫時，重點是讓 Figma Variables、Design Tokens、CSS Variables、React Props 與 Tailwind Config 的命名規則一致。視覺不必完全一比一，但規則要能互相追蹤。
設計 Token 與工程 Token 的對應
設計端 Token 要先定義語意，再交給工程端轉成可用格式。不要讓工程師從畫面猜顏色，也不要讓設計師直接複製 CSS 名稱而失去設計語意。
| 設計端 | 工程端 | 範例 |
|---|---|---|
| Figma Variable | CSS Variable | color/action/primary 對應 --color-action-primary |
| Spacing Token | Tailwind Config | space/16 對應 spacing.4 |
| Component Property | React Prop | type=primary 對應 variant="primary" |
| Text Style | Typography Class | text/body/md 對應 text-body-md |
Button 元件從 Figma 到 React 的對接範例
Figma Button 可以有 type、size、state、iconPosition 等 Properties；React Button 則可以對應 variant、size、disabled、icon。關鍵是雙方要事先確認哪些屬性能交付，哪些只是設計示意。
例如 Figma 裡的 Button/Primary/Md，工程端可以對應 <Button variant="primary" size="md">。如果 Figma 多了一個 glass 樣式，但前端元件庫沒有，就不應該直接進入正式交付。
Dev Mode 在交付中的角色
Figma Dev Mode 適合工程師檢視尺寸、間距、樣式、變數與標註，也適合在設計交付時減少截圖說明。但 Dev Mode 不是治理本身，命名、Token 與元件規則仍然要在設計系統內先定義。
設計系統和前端元件庫不一定要完全一比一，但規則要一致
有些 Figma 元件是為了設計效率存在，有些 React Components 則處理資料、互動與狀態邏輯。兩邊不必完全相同，但 Button、Input、Modal 這類核心元件的屬性、狀態與命名應保持一致。延伸可參考 Design Token 與 Figma Variables 指南、前端元件庫建立方式、Figma Dev Mode 交付流程。
如何檢查你的 Figma 設計系統是否失控？
Figma 設計系統失控通常會出現重複樣式、未命名 Layer、失控 Variant、未使用元件、舊版 Instance 與文件缺漏。定期 Audit 可以讓系統維持可用，而不是越做越難改。
樣式與變數檢查
- 是否存在多組相近色碼，但沒有語意差異。
- Text Styles 是否重複或命名不一致。
- Variables 是否有未使用、重複或語意不清的名稱。
- Modes 是否和實際主題切換規則一致。
元件與 Instance 檢查
- 是否有大量 detached Instance。
- 同一元件是否被複製成多個版本。
- Variants 是否過多，且能否改用 Properties 簡化。
- Override 是否常造成版面破裂。
文件完整度檢查
文件要檢查是否有用途、狀態、限制、錯誤用法與交付注意事項。只放元件展示圖很難支援團隊採用，尤其是新人或工程師第一次使用時。
版本更新與 breaking change 處理
更新核心元件前，要先判斷是否會影響既有 Instance。若會影響舊檔案，就要記錄 breaking change，並提供替代元件或遷移說明。
誰可以修改核心元件
核心元件不能任何人都直接改。小團隊可以指定一位設計師維護，大團隊則需要設計系統 owner、review 流程與發布規則。這不是增加流程負擔，而是避免 Library 變成多人同時修改的風險區。
20 分鐘快速建立 Figma 設計系統範例流程
20 分鐘可以建立一套最小可用 Figma 設計系統：先建頁面與命名規則，再建立色彩、文字、Button、Input、文件與 Library。這只能當起點，不能取代後續治理。
0-5 分鐘：建立頁面與命名規則
建立 Cover、Foundations、Components、Documentation、Changelog 五個頁面。先寫下命名格式，例如 color/action/primary、Button/Primary/Md，避免後面邊做邊改。
5-10 分鐘：建立色彩與文字變數
建立最小色彩集合：text、background、action、border、status。文字先做 display、heading、body、caption 四類。這個階段不要追求完整色階，先讓主要畫面能穩定使用。
10-15 分鐘：建立 Button 與 Input
建立 Button 的 primary、secondary、disabled、loading 狀態，再建立 Input 的 default、focus、error、disabled 狀態。建議用 Auto Layout 管理內距，並保留 icon 的 Instance Swap 空間。Auto Layout 細節可延伸參考 Figma Auto Layout 實作指南。
15-20 分鐘：補上文件與發布 Library
每個元件至少寫一段用途、一組正確用法、一組錯誤用法。完成後發布 Library，讓測試檔案先引用元件，確認 Instance 與 Overrides 是否正常。
快速流程只能當起點，不能取代治理
20 分鐘流程適合建立方向，不適合當正式系統完成標準。真正可維護的設計系統，還需要 Audit、版本控管、前端對接與使用者回饋。更完整的基礎架構可接到 設計系統完整指南、Figma Component Variants 教學。
常見錯誤：為什麼很多 Figma 設計系統最後沒人用？
很多 Figma 設計系統沒人用，原因通常不是元件不夠多，而是命名混亂、Variant 爆炸、文件不足、設計端和前端 Token 不一致，或維護責任不清楚。
只做漂亮 UI Kit
漂亮 UI Kit 可以提升第一眼質感，但無法回答使用規則。當團隊遇到錯誤狀態、空狀態、權限限制、資料過長等真實情境時，沒有規則的 UI Kit 很快就會失效。
命名過度視覺化
如果所有命名都依賴 blue、large、rounded，就很難支援產品演進。語意命名雖然一開始比較慢，但後續改版時更穩。
Variant 太多、Properties 太少
Variant 太多會讓元件面板難以使用，也會讓維護者不敢更新。能用 Properties 處理的圖示、文字、開關、替換內容，就不必全部做成新的 Variant。
沒有文件與範例
沒有文件的元件會讓使用者猜規則。猜久了，大家就會複製舊畫面或自行建立新元件，設計系統自然失去作用。
設計端和前端 Token 不一致
設計端叫 primary-blue，前端叫 brand-main，文件又寫 CTA color，三邊不一致會讓設計交付一直卡住。Figma 設計系統要長期可用，必須讓 Design Tokens、Figma Variables、前端元件庫與文件維持同一套語意。
Figma 設計系統和 UI Kit 有什麼不同？
UI Kit 主要是視覺元件集合，Figma 設計系統則包含樣式、變數、元件、文件、版本控管、設計交付與治理規則。UI Kit 可以是設計系統的一部分，但不能取代完整設計系統。
小團隊也需要建立 Figma 設計系統嗎？
需要，但不必一開始做得很大。小團隊可以先建立 Level 2 的元件庫，整理顏色、文字、Button、Input、表單元件、命名規則與基本 Changelog。
Figma Variables 和 Styles 差在哪？
Styles 適合設計師套用固定視覺樣式，例如文字、陰影、Grid。Variables 適合管理語意值、主題模式與 Design Tokens，例如 color/action/primary、space/16、radius/md。
設計系統一定要和前端元件庫同步嗎？
核心規則要同步，但元件數量不一定完全相同。Button、Input、Modal 等核心元件的狀態、屬性與 Token 應一致；設計端專用的排版輔助元件則可不進前端元件庫。
Figma 設計系統要怎麼命名？
建議用語意命名。Component 可用 Button/Primary/Md，Variant 可用 type=primary、state=disabled，Variable 可用 color/text/primary、color/bg/surface。避免只用 blue、big、new 這類短期名稱。
第一套設計系統應該先做哪些元件？
先做 Button、Input、Checkbox、Radio、Select，再做 Card、Modal、Navigation。優先順序應依照使用頻率、跨頁面重複程度、設計交付痛點決定。
Design Tokens 是什麼？和 Figma Variables 有什麼關係？
Design Tokens 是設計決策的命名資料，例如顏色、間距、圓角、字級。Figma Variables 可以承載這些 Token，並進一步對應 CSS Variables、Tailwind Config 或 React Props。
Figma Component、Variant、Property 要怎麼分工？
Component 是元件本體，Variant 管理同一元件的類型與狀態，Property 管理文字、圖示、布林開關、Instance Swap 等可調整內容。能用 Property 解決的變化，不必全部拆成 Variant。
深色模式應該用 Variables 還是另外做一套元件？
深色模式優先用 Variables Modes。保持同一組元件與語意 Token，再用 light、dark 模式切換底層值。只有在互動或結構不同時，才需要另外建立元件變體。
設計系統做好後要怎麼維護？
要固定檢查重複樣式、未命名 Layer、detached Instance、未使用元件、文件缺漏與 breaking change。小團隊可用固定週期檢查，大團隊應建立 owner、review 與版本控管流程。
如何判斷設計系統是不是做太複雜？
如果設計師找不到元件、工程師看不懂 Token、改一個狀態需要更新大量 Variants，或新人需要很久才能理解規則，就代表系統可能過度複雜。成熟度應依團隊規模與協作需求決定。
可以先用現成 UI Kit 再改成自己的設計系統嗎？
可以，但要把現成 UI Kit 視為起點。團隊仍需要重新整理命名、Design Tokens、Variables、使用情境、限制、文件與前端對接規則，才能變成真正可維護的 Figma 設計系統。