candy14432 設計系統建立法則
任務定義
建立可重複使用的設計規則、tokens、元件規範與治理方式,降低不一致與重複建設成本。
何時使用
- 產品規模擴大,需要保持一致性時
- 多個團隊協作開發時
- 需要提升設計和開發效率時
- 品牌需要統一視覺語言時
必要輸入
- 現有產品畫面、元件或設計檔
- 品牌風格與視覺方向
- 團隊規模與協作模式
- 目前重複問題或不一致問題
- 目標平台與技術棧
預期輸出
- 設計系統範圍與原則
- Design Tokens 規劃
- 元件優先順序與規範草案
- 文件架構與治理方式
- 導入與維護建議
完成條件
- 已定義設計系統服務的產品範圍、平台與團隊對象
- 已整理核心 tokens、元件優先序與命名原則
- 已說明元件規範、文件架構與治理方式如何協作
- 已辨識短期導入項目與長期維護機制
- 已讓設計與開發團隊可以用同一套規則協作
不適用情境
- 只需修單一畫面樣式,不需要完整 design system
- 團隊仍未對產品範圍與核心元件達成基本共識
- 問題主要是單一流程可用性,應先處理 usability-testing 或 wireframing
常見誤用
- 把設計系統當成元件展示集,缺少原則與治理
- 一開始就想做太大,沒有先處理最高頻問題
- 只有設計稿規範,沒有對應 token、文件或實作策略
- 元件命名與變體邏輯混亂,導致無法擴充
- 缺乏維護責任與變更流程,讓系統很快失控
觸發條件
- 使用者提到「設計系統」、「元件庫」、「design token」、「UI 規範」、「component library」
- 任務需要統一按鈕、表單、色彩、間距或排版規則
- 任務需要把零散畫面整理成可複用的系統
高複雜度觸發
- 任務涉及多產品線、B2B 平台、後台模組或多角色共用的複雜系統
- 使用者提到跨團隊協作、元件不一致、不同模組各自發展、缺乏治理機制
- 問題包含權限差異、資料密集介面、複雜表單、狀態不一致或品牌延伸需求
- 團隊不只是要整理視覺,還要建立元件規則、文件與維護流程
必要澄清
- 現在最痛的系統性問題是什麼?樣式不一致、元件重複還是跨團隊協作失控?
- 這個設計系統要服務哪些產品、平台與角色?是否包含後台與前台?
- 哪些元件是最高頻且最需要先標準化的?
- 目前是否已經有 token、元件庫、文件站或治理流程?哪些缺口最大?
- 設計與開發團隊如何協作?誰負責審查、發布與維護?
- 這次的目標是建立基礎系統、整併現有元件,還是導入新的治理模式?
可搭配技能
accessibility-design: 把無障礙要求納入元件與規範基準wireframing: 用一致元件快速組裝頁面骨架prototyping: 驗證元件在真實流程中的互動完整性information-architecture: 若系統涵蓋大型後台,同步整理頁面與模組結構
執行步驟
- 盤點現況: 找出重複元件、不一致樣式與高頻問題。
- 定義原則: 先寫清一致性、命名、狀態、無障礙與治理原則。
- 建立基礎: 定義 colors、spacing、typography、radius、shadow 等 tokens。
- 排元件優先序: 先做 Button、Input、Select、Card、Table 等高頻元件。
執行檢查
- 已盤點現有元件與樣式不一致問題
- 已建立核心 tokens 與命名規範
- 已定義高頻元件優先序
- 已寫清元件狀態、變體與使用規則
- 已建立文件與維護流程
精簡範例輸出
# Design System 核心規格
Tokens:
- primary: #2563EB
- neutral-900: #111827
- spacing-md: 16px
- radius-md: 8px
核心元件:
- Button: primary / secondary / danger
- Input: default / focus / error / disabled
- Card: default / elevated / outlined
治理:
- 新增元件需經設計與前端共同審查
- 變更需附版本記錄與遷移說明
範例資料庫
本技能提供完整的設計系統範例庫，請參考 examples.yaml：
- Design Tokens：色彩、字體、間距、圓角、陰影等完整 token 定義
- 元件庫：按鈕、輸入框、卡片等常用元件的變體和狀態
- 命名規範：元件、token、變體、狀態的命名慣例
- 文件結構：元件頁面和 token 頁面的文件組織方式
- 治理流程：貢獻流程、版本管理、棄用流程
- 實作範例：CSS Variables、Tailwind Config、React Component 等程式碼範例
使用方式：參考 token 定義建立設計變數，使用元件範例快速建立元件庫。
資料使用規則
- 產出內容前，先閱讀
TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。 - 接著再閱讀
examples.yaml，從既有 token、元件規格、命名規範與治理流程中選取最適合的內容。 - 若要新增資料，優先沿用
TEMPLATE.md的格式與命名規則，避免建立重複 token、重疊元件或不一致的治理定義。 - 最終輸出必須優先對齊
TEMPLATE.md的格式要求，其次再引用examples.yaml的內容細節。