CH14 · Design System 詳細 ROADMAP
計畫文件，不會被 Quartz 渲染。
回主 roadmap → frontend/ROADMAP.md
章節目標
Design System（DS）是前端能力走到成熟階段的里程碑——整合了元件設計、視覺系統、a11y、測試、打包、版本管理、跨框架、團隊治理。建立從 Design Token 到 Headless 元件、從 Storybook 到 Figma 整合、從個人 UI Library 到組織級 DS 的完整能力。
🌱 基本介紹
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 01 | Design System 是什麼 | 01-what-is-design-system | 🌱 | DS 定義、包含的東西（tokens、components、guidelines、patterns）、為什麼不只是「元件庫」 |
| 02 | Design Token 是什麼 | 02-what-is-design-token | 🌱 | 設計決策的變數化、跟 CSS 變數差異、W3C Design Tokens Community Group 格式 |
| 03 | Component Library vs Design System 差異 | 03-library-vs-system | 🌱 | Library 是「元件」；System 是「元件 + tokens + 文件 + 流程 + 治理」 |
❓ 為什麼需要
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 04 | 為什麼需要 Design System（元件庫不夠嗎） | 04-why-design-system | 🌱 | 一致性、團隊效率、設計債、品牌、onboarding；什麼規模才值得投入（2 個產品不夠、5 個要考慮、多團隊必做） |
| 05 | 為什麼 Design Token 是 DS 基礎 | 05-why-design-tokens | 🌱 | 設計與程式碼之間的契約、跨平台一致（Web / iOS / Android）、主題切換、dark mode 的唯一正解 |
| 06 | 為什麼不直接用 Material UI / Ant Design | 06-why-not-off-the-shelf | 🌱 | 品牌獨特性、bundle size、客製困難、vendor lock-in、其實多數情境用現成的就夠的反省 |
| 07 | 為什麼大公司都自建 DS | 07-why-big-companies-build-own | 🌱 | 跨產品一致、品牌核心、累積的設計語言、離職工程師帶不走；Material / Polaris / Lightning / Carbon / Atlassian 為什麼都自己做 |
🕰️ 演進
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 08 | DS 演進史 | 08-ds-evolution | 🌱 | Brand Guidelines（紙本）→ Style Guide（BBC 2010s）→ Pattern Library（MailChimp）→ Design System（Salesforce Lightning 2015）→ Token-driven（2020+） |
| 09 | Storybook 演進 | 09-storybook-evolution | 🌱 | React Storybook（2016）→ 支援多框架 → CSF 3（2022）→ Storybook 8（Vitest 整合、CSF 3 play function） |
| 10 | Headless UI 興起 | 10-headless-ui-rise | 🌱 | 為什麼 Radix / Headless UI / Ark UI / React Aria 成主流、跟傳統 UI library 差異、shadcn/ui 現象 |
| 11 | Figma × Code 同步演進 | 11-figma-code-sync-evolution | 🌱 | Figma Dev Mode（2023）→ Tokens Studio → Anima / Builder.io → AI 生成（v0.dev），設計稿到程式碼的變化 |
🧠 知識型
Design Tokens
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 12 | Design Token 三層架構 | 12-token-architecture | 🌱 | Base tokens（color.blue.500）→ Semantic tokens（color.primary）→ Component tokens（button.bg），為什麼要分層 |
| 13 | Token 格式與工具 | 13-token-format-tools | 🌱 | W3C DTCG 格式、Style Dictionary、Tokens Studio for Figma、Supernova，選型考量 |
| 14 | Token 導出到各平台 | 14-token-platform-export | 🌱 | 從 JSON token 產生 CSS / Sass / JS / Swift / Android 檔案、cross-platform 一致 |
| 15 | Dark mode + Theming via tokens | 15-dark-mode-theming | 🌱 | 用 semantic token 實作主題切換、多主題（dark / light / high-contrast）、[data-theme] 切換 |
Component API 設計
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 16 | Component API 設計原則 | 16-component-api-principles | 🌱 | 可組合優於 props、最小 API surface、預設值哲學、為什麼 Button 不該有 type="success"（改用 composition） |
| 17 | Compound Components Pattern | 17-compound-components | 🌱 | <Tabs>/<Tabs.List>/<Tabs.Panel> 模式、context 共享、靈活組合 |
| 18 | Headless Component 設計 | 18-headless-components | 🌱 | 行為與樣式分離、Radix / React Aria / TanStack 的做法、為什麼這是 2024+ 主流 |
| 19 | Polymorphic Components（as prop） | 19-polymorphic-components | 🌱 | <Box as="a">、TypeScript 支援、Radix 的 asChild pattern |
| 20 | Controlled vs Uncontrolled 取捨 | 20-controlled-uncontrolled-api | 🌱 | 元件內部是否管理 state、如何同時支援兩者、defaultValue vs value |
| 21 | A11y 內建 DS | 21-a11y-built-in | 🌱 | DS 元件的 a11y 是內建義務、不是可選、Radix / React Aria 為什麼自帶 a11y |
文件與 Storybook
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 22 | Storybook 基礎 | 22-storybook-basics | 🌱 | CSF（Component Story Format）、args / argTypes、controls、actions |
| 23 | Storybook 進階 | 23-storybook-advanced | 🌱 | play function、interaction test、docs page、自動化 props table |
| 24 | 自動化 Component API 文件 | 24-component-docs-automation | 🌱 | TSDoc / JSDoc → Storybook、react-docgen、API extractor |
| 25 | 視覺迴歸測試整合 DS | 25-vrt-for-ds | 🌱 | Chromatic / Percy / Lost Pixel、每個元件的 baseline、CI 整合 |
打包與發布
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 26 | Monorepo 組織 DS | 26-ds-monorepo | 🌱 | Turborepo / Nx / pnpm workspaces、packages 分層（core / components / icons / themes） |
| 27 | 打包策略（ESM + CJS + Types） | 27-ds-build-strategy | 🌱 | tsup / Rollup / Rolldown、dual package、tree-shaking 友善、sideEffects: false |
| 28 | Versioning / Changeset | 28-ds-versioning | 🌱 | @changesets/cli、semver 用法、breaking change 溝通 |
| 29 | Release Automation | 29-ds-release-automation | 🌱 | GitHub Actions / release-please、canary 發布、自動 changelog |
Theming
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 30 | Runtime vs Build-time Theming | 30-runtime-buildtime-theming | 🌱 | 兩種的效能 / 彈性 tradeoff、CSS Variable 為什麼是現代解 |
| 31 | Multi-tenant / White-label | 31-multi-tenant-theming | 🌱 | SaaS 多租戶、品牌客製、token override 策略 |
治理
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 32 | DS 治理模型 | 32-ds-governance-models | 🌱 | Solitary（一人做）、Centralized（專職團隊）、Federated（多團隊貢獻）、Cyclical（混合），選型考量 |
| 33 | Contribution Workflow | 33-contribution-workflow | 🌱 | PR review 流程、RFC 機制、新元件納入標準、maintainer 責任 |
| 34 | Breaking Change 管理 | 34-breaking-change-management | 🌱 | deprecation 週期、migration guide、codemod 提供、major release 節奏 |
| 35 | 使用者支援 | 35-ds-user-support | 🌱 | Office hour、Discord / Slack 支援、feedback loop、adoption metrics |
跨框架
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 36 | 跨框架 DS 策略 | 36-cross-framework-ds | 🌱 | Web Components 方案、Headless + Framework wrappers（React/Vue 各自 wrap）、Stencil |
Figma 整合
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 37 | Figma Dev Mode | 37-figma-dev-mode | 🌱 | Dev Mode 能做什麼、inspect specs、code connect、component linking |
| 38 | Token 雙向同步（Figma ↔ Code） | 38-figma-token-sync | 🌱 | Tokens Studio / Supernova 雙向同步、single source of truth 戰略 |
| 39 | AI 驅動的設計稿轉 Code | 39-ai-design-to-code | 🌱 | v0.dev / Builder.io / Anima / Locofy 2024 比較、哪些適合 DS 情境、局限性 |
🔧 小實作注意事項
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 40 | 建立第一個 Design Token 系統 | 40-first-token-system | 🌱 | Style Dictionary 實戰、base → semantic → component、輸出 CSS + JS |
| 41 | Headless Dropdown 從零實作 | 41-headless-dropdown | 🌱 | 跟 Radix 對比、a11y 建構、key flow、focus management |
| 42 | Storybook 導入實戰 | 42-storybook-setup | 🌱 | Vite + React + TS + Tailwind，Storybook 8 零配置起手 |
| 43 | Token 版本升級策略 | 43-token-upgrade-strategy | 🌱 | primary.500 改名 → migration guide / codemod / 併存期 |
| 44 | 跨 React / Vue 共用 DS | 44-cross-framework-ds-practice | 🌱 | Tokens 共用 + 各自 wrapper、monorepo 設定、testing 策略 |
| 45 | 發布一個 DS npm package | 45-publish-ds-package | 🌱 | 從 Storybook 到 npm、scoped package、主題支援 |
| 46 | 走歪的信號：DS 設計者 / 架構師 / 前端 Senior 的自我檢視 | 46-signs-of-going-astray | 🌱 | 走歪的 10 個信號：只談抽象沒程式碼、沒有個人 awesome repo（用過的工具收藏）、沒有 proto repo（驗證新技術的沙盒）、推薦別人方案前沒用過、用 buzzword 但解釋不清底層、引用 2 年前資訊當現狀、只看 talk 不讀源碼、評斷技術靠人情而非技術、不願意說「我還不熟」、追求完美架構卻沒產出。避免走歪的實作習慣：維護個人 awesome repo（只放用過的）、每年至少 1 個 proto project、讀源碼不只讀文章、定期跟實戰者對話、對不熟領域誠實標記、每個觀點都要有 code evidence、避免評論沒用過的工具。Dunning-Kruger 在技術圈：抽象領域（架構 / DS）特別容易被 knowledge-without-practice 綁架，DS 設計者尤其要警覺——整天開會畫 token 圖但沒實際碰組件的那種 |
💣 Anti-pattern
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 47 | DS Anti-patterns | 47-ds-anti-patterns | 🌱 | 過早建 DS（2 個 component 硬做系統）、跳過 token 直接做 component、沒治理的 federated DS（混亂）、Breaking change 不預告、Storybook 跟實際使用脫節、a11y 事後補、Figma 設計稿跟 code 永遠同步不上 |
🧰 對應檢查工具
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 48 | DS 工具生態 | 48-ds-tooling | 🌱 | Storybook / Chromatic / Ladle / React Cosmos / Style Dictionary / Tokens Studio / Supernova / Zeplin / Anima / Figma Dev Mode / changeset / tsup / Rolldown |
📎 補充
| # | 主題 | Slug | Stage | 大綱 |
|---|
| S01 | 知名 DS 研究 | s01-famous-design-systems | 🌱 | Material / Polaris（Shopify）/ Lightning（Salesforce）/ Carbon（IBM）/ Atlassian / Fluent（Microsoft）/ Primer（GitHub），每家特色 |
| S02 | DS 成功指標（ROI / Adoption） | s02-ds-success-metrics | 🌱 | adoption rate、時間節省、bug reduction、consistency score 怎麼測 |
| S03 | Icon System 設計 | s03-icon-system | 🌱 | SVG sprite / Icon font / React component、命名策略、size variants、linecap |
| S04 | Illustration / Motion System | s04-illustration-motion | 🌱 | 插圖系統、動畫 token、微互動 guideline |
章節進度統計
- 知識主題：48 + 4 補充 = 52 項
- 🌿 growing：0
- 🌱 seed：52
跨系列連結
- →
frontend/css/ CH2（CSS Variables / Theming / Tokens）
- →
frontend/framework/ CH6（元件 API 設計）
- →
frontend/testing/ CH10（視覺迴歸測試整合）
- →
frontend/a11y/ CH12（DS 元件的 a11y 義務）
- →
frontend/application/ CH8（UI Library 建置時機、Monorepo、npm 發布）
- → W05 CMS capstone（自訂 DS 給 CMS 用）