設計系統
葉節點技能 屬於設計領域；可透過其領域或名稱呼叫。
設計系統只有在團隊信任它時才能節省決策。偏離會悄悄地侵蝕這種信任：同一個元件有三個名稱、未經權杖處理的原始十六進制值、無人記錄的狀態。一旦人們不再信任系統，他們就會繞過它。此方法以三種模式運作——稽核現有系統、記錄元件以便正確使用、擴展以符合現有系統的模式——並將每種模式紮根於實際原始碼：權杖檔案、元件程式碼和設計檔案，而非設計系統的抽象概念。
一個實際的稽核發現範例
情境（虛構）： 一個包含權杖檔案的 React 函式庫；要求是「稽核我們的按鈕和卡片」。
命名 Button、IconBtn 和 .btn-link 以三種方式表達同一個概念。
→ 採用 Button，並加入 `icon` 和 `link` 兩種變體；將舊名稱設為別名，保留一個發行版本。
權杖 Card 和 Modal 中有 23 個硬編碼顏色。其中 18 個等於現有權杖（機械式替換）；5 個無對應。
→ 這 5 個需要一個決定：缺少權杖，或是需要修正的設計錯誤。
狀態 Card 沒有焦點狀態，儘管它是可點擊的。
可重複使用的選擇在於區分重複權杖的值（機械式修復）與無對應權杖的值（需要交由人類決定的設計問題）。
收集系統資訊
在評斷之前先閱讀現有內容：權杖原始碼、元件程式碼或函式庫，以及文件。像 rg -n '#[0-9a-fA-F]{3,8}\b|[0-9]+px' src/components 這樣的搜尋可以找出程式碼中的硬編碼值；請根據技術堆疊調整模式。
標記為
~~的段落表示工具類別，而非特定產品：~~design tool（例如 Figma）或~~knowledge base（例如 Notion）。請使用主機提供的該類別中任何已連接的工具；如果沒有，則跳過該步驟。
使用 ~~design tool 時，檢查設計檔案中的元件名稱、變體、圖層結構和權杖使用情況，並與程式碼進行比較。使用 ~~knowledge base 時，尋找現有的元件頁面和使用指南，並且僅在使用者要求時，才將更新後的文件發佈到那裡。
一個系統包含三個層級；稽核和文件應涵蓋每個層級：
| 層級 | 內容 |
|---|---|
| 權杖 | 色彩（品牌、語意、中性）、字體排印、間距、圓角和邊框、高度、動畫持續時間和緩動函數 |
| 元件 | 變體、狀態（預設、懸停、焦點、作用中、停用、載入、錯誤）、尺寸、行為、無障礙功能 |
| 模式 | 表單、導航、資料展示、反饋——組合起來解決重複問題的元件 |
當權杖在不同工具之間轉移時，設計權杖社群組格式（第一個穩定版本 2025.10，2025 年 10 月）是通用的交換格式；請遵循專案已使用的格式。
原則
- 一致性勝於新奇。 系統的存在是為了讓團隊停止重複決定相同的事情；獨特的變體需要有系統缺乏的正當理由。
- 在約束內可組合。 偏好使用變體或現有元件的組合，而非建立新元件。
- 未記錄等同於無法使用。 無人能找到的狀態或變體會被重新建立。
- 版本控制與遷移。 破壞性的重新命名或移除需要遷移路徑，例如一個發行版本的別名，以及 codemod 或搜尋來找到使用處。
稽核
報告數量和證據，而非分數：沒有標準的數字會隱藏哪個問題是重要的。
## 設計系統稽核：[範圍]
**審查項目：** [元件、權杖檔案] | **發現：** [依類別計數]
### 命名
| 問題 | 位置 | 建議 |
|---|---|---|
### 權杖覆蓋率
| 類別 | 已定義權杖 | 硬編碼值 | 與現有權杖相符 |
|---|---|---|---|
### 元件完整性
| 元件 | 狀態 | 變體 | 文件 | 無障礙功能 |
|---|---|---|---|---|
| Button | 完整 | 部分：缺少僅圖示尺寸 | 缺少 | 焦點環存在 |
### 優先行動項目
1. [對使用者或團隊影響最大者優先，並附上所需工作量]
記錄
為所有使用該元件的消費者記錄一個可重複使用的元件。從實際元件的 props 和程式碼範例中擷取，而非發明一個 API。
## 元件：[名稱]
[它是什麼以及何時使用——以及何時改用其他元件]
### 變體
| 變體 | 使用時機 |
|---|---|
### Props
| Prop | 型別 | 預設值 | 描述 |
|---|---|---|---|
### 狀態
| 狀態 | 視覺外觀 | 行為 |
|---|---|---|
### 無障礙功能
- **角色：** [角色或原生元素]
- **鍵盤：** [Tab, Enter, Space, Escape, 方向鍵]
- **螢幕閱讀器：** [朗讀為…]
### 該做與不該做
| 該做 | 不該做 |
|---|---|
### 範例
[專案框架中的簡短程式碼片段]
擴展
在提出任何新內容之前，先列出接近的現有元件，並說明每個元件為何不足；大多數需求最終會以新變體的形式解決。新元件應重複使用現有權杖，僅在提出新權杖時附上理由。
## 提議的元件：[名稱]
### 問題
[使用者需求或落差]
### 現有選項
| 元件 | 共同點 | 為何不足 |
|---|---|---|
### 設計
Props、變體和狀態如同文件模板；使用的權杖。
### 無障礙功能
角色、鍵盤和螢幕閱讀器行為。
### 開放問題
[需要設計審查的決策]
系統的元件和權杖是此方法的對象。單一功能或畫面的規格表，以及新產品的視覺方向，屬於獨立的設計工作；系統稽核也不能取代 WCAG 稽核。