設計系統是什麼？從零建立品牌規範與 Design Tokens

設計系統到底是什麼？

設計系統是一套讓品牌、設計與前端共用的協作框架，包含設計原則、元件、Design Tokens、文件與治理流程。

對初創團隊來說，設計系統的價值不是把畫面做得更漂亮，而是把重複決策變少。當產品開始出現 20 個以上頁面、3 種以上表單、2 個以上設計師或前端共同維護時，沒有規範通常會讓按鈕、色彩、間距與錯誤訊息逐步分裂。

一套可落地的設計系統至少要有 4 個支柱：

• 設計原則：定義品牌在一致性、可讀性、可擴充性上的判斷標準。
• 元件庫：把按鈕、輸入框、卡片、表格等 UI 拆成可重用單位。
• Design Tokens：把顏色、字級、間距、圓角轉成跨工具可同步的命名資料。
• 文件與治理：規定誰能新增元件、何時改版、破壞性變更如何通知。

我的判斷是，小團隊最常失敗的地方不是沒有 Figma 檔，而是沒有決策邊界。只要每個頁面都重新討論 primary button 長什麼樣，開發速度就會被小決策拖慢。

設計系統 vs UI Kit vs 風格指南 vs 元件庫（比較表）

項目	主要功能	文件化程度	維護頻率	適合用途
UI Kit	提供畫面元件樣式	低到中	不固定	快速拉頁面、做 MVP
風格指南	定義品牌色、字體、Logo 用法	中	品牌調整時更新	品牌一致性、行銷素材控管
元件庫	提供可重用 UI 元件與狀態	中到高	隨產品需求更新	設計與前端協作
設計系統	整合規則、元件、Token、治理	高	版本化維護	多產品、多平台、長期治理

UI Kit 可以是設計系統的一部分，但不能取代治理、Token 與文件。想延伸閱讀，可參考 設計規範建立指南 與 元件庫建置流程。

為什麼企業需要設計系統？

企業需要設計系統，是因為產品規模一大，品牌一致性、交付速度與設計債會同時變成成本問題。

當企業同時經營官網、會員中心、後台、App 與活動頁，沒有共同規範會讓相同功能長出多種版本。電商促銷頁常見的問題是，同一個「立即購買」按鈕在桌機、手機、LINE 導購頁各有不同高度與文案，最後客服、行銷與工程都要吸收混亂。

• 元件重用率：成熟團隊可把核心元件重用率設定為 60% 以上，低於 40% 通常代表重複設計過多。
• 交付週期：新版頁面若可沿用既有元件，設計審稿次數通常能從 3 到 4 輪降到 1 到 2 輪。
• 設計債：每季盤點一次過期元件，能避免同一種輸入框累積 5 個以上相似版本。

我會建議決策者先追蹤「元件重用率、設計交付時間、前端返工次數」這 3 個指標，比單純問設計系統花多少錢更接近管理現場。

設計系統的四大支柱

設計系統的四大支柱是設計原則、元件庫、Design Tokens、文件與治理，缺任何一項都會影響長期維護。

成熟企業最容易卡在第二階段：Figma 看似有元件，但顏色沒有 Token、元件沒有狀態表、Storybook 沒有同步文件。這種狀態短期看起來能交付，半年後會變成跨平台不一致。

1. 設計原則（Consistency、Scalability）

設計原則要能協助團隊做取捨，例如一致性優先於局部創意、可讀性優先於裝飾。若金融表單錯誤訊息需要在 1 秒內被辨識，顏色、圖示、欄位說明就不能每個產品自行定義。

• 色彩一致：主要操作色不超過 1 組，警示色需符合語意。
• 間距規範：常用 spacing 建議控制在 4 到 8 個級距內。
• 可擴充：新增活動頁時，不應為單一促銷重新發明整套版型。

2. 元件庫（Atomic Design）

元件庫把 UI 拆成原子、分子、組織與模板。Atomic Design 的重點不是術語，而是讓團隊知道按鈕、輸入框、卡片、導覽列與表單頁之間的依賴關係。

以前端主管角度看，每個元件至少要記錄 4 類資訊：用途、變體、狀態、限制。以按鈕為例，primary、secondary、danger 是變體；default、hover、focus、disabled、loading 是狀態。少寫一個狀態，QA 階段就可能多出一次返工。

元件狀態與變體設計

• 每個可互動元件都要有 focus 狀態，並能用鍵盤操作。
• disabled 狀態不得只靠透明度，仍需保留可讀對比。
• ARIA 標記要寫進元件文件，例如 icon button 需有 aria-label。
• CSS class 與 component props 命名要一致，避免設計與程式各說各話。

3. Design Tokens（跨平台單一事實來源）

Design Tokens 是把視覺決策資料化的方式，例如 color.brand.primary、font.size.body、spacing.4。W3C Design Tokens Community Group 已發布格式規範，目的就是提升工具之間的互通性。

Token 命名要避免直接綁定顏色名稱。比起 blue-500，button-primary-bg 更適合跨品牌維護；比起 16px，font-size-body-md 更能對應語意。Figma Variables 可管理設計端變數，CSS Variables 可管理前端輸出，兩者用 JSON 當交換格式會最穩。

{
  "color": {
    "button": {
      "primary": {
        "bg": { "$value": "#0F62FE", "$type": "color" },
        "text": { "$value": "#FFFFFF", "$type": "color" }
      }
    }
  },
  "spacing": {
    "4": { "$value": "16px", "$type": "dimension" }
  }
}

範例檔可放在 Design Tokens JSON 範本，設計端可搭配 Figma Variables 官方指南。

4. 文件與治理流程

文件與治理決定設計系統能不能活超過一季。文件至少要回答 3 件事：什麼時候用這個元件、不能怎麼用、改版會影響哪些產品。

治理流程可以用文字流程圖管理：需求提出、設計審核、前端實作、可及性檢查、版本發布、產品通知。若團隊已使用 Storybook，可把元件狀態、props、互動測試與無障礙檢查放在同一處，降低設計文件與程式碼脫節。

參考資源可放入 Storybook Accessibility Testing 與 設計系統治理流程。

從零開始建立設計系統的 5 步路線圖

從零建立設計系統，應先盤點現有 UI，再建立 Token、核心元件、文件，最後導入治理與版本控管。

階段	時間	主要產出	驗收指標
1. UI 審計	第 1 週	列出重複按鈕、表單、色彩、字級	完成前 20 個高流量頁面盤點
2. Token 定義	第 2 到 4 週	色彩、字級、間距、圓角 JSON	核心 Token 覆蓋 80% 常用 UI
3. 核心元件	第 2 個月	按鈕、輸入框、選單、卡片、表格	完成 10 到 15 個高頻元件
4. 文件化	第 3 個月	使用情境、限制、狀態、範例	每個元件至少 1 頁文件
5. 治理導入	第 3 個月後	審核角色、版本規則、更新公告	每月一次元件審查

小團隊不用一開始追求完整平台，先把最常出問題的表單、按鈕與活動頁模板穩住，通常比追求 100 個元件更有效。相關執行細節可延伸到 UI 審計清單。

Design Tokens 深入實作（範例與工具）

Design Tokens 的實作核心，是用 JSON 管理來源，再輸出給 Figma、CSS、SCSS 與前端元件使用。

工具選型建議分 3 層：Figma Variables 管理設計端變數，Style Dictionary 或相容工具負責轉換格式，前端用 CSS Variables 或 SCSS maps 接收。我的經驗是，Token 名稱比工具更重要；名稱一亂，任何同步工具都只是把混亂自動化。

:root {
  --color-button-primary-bg: #0F62FE;
  --color-button-primary-text: #FFFFFF;
  --spacing-4: 16px;
  --radius-sm: 4px;
}
.button-primary {
background: var(—color-button-primary-bg);
color: var(—color-button-primary-text);
padding: var(—spacing-4);
border-radius: var(—radius-sm);
}

可參考 Style Dictionary 官方文件、W3C Design Tokens Format Module 與 Figma Variables 同步教學。範例檔建議拆成 colors.json、typography.json、spacing.json，避免單一檔案超過 300 行後難以審查。

治理與維護：誰負責、怎麼審核、版本控制

設計系統治理要明確分工，常見角色包含設計主管、資深設計師、前端 Lead、QA 與產品負責人。

任務	設計主管	UI/UX 設計師	前端 Lead	QA	產品負責人
新增元件	A	R	C	C	I
Token 改版	A	R	R	C	I
破壞性更新	A	C	R	R	I

版本規則可採 major、minor、patch。改變 Token 名稱或移除元件屬於 major；新增變體屬於 minor；修正文件或視覺錯誤屬於 patch。成熟團隊應把每次發布記錄在 changelog，並要求至少 1 位設計與 1 位前端審核。

治理表範例可放在 RACI 治理表範本，更新規則可搭配 元件版本控制指南。

無障礙設計納入設計系統（WCAG 2.2）

無障礙要內建在設計系統裡，包含對比度、鍵盤操作、焦點狀態、ARIA 標記與錯誤提示。

WCAG 2.2 已是 W3C Recommendation，文字對比常用門檻仍以一般文字 4.5:1、大型文字 3:1 作為 AA 檢核基礎。若是台灣公共服務平台或金融表單，錯誤訊息不能只靠紅色，還要提供文字說明與可被輔助工具讀取的關聯。

• 對比度：按鈕文字、錯誤文字、表單標籤都要進行 AA 檢查。
• 鍵盤操作：所有互動元件需能用 Tab、Enter、Space 操作。
• 焦點狀態：focus ring 不應被 CSS 移除，且需有明顯視覺差異。
• ARIA：icon button、錯誤提示、展開選單需有正確標記。
• 檢測工具：可搭配 Storybook a11y addon、瀏覽器 Lighthouse 與人工鍵盤測試。

官方參考可見 W3C WCAG 2.2，實作清單可延伸閱讀 無障礙設計檢查表。

台灣在地化需求：繁體排版、電商促銷、金融表單

台灣設計系統要處理繁體中文閱讀、手機熱區、地址格式、民國年與金融表單驗證等在地需求。

台灣使用情境 Q&A

Q：繁體中文排版最先規範什麼？
A：先規範字級、行高與段落距離。內容型頁面行高常落在 1.5 到 1.8；表格與後台介面可更緊，但不能壓到辨識性。

Q：電商促銷頁的手機按鈕怎麼設計？
A：主要操作區建議至少 48 CSS px 高，避免倒數、價格、折扣碼同時擠在同一行。活動頁轉換率常輸在可點擊區太小，不是視覺不夠熱鬧。

Q：金融表單要特別規範什麼？
A：身分證字號、手機、地址、民國年日期都要有格式提示與錯誤範例。地址欄位需支援縣市、行政區、路段與全形半形輸入。

Q：政府服務平台該注意什麼？
A：首要是可讀性與無障礙，不應把公告、警示、申辦狀態全放成相同顏色。對高齡使用者來說，清楚的階層比新潮視覺更重要。

成功案例與 KPI 量化（本公司實戰）

設計系統的成功案例應用元件重用率、交付時間、缺陷率與維護成本量化，避免只寫抽象成效。

以下為 MakeWebsites 可採用的匿名專案紀錄格式。若客戶資料不能公開，建議用區間呈現，不假裝有超精準結論。我的判斷是，SEO 內容寫案例時寧可少一點戲劇性，也不要把無法驗證的數字寫成戰績。

指標	導入前	導入後 3 個月	資料來源
核心元件重用率	約 30% 到 40%	約 60% 到 70%	Figma 元件使用紀錄與前端 import 統計
活動頁設計交付時間	約 5 到 7 個工作天	約 3 到 4 個工作天	專案排程與交付紀錄
表單 UI 返工次數	每版 3 次以上	每版 1 到 2 次	QA issue 與設計修正紀錄

這類案例可以搭配 設計系統 KPI 追蹤表 與 UI/UX 專案案例寫法。作者陳建宏在 2026 年撰寫此類內容時，應把「可追蹤的依據」放在漂亮敘事之前。

常見問題快速檢索（FAQ）

設計系統和 UI Kit 有什麼差別？

UI Kit 主要提供畫面元件與樣式，設計系統則包含設計原則、元件庫、Design Tokens、文件與治理。若只需要快速完成 MVP，UI Kit 可能夠用；若產品會長期維護，設計系統才有版本控管與跨團隊協作能力。

為什麼設計系統不是只要一套元件庫就好？

元件庫只解決「有什麼元件」，沒有解決「何時使用、誰能修改、改版怎麼通知」。缺少 Design Tokens 與治理流程時，元件會逐漸分裂成多個相似版本，設計債仍會累積。

建立 Design Tokens 需要哪些工具？

常見組合是 Figma Variables 管理設計端變數，JSON 作為交換格式，Style Dictionary 輸出 CSS Variables 或 SCSS。小團隊可先用試算表整理命名，再進入自動化工具，避免一開始就把錯誤命名寫進流程。

設計系統導入後，怎麼測量效益？

建議追蹤元件重用率、設計交付時間、前端返工次數與 QA issue 數量。若核心元件重用率能穩定超過 60%，通常代表設計系統開始真正進入日常工作，而不只是放在文件裡。

我是小團隊，真的需要設計系統嗎？

小團隊不一定需要完整企業級設計系統，但需要最小可用規範。先建立顏色、字級、間距、按鈕、輸入框與卡片規則，就能減少重複討論。當產品超過 20 個頁面時，這筆投資通常會開始回收。

設計系統的治理流程長什麼樣？

基本流程是需求提出、設計審核、前端評估、無障礙檢查、版本發布與產品通知。每次新增元件至少要有 1 位設計與 1 位前端共同審查，破壞性更新則需要提前公告影響範圍。

如何在 Figma 與 CSS 之間同步 Design Tokens？

常見做法是讓 Token 以 JSON 保存，再同步到 Figma Variables 與前端 CSS Variables。關鍵是命名一致，例如 color.button.primary.bg 在設計與程式中都指向同一個語意，而不是各自維護一份顏色表。

設計系統要怎樣才能符合 WCAG 無障礙標準？

設計系統需把對比度、焦點狀態、鍵盤操作、ARIA 標記與錯誤提示寫進元件規格。一般文字對比建議依 WCAG AA 的 4.5:1 檢查，互動元件也要能不用滑鼠完成主要操作。

台灣電商活動頁的按鈕熱區要怎麼設定？

手機主要按鈕建議至少 48 CSS px 高，左右保留足夠點擊範圍，並避免價格、倒數、折扣碼與主要 CTA 擠在同一列。若活動頁有 sticky bar，也要保留關閉或返回操作的可點擊空間。

設計系統的版本更新會不會影響既有產品？

會，所以需要版本規則。新增元件通常屬於 minor 更新，修正文件屬於 patch，移除 Token 或改變元件 API 則屬於 major。重大更新應提供遷移說明，並列出受影響產品。

什麼是「Atomic Design」？它在設計系統裡的角色？

Atomic Design 是把介面拆成原子、分子、組織、模板與頁面的思考方式。在設計系統中，它幫助團隊理解元件層級，避免每次做新頁面都從零開始組裝 UI。

我可以直接把 Figma 元件庫當設計系統嗎？

不建議。Figma 元件庫可以是設計系統的重要資產，但若沒有 Token、前端實作、文件、無障礙規範與治理流程，它仍只是設計端的元件集合。真正可維護的設計系統必須能跨設計與工程落地。