icon 設計規範是什麼？先界定本文討論的範圍
icon 設計規範是一套管理 UI 圖示（Icon）的產品規則，包含尺寸、語意、風格、狀態、命名、匯出與驗收標準。
它服務的是介面決策，不是單顆圖示的美術表現。好的 UI 圖示規範會讓設計師畫得一致，Design System 維護者管得住版本，工程師也能知道 SVG、元件與無障礙標記該怎麼落地。
Icon 在 UI 裡負責什麼？
UI 裡的圖示負責壓縮操作意義，例如搜尋、刪除、關閉、返回、下載、通知、同步。它的價值在於讓使用者更快辨識功能，減少介面文字負擔。實務上，圖示要先對應明確任務，再進入造型設計。
功能 icon、App icon、品牌 icon 差在哪？
功能 icon 是操作工具，App icon 是產品入口，品牌 icon 則承載識別與記憶。三者常被混在一起討論，這會讓規範失焦。產品介面中的 UI 圖示規範應優先處理可辨識、可重用、可交付。
| 類型 | 主要用途 | 規範重點 | 常見位置 |
|---|---|---|---|
| UI 功能 icon | 代表操作或功能 | 辨識速度、尺寸一致、狀態清楚 | 按鈕、工具列、表單、卡片 |
| 導覽 icon | 協助使用者移動到某個區域 | 與資訊架構、選單層級一致 | 底部導覽列、側欄、分頁 |
| App icon | 代表整個產品或應用程式 | 品牌辨識、平台尺寸、視覺層次 | 桌面、App Store、通知、系統設定 |
| 品牌 icon | 輔助品牌識別 | 品牌語氣、識別一致性 | 官網、簡報、品牌素材 |
| 行銷 icon | 輔助說明賣點或內容分類 | 情緒、風格、視覺吸引力 | Landing Page、EDM、社群素材 |
為什麼 icon 不能只靠美感決定？
因為使用者點的是功能，不是欣賞圖形。圖示如果語意不清，介面會變成猜謎。我的判斷是，越接近交易、資料刪除、權限設定的功能，越不能讓造型凌駕於理解成本之上。
制定 icon 規範前，先釐清使用者決策邏輯
制定 UI 圖示規範前，要先判斷使用者看到圖示時能不能理解功能、風險與下一步。
圖示規格不是從畫布開始，而是從使用情境開始。相同的放大鏡圖示，在搜尋列裡很好懂，放在資料分析頁可能代表查詢、篩選或檢視明細。語境會改變圖示的解讀。
使用者看到 icon 時會先判斷什麼？
使用者通常先判斷形狀是否熟悉，再判斷它所在位置，最後才推測點擊後會發生什麼。規範要記錄圖示的功能定義、可用場景與禁用場景，避免同一顆圖示在不同頁面代表不同意思。
哪些功能可以只用 icon？哪些一定要搭配文字？
高頻、低風險、平台慣例強的功能可以考慮只用圖示，例如關閉、搜尋、返回。低頻、危險、需要判斷後果的功能應搭配文字，例如永久刪除、取消訂閱、變更權限。
| 情境 | 可否只用 icon | 建議處理方式 |
|---|---|---|
| 搜尋、關閉、返回 | 可視產品成熟度決定 | 保留 aria-label，必要時加 tooltip |
| 刪除、封鎖、付款、送出 | 不建議 | 搭配文字、確認狀態與明確回饋 |
| 新功能入口 | 不建議 | 先用文字建立學習，再逐步簡化 |
| 狀態提示 | 不應只靠 icon | 搭配文字、顏色與輔助科技標記 |
陌生功能、危險操作、低頻功能要更保守
陌生功能需要學習成本，危險操作有風險成本，低頻功能缺少記憶基礎。這三類功能使用 icon 時，要優先加文字標籤、確認訊息或說明，避免把判斷責任丟給使用者。
Icon 設計規範怎麼訂？完整規格表
一套可用的 icon 設計規範，至少要定義尺寸、網格、安全範圍、筆畫、圓角、視覺密度、狀態與匯出規則。
規格表的目的不是限制設計師，而是讓不同人畫出的圖示能進入同一個系統。數值要固定，例外也要有條件；沒有例外規則的 Design System，很快會被例外拖垮。
| 規格項目 | 建議基準 | 實務做法 | 驗收方式 |
|---|---|---|---|
| 基準尺寸 | 24px | 以 24px 作主要繪製尺寸，再建立 16px、20px、32px 版本 | 確認各尺寸不是直接縮放後失真 |
| 小尺寸 | 16px、20px | 用於表格、密集工具列、輔助資訊 | 縮小後仍能辨識主符號 |
| 安全範圍 | 保留內距 | 圖形主體不貼滿畫布，避免被按鈕或容器吃掉 | 在圓形與方形按鈕內都不壓迫 |
| Stroke | 同套 icon 維持固定邏輯 | 先定線寬、端點、轉角，再畫圖形 | 同列圖示視覺重量一致 |
| Corner radius | 固定幾組半徑 | 避免每顆 icon 自由設定圓角 | 圓角語氣與產品 UI 一致 |
| 對齊 | 以視覺中心為準 | 三角形、箭頭、播放等形狀需要 optical alignment | 放入按鈕後看起來置中 |
| 狀態 | Default、Hover、Active、Disabled、Selected | 由 token 或元件狀態控制，不為每顆 icon 另畫一套 | 狀態變化清楚且可維護 |
建議基準尺寸：16px、20px、24px、32px 怎麼用？
24px 適合作為 UI 圖示規範的主要基準，因為多數介面元件與平台圖示系統都能銜接。16px 適合密集資訊，20px 適合桌面工具列，32px 則適合較強調的入口或空狀態輔助圖示。
Grid、Safe Area 與出血範圍怎麼設定？
Grid 是繪製基準，Safe Area 是圖形主要活動範圍，出血則用來處理視覺補償。箭頭、播放、星形這類圖形可能需要微幅超出幾何範圍，重點是放入元件後看起來平衡。
Stroke 粗細、端點、轉角與圓角半徑
線性 icon 要先決定 stroke 粗細，再決定端點是圓端或平端、轉角是圓角或斜角。若產品 UI 本身偏精準俐落，端點可以較收斂；若產品語氣較親切，圓端與小圓角會更自然。
角度、曲線、留白與視覺密度
角度與曲線會影響整套 icon 的性格。規範應限制常用角度，例如水平、垂直、45 度，並要求小尺寸下保留足夠負空間。16px 糊掉的圖示，多半不是尺寸問題，而是密度沒有重畫。
Optical Alignment：對齊視覺中心，而不是只對齊幾何中心
播放鍵、返回箭頭、定位針這類圖形，幾何置中後常會看起來偏一邊。設計驗收時要把 icon 放進實際按鈕與列表中看，而不是只看 Figma 畫布上的座標。
狀態規格：Default、Hover、Active、Disabled、Selected
狀態不應靠設計師複製多份圖示處理。更穩定的做法是讓 icon 繼承元件色彩 token，例如 default、muted、accent、danger、disabled，讓同一顆 SVG 能在不同狀態中重用。
Icon 的語意規範：使用者要先看懂，再談風格
icon 語意規範要定義每顆圖示代表什麼、不能代表什麼，以及相似符號如何避免混淆。
圖示不是越聰明越好。太過內部化的符號，會讓團隊覺得精準，使用者卻完全看不懂。能被多數人快速理解的符號，通常比充滿創意但需要解釋的符號更適合介面。
一顆 icon 只承載一個主要意思
同一顆圖示不應同時代表新增、建立、加入收藏。規範要為每顆 icon 寫下主語意、可接受用途與不可使用用途。當語意開始分裂，就該新增圖示或調整文案。
組合式 icon：主符號與輔助符號的位置規則
組合式 icon 常用主符號加上加號、減號、警示、勾選等輔助符號。輔助符號位置要固定，例如右下角代表新增狀態、右上角代表提醒，避免每顆 icon 自由擺放。
危險、成功、通知、同步等狀態 icon 的語意一致性
危險通常使用警示或刪除語意，成功使用勾選，同步使用循環箭頭，通知使用鈴鐺或徽章。規範要把狀態 icon 與色彩 token 綁定，並確認色彩消失時仍能辨識狀態。
避免用內部人員才懂的符號
內部代號、後台流程、組織習慣常會產生只有團隊懂的 icon。正式進入 Icon Library 前，應至少拿給非專案成員做快速辨識測試。若需要口頭解釋才懂，就不適合直接上線。
視覺一致性規範：讓整套 icon 看起來像同一個系統
icon system 的一致性要檢查風格、筆畫、圓角、比例、留白、密度與視覺重量。
一致性不是把每顆圖示塞滿同樣面積。好的 icon 設計規範會讓不同形狀保持相近的存在感，方形、圓形、箭頭、人物都能在同一列看起來同屬一個產品。
線性、面性、雙色 icon 不要混用
線性 icon、面性 icon、雙色 icon 可以各自成立，但不應在同一個主要操作系統中混用。若產品同時需要多種風格，應明確定義使用層級，例如 UI 操作用線性，空狀態輔助才用面性。
視覺重量要一致，不是每顆都填滿同樣面積
視覺重量來自筆畫、填色面積、負空間與形狀複雜度。圓形 icon 通常看起來比方形輕，箭頭可能需要微調長度。這是我會堅持人工 QA 的地方，單靠數值檢查常抓不到。
圓角、端點、負空間要有共同語言
如果有些 icon 是尖角，有些是大圓角，使用者會感覺來自不同系統。規範應定義常用圓角半徑、線端樣式與最小留白，並在 Figma component 說明中留下範例。
可以突破網格，但必須維持視覺均衡
Grid 是秩序，不是牢籠。斜線、箭頭、三角形、播放符號常需要微調才能看起來置中。規範要允許有條件突破，但例外必須能通過實際元件截圖驗收。
不同 icon 類型的規範差異
不同 icon 類型要分開訂規範，因為功能 icon、導覽 icon、狀態 icon、App icon 與行銷 icon 的任務不同。
把所有 icon 放進同一套規格，會讓 UI 過度裝飾，也會讓品牌圖示被壓得太功能化。正確做法是用用途決定規格密度。
UI 功能 icon：以辨識速度與一致性為主
功能 icon 的核心是操作效率。它要縮小後仍清楚、放在按鈕中不搶文字、狀態變化可被系統控制。任何會降低辨識速度的裝飾都應移除。
導覽 icon：要搭配資訊架構與選單層級
導覽 icon 不只代表頁面，也代表使用者在產品中的位置。底部導覽、側欄、分頁的圖示要與 IA 命名一致，避免圖示暗示的意思和選單文字不同。
狀態 icon：不能只靠顏色傳達
狀態 icon 要能在低對比、色弱、黑白列印或輔助科技環境下保留意義。錯誤、警告、成功、等待、同步應使用不同符號結構，而不是只換紅色、黃色、綠色。
App icon：更重視品牌感、層次與平台規格
App icon 是產品入口，會出現在系統桌面、商店、通知與設定中。它可以有更完整的品牌語氣、層次與平台尺寸要求，但這套規格不應直接套到 UI 功能 icon。
行銷 icon：可更有情緒，但不能反過來污染 UI icon
行銷 icon 可以更有表情、更有裝飾性，也可以配合活動視覺。但它不應回流到產品主要操作介面，否則 Icon Library 會失去一致性。
如何在 Figma 建立可維護的 Icon Library
Figma Icon Library 要用分類、component、variant、命名、版本與審核規則管理，不能只是一頁圖示集合。
可維護的 Library 會讓設計師知道該重用哪一顆 icon，也讓工程師知道對應元件名稱。最怕的是每個頁面都有自己的 icon，最後沒有人知道哪一顆才是最新版。
先定義分類：action、navigation、status、object、brand
分類能降低搜尋成本。建議從用途分類，而不是從造型分類，因為團隊通常是為了找「刪除」、「返回」、「通知」這類功能，而不是找「圓角線性圖示」。
Component 命名規則：icon/action/add/24
命名要讓設計與工程對得起來。icon/action/add/24 表示這是一顆 action 類型、語意為 add、尺寸為 24px 的圖示。不要使用 icon/new_new_final 這種無法維護的名稱。
Variant 怎麼設：尺寸、狀態、填色模式
Variant 適合管理尺寸、狀態與填色模式，例如 size: 16、20、24，state: default、disabled，style: line、filled。若每顆 icon 都有自己的 variant 結構，Library 會變得難以搜尋與替換。
何時新增 icon？何時重用既有 icon？
當新功能語意已被既有 icon 覆蓋，應重用。當既有 icon 會造成語意誤解，才新增。新增前要檢查相似 icon、使用頁面、工程元件名稱與是否需要文字搭配。
Icon Library 的審核與淘汰規則
Library 需要定期淘汰重複、過時、語意分裂的 icon。每次新增都要記錄用途、尺寸、SVG 名稱、負責人與版本。沒有審核規則的 Library，通常半年後就會變成素材倉庫。
| Figma 項目 | 命名範例 | 用途 | 管理規則 |
|---|---|---|---|
| Action | icon/action/delete/24 |
操作行為 | 危險操作需檢查文字標籤 |
| Navigation | icon/navigation/home/24 |
頁面導覽 | 需對應 IA 與選單名稱 |
| Status | icon/status/warning/20 |
狀態提示 | 不能只靠顏色區分 |
| Object | icon/object/file/24 |
物件或資料型態 | 需避免和 action 語意衝突 |
| Brand | icon/brand/product-name/32 |
品牌或產品識別 | 不混入功能操作集 |
Icon 交付給工程師前要檢查什麼？
icon 交付前要檢查 SVG viewBox、尺寸、命名、stroke、fill、ARIA、tooltip、觸控範圍與元件對應。
設計稿看起來正確，不代表工程落地會正確。SVG 如果 viewBox 不一致，React component 命名對不上，或可互動 icon 沒有 aria-label，前端就會在每個頁面自行補洞。
SVG viewBox 要一致
同一尺寸系列的 SVG 應使用一致 viewBox，例如 24px icon 使用 viewBox="0 0 24 24"。若 viewBox 混亂，工程師很難用同一套元件控制尺寸與對齊。
Stroke 要不要轉 outline？
若前端需要透過 CSS 控制 stroke 顏色與狀態，保留 stroke 較彈性。若跨平台渲染不穩、線端樣式容易跑掉，轉 outline 較安全。規範要明確定義哪類 icon 採用哪種交付方式。
Icon font、SVG sprite、React component 怎麼取捨？
Icon font 適合舊系統延續，但可及性與渲染控制較受限制。SVG sprite 適合集中管理。React component 適合現代前端元件化，能把 size、color、aria-label 納入 props 控制。
元件命名與設計命名要對得起來
設計命名若是 icon/action/add/24，工程元件就應有可追溯名稱，例如 AddIcon 或 IconActionAdd。命名對不起來時，維護成本會轉嫁到工程搜尋與人工比對。
可互動 icon 需要 aria-label 或文字標籤
裝飾性 icon 可以設為輔助科技忽略；可互動 icon 則要讓螢幕閱讀器讀到功能，例如「刪除項目」、「開啟選單」。工程規範要把 aria-label 視為驗收條件，不是最後補充。
| 工程交付檢查項目 | 標準 | 為什麼重要 | 驗收方式 |
|---|---|---|---|
| SVG viewBox | 同尺寸系列一致 | 避免縮放與對齊失真 | 抽查 SVG 原始碼 |
| 尺寸 props | 支援設計系統尺寸 | 避免頁面自行寫死尺寸 | 檢查元件 API |
| 色彩控制 | 使用 currentColor 或 token | 讓狀態由元件控制 | 測試 hover、disabled、selected |
| 命名對應 | 設計與工程可追溯 | 降低維護與替換成本 | 比對 Library 與元件清單 |
| ARIA | 可互動 icon 有功能標籤 | 支援螢幕閱讀器 | 用輔助科技或測試工具檢查 |
| 觸控範圍 | 由按鈕容器提供足夠熱區 | 降低誤點與點不到 | 在手機版操作測試 |
可用性與無障礙規範：icon 不能只讓設計師看得懂
icon 無障礙規範要處理文字標籤、tooltip、觸控範圍、對比度、狀態提示與螢幕閱讀器。
可用性規範的重點是降低誤解與誤點。圖示再漂亮，如果按鈕太小、狀態只靠顏色、螢幕閱讀器讀不到功能，就不是合格的 UI 元件。
什麼情況 icon 可以不加文字？
只有在功能高頻、符號通用、位置固定、後果低風險時，才適合只顯示圖示。即使畫面上不顯示文字，工程仍應提供 aria-label，滑鼠介面也可用 tooltip 輔助理解。
觸控熱區不能等於圖示實際尺寸
24px icon 不代表可點擊區域只有 24px。手機與平板上的按鈕容器要提供足夠熱區，讓手指能穩定操作。設計稿要標示按鈕尺寸，而不是只標 icon 尺寸。
狀態 icon 不應只靠顏色
錯誤、成功、警告、資訊提示應同時透過形狀、文字與顏色傳達。只用紅色或綠色區分，會讓色弱使用者或低對比環境中的使用者失去關鍵線索。
螢幕閱讀器要讀到功能，不是讀到裝飾
螢幕閱讀器需要知道按鈕功能，而不是讀到「垃圾桶圖示」這種圖形描述。可互動 icon 應標示「刪除」，裝飾性 icon 則應從輔助科技樹中隱藏。
| 使用情境 | 建議標籤 | tooltip | 無障礙處理 |
|---|---|---|---|
| 工具列常用功能 | 可視畫面密度決定 | 建議提供 | 可互動元件加 aria-label |
| 危險操作 | 必須顯示文字 | 可補充後果 | 加確認流程與明確標籤 |
| 狀態提示 | 應搭配文字 | 可說明狀態原因 | 不可只靠顏色 |
| 裝飾圖示 | 不需要 | 不需要 | 設為輔助科技忽略 |
常見 icon 設計錯誤與修正方式
常見 icon 設計錯誤包含筆畫不一致、視覺重量失衡、小尺寸糊掉、語意抽象與不同來源混用。
icon QA 要用「問題、原因、修正規則」檢查，而不是只問好不好看。真正能降低維護成本的檢查，是能讓下一位設計師照著修。
筆畫粗細不一致
筆畫忽粗忽細會讓整套 icon 像來自不同來源。修正時先回到基準尺寸，檢查 stroke、端點、轉角與 outline 是否一致，再放回實際元件中比較。
同尺寸下視覺重量差太多
同樣是 24px，填色面積大的 icon 會比線條細的 icon 更重。修正時不要只看外框尺寸，要比較黑白面積、負空間與放在同列時的存在感。
圖形太密，縮到 16px 後糊在一起
複雜 icon 直接縮成 16px，細節常會黏在一起。正確做法是為小尺寸重畫簡化版，刪除次要線條，保留主符號輪廓與必要辨識點。
語意太抽象，使用者需要猜
抽象符號若沒有產品學習基礎，很容易造成誤解。修正時先回到功能動詞，例如新增、刪除、同步、篩選，再選用更接近使用者語境的符號。
不同來源 icon 混用，整套系統破碎
從多個來源拼湊 icon，常會造成筆畫、圓角、比例與視覺密度不一致。我的建議是先盤點與統一規格，再逐批替換，不要在沒有規範時急著重畫全部。
| QA 檢查項目 | 常見問題 | 修正規則 | 驗收方式 |
|---|---|---|---|
| 筆畫 | 線寬不一致 | 回到基準 stroke 與端點規則 | 同列比較 |
| 重量 | 有些 icon 特別重或特別淡 | 調整填色、負空間與尺寸補償 | 放入實際元件截圖 |
| 小尺寸 | 16px 無法辨識 | 重畫小尺寸版本 | 以 100% 顯示檢查 |
| 語意 | 使用者需要猜功能 | 改用通用符號或加文字 | 快速辨識測試 |
| 來源 | 多套風格混用 | 統一規範後分批替換 | Library 審核 |
Material、Apple、Microsoft、HarmonyOS 規範該怎麼參考？
平台規範應作為參考來源，用來理解尺寸、語意、平台一致性與互動慣例，再轉成自己的產品規則。
官方文件很有價值，但它們服務的是各自平台。產品團隊應吸收可用原則，避免直接複製後讓自己的設計系統失去主體性。
Material：適合參考系統性與尺寸規則
Material Design Icons 對 system icons、24dp 基準、幾何形狀與狀態透明度有清楚描述。適合參考尺寸系統與簡化邏輯，但仍要依產品密度與品牌語氣調整。
Apple：適合參考平台一致性與互動語境
Apple Human Interface Guidelines 強調 interface icon 要簡化、可辨識，並與系統符號和平台語境一致。若產品高度依賴 Apple 生態，應優先檢查是否與平台慣例衝突。
Microsoft：適合參考桌面系統與狀態表現
Microsoft Windows app icons guidance 適合參考桌面工具列、命令、導覽與系統語意。若產品是 SaaS 後台或桌面 Web App，這類密集操作情境很值得看。
HarmonyOS：適合參考情感、層次與 App icon 差異
HarmonyOS Design 較重視跨裝置、層次與系統視覺語氣。它適合拿來理解 App icon 與系統視覺的情感表現，但不宜直接套用到台灣 Web 產品的 UI 功能 icon。
不要把平台規範當成自己的產品規範
平台規範只能回答「在該平台上通常怎麼做」，不能回答你的產品語意、命名、交付與審核流程。Design System 維護者要把外部規範轉成內部可執行表格。
| 平台 | 適合參考 | 不宜直接複製 | 轉成產品規範的方式 |
|---|---|---|---|
| Material Design | 24dp、system icon、幾何簡化 | 完整視覺風格 | 採用尺寸邏輯，重訂品牌語氣 |
| Apple HIG | 平台語境、SF Symbols、簡化原則 | Apple 專屬互動假設 | 檢查 iOS 與 macOS 產品一致性 |
| Microsoft Fluent | 桌面操作、命令列、系統圖示 | Windows 專屬元件邏輯 | 用於後台與密集工具列參考 |
| HarmonyOS | 跨裝置、層次、App icon 語氣 | 平台視覺包裝 | 只吸收 App icon 與系統感差異 |
不建議納入本文的延伸主題
UI 圖示規範應排除免費素材、Logo、商標、AI 生成與純插畫教學，避免主題偏離 Design System。
這些主題都和 icon 有關，但搜尋任務不同。若混在同一篇規範中，讀者會拿不到真正需要的尺寸、命名、Figma Library、工程交付與 QA 標準。
- 免費 icon 素材下載與圖庫整理
- Logo 設計、品牌識別與商標註冊
- App icon 完整繪製教學
- 行銷插畫 icon 風格提案
- AI 生成 icon 工具介紹
- Photoshop 特效與裝飾性圖示教學
制定 icon 設計規範可以依照七個步驟進行：先定義 icon 類型與使用範圍，設定尺寸與網格，設定 stroke、corner、端點與密度，建立語意與命名規則，建立 Figma Icon Library，定義 SVG 與工程交付規格，最後用 QA checklist 定期檢查與汰換。
- 定義 icon 類型與使用範圍，先排除 App icon、Logo 與行銷插圖。
- 設定尺寸與網格，以 24px 作為主要基準，再規劃 16px、20px、32px。
- 設定 stroke、corner、端點與密度，讓整套 icon 有共同語言。
- 建立語意與命名規則，避免同一顆 icon 在不同頁面代表不同功能。
- 建立 Figma Icon Library，用 component、variant、分類與版本管理。
- 定義 SVG 與工程交付規格，包含 viewBox、元件名稱、ARIA 與狀態控制。
- 用 QA checklist 定期檢查與汰換，保留可用圖示，淘汰重複與語意混亂的圖示。
icon 設計規範一定要從 24px 開始嗎？
不一定，但 24px 很適合作為 UI 圖示規範的主要基準。它容易銜接多數介面元件與平台圖示邏輯，也方便往 16px、20px、32px 延伸。若產品是資料密集型後台，可以同時建立 20px 基準。
UI icon 和 App icon 的設計規範差在哪？
UI icon 代表介面操作，重點是辨識速度、一致性與工程交付。App icon 代表整個產品，重點是品牌記憶、平台尺寸與視覺層次。兩者應分開管理，不能用 App icon 的裝飾邏輯處理功能按鈕。
icon 可以只用線性風格嗎？
可以。線性風格適合多數 SaaS、後台、工具型產品，因為它較輕、可讀性高，也容易用 stroke 與 color token 管理狀態。要注意小尺寸下線條不能過細，重要狀態也不能只靠顏色。
什麼情況 icon 一定要搭配文字標籤？
危險操作、低頻功能、陌生功能、交易相關操作、權限變更與不可逆動作，都應搭配文字標籤。這些情境的錯誤成本高，圖示只能輔助辨識，不能取代明確文字。
icon 的 stroke 要不要轉 outline 再交給工程師？
若前端需要彈性控制線寬、顏色與狀態，可以保留 stroke。若渲染環境複雜，或線端、轉角在不同平台容易跑掉，轉 outline 較穩。重點是整套規範要一致，不能每顆 icon 自行決定。
Figma 裡的 icon library 要怎麼命名？
建議使用用途加語意加尺寸，例如 icon/action/add/24、icon/status/warning/20、icon/navigation/home/24。命名要能對應工程元件，避免使用 final、new、copy 這類暫存字。
不同尺寸的 icon 可以直接等比例縮放嗎？
不建議全部直接縮放。24px 縮到 16px 時，細節與負空間常會糊在一起。小尺寸 icon 應重畫簡化版，保留主符號與關鍵辨識點，刪除不必要的次要線條。
icon 怎麼判斷視覺重量是否一致？
把 icon 放在同一列、同一按鈕尺寸、同一顏色下比較。檢查筆畫粗細、填色面積、負空間、形狀複雜度與視覺中心。只看畫布外框尺寸不夠，實際元件截圖更可靠。
狀態 icon 可以只靠顏色區分嗎？
不應只靠顏色。錯誤、警告、成功、等待、同步等狀態應搭配不同符號結構、文字或輔助標記。這樣在色弱、低對比、黑白列印與螢幕閱讀器情境下仍能傳達狀態。
從 Material 或 Apple 規範複製過來可以嗎？
可以參考，不應直接複製。Material、Apple、Microsoft、HarmonyOS 都服務各自平台。產品團隊應吸收尺寸、語意與互動原則，再轉成自己的分類、命名、狀態、交付與 QA 規範。
既有產品 icon 很混亂，應該先重畫還是先整理規範？
先整理規範。盤點現有 icon、分類用途、找出重複與語意衝突，再決定哪些保留、哪些合併、哪些重畫。直接重畫容易只換風格，沒有解決命名、狀態與工程交付問題。
icon 設計規範要放在 design system 哪個章節？
建議放在 Foundations 或 Assets 章節，並與 Components、Accessibility、Content Guidelines、Engineering Handoff 互相連結。icon 規範不只是一組素材，它會影響按鈕、導覽、狀態提示與前端元件。