Figma Component 是什麼？和 Instance 有什麼差別？
Figma Component 是可重複使用的 UI 元件，Main Component 是來源，Instance 是可放到不同畫面使用的複本。做得好的 figma component 會讓按鈕、卡片、輸入框在不同頁面保持一致，同時允許必要的文字、icon、狀態覆寫。
初學者最常卡住的地方，是把「複製一個圖層」誤以為「建立元件」。複製圖層只是在畫面上多一份設計，後續改高度、字級、圓角時，每一份都要手動修；Component 則會保留來源關係，讓主元件修改後能同步到 Instance。
| 概念 | 作用 | 實務例子 |
|---|---|---|
| Main Component | 定義元件的基礎樣式、結構與 Component Properties | 一顆主要按鈕的高度、字級、內距、圓角 |
| Instance | 從 Main Component 產生的可重複使用複本 | 出現在首頁、結帳頁、會員頁的同一顆按鈕 |
| Override | 在 Instance 上調整允許改的內容 | 把按鈕文字從「送出」改成「立即預約」 |
Main Component 與 Instance 的關係
Main Component 像元件的來源檔，Instance 像被放到各頁面的使用版本。當主元件的圓角、內距或預設顏色被調整，Instance 會跟著更新；但 Instance 上已覆寫的文字、替換過的 icon，通常會保留自己的設定。
| 修改位置 | 會影響什麼 | 適合情境 |
|---|---|---|
| Main Component | 同步基礎結構與樣式到相關 Instance | 統一按鈕高度、卡片陰影、輸入框邊框 |
| Instance | 只影響該畫面中的使用版本 | 更換文案、切換狀態、替換指定 icon |
什麼可以 Override？什麼不該亂改？
Override 是情境調整，不是把元件重新做一遍。文字、顏色、icon swap、顯示或隱藏輔助文字，通常可以透過 Component Properties 控制；如果每次用到 Instance 都要改高度、拆圖層、重排 Auto Layout，代表主元件架構本身需要回頭整理。
| Do | Don’t |
|---|---|
| 用 Text Property 改按鈕 label | Deep select 進去亂改文字圖層名稱 |
| 用 Boolean 控制 icon 是否顯示 | 每次手動刪掉 icon 圖層 |
| 用 Instance swap 替換允許的 icon | 貼上任意 SVG 破壞元件結構 |
| 保留 Instance 與 Main Component 的連動 | 一遇到不好改就 Detach Instance |
如何建立第一個 Figma Component？
建立第一個 Figma Component 的重點，是先選一個結構穩定、狀態少的 UI，再把它轉成 Component，拖出 Instance 測試同步。新手不要一開始就挑 Button，因為按鈕牽涉 Type、State、Size、Icon，複雜度比想像高。
- 先整理圖層名稱，例如 Header、Title、Description、Action。
- 選取完整 UI 物件，例如 Page Header。
- 使用 Create component 建立 Main Component。
- 從 Assets 或複製方式拖出一個 Instance。
- 修改 Main Component 的字級、間距或背景，檢查 Instance 是否同步。
- 在 Instance 上改文案，確認覆寫不會破壞主元件更新。
用 Page Header 練習，比直接做 Button 更容易看懂 Component 的價值。Header 通常只有標題、副標、右側按鈕，狀態少，卻能明顯感受到「一次修改、多處同步」的工作方式。
初學者應該先做哪一種 Component？
初學者適合從少狀態、少尺寸、少互動的元件開始。Badge、Card Header、Page Header 都比完整 Button 更適合入門，因為它們不需要立刻處理 hover、disabled、loading、icon position 等變體。
- Page Header：適合練習主標、副標、右側操作區。
- Badge：適合練習文字與顏色，但不要先塞太多狀態。
- Card Header：適合練習 title、metadata、action button 的組合。
- Simple Empty State：適合練習 icon、標題、描述與按鈕的基本結構。
Button 很常見，但它其實是設計系統裡最容易失控的元件之一。新手先用簡單元件理解 Main Component 與 Instance，再進入 Variants，學習曲線會穩很多。
建立後一定要測試 Instance
Component 建好後不能只看 Main Component 漂不漂亮，一定要測 Instance。元件的成功標準，是它被放到不同畫面後仍然能同步、能覆寫、能被下一位設計師理解。
- 同步檢查：修改 Main Component 的基礎樣式，Instance 是否更新。
- 覆寫檢查：Instance 改文字後，主元件更新時文字是否保留。
- 使用檢查：從 Assets 找得到元件，名稱是否能被搜尋理解。
Variants 是什麼？什麼時候該用 Variant？
Variants 適合管理同一種元件的可預測版本，例如 Button 的 size、state、type。只要差異可以被清楚列成選項，就可以考慮 Variant；如果只是改文案、換 icon 或顯示輔助文字，通常應該先看 Component Properties。
| 差異類型 | 建議做法 | 例子 |
|---|---|---|
| 可枚舉的狀態 | 用 Variant | Default、Hover、Pressed、Disabled |
| 可枚舉的尺寸 | 用 Variant | Small、Medium、Large |
| 文字內容不同 | 用 Text Property | 送出、取消、查看詳情 |
| icon 有無 | 用 Boolean Property | Show icon true 或 false |
| icon 種類不同 | 用 Instance swap | Arrow、Search、Download |
Component、Variant、Property、Nested Component 決策樹
判斷元件架構時，先問差異是不是同一個用途下的固定版本，再問使用者是否只需要調整局部內容。我的經驗是，很多失控的 Figma component library 不是元件做太少，而是把所有差異都急著做成 Variant。
- 這個 UI 會重複出現嗎？會，建立 Component；不會，先保留一般 frame。
- 它是同一用途的固定版本嗎？例如大小、狀態、類型，使用 Variants。
- 它只是控制顯示、文字或替換 icon 嗎？使用 Component Properties。
- 它裡面有可重用的小元件嗎？例如 icon、avatar、input，使用 Nested Component。
- 它需要自由編排內容嗎？例如 modal 內容區、card body，考慮 Slot Property 或清楚的內容容器。
只改顏色或字級時，先考慮 Style / Variable
如果差異只是 color token、字級、間距值，不一定要新增 Variant。樣式值應該先看 Style、Variable 或 design token 是否能承接，避免 Button 因為品牌色、深淺模式、字級微調而爆出一堆低價值版本。延伸可看 Design Token 與 Figma 樣式管理。
Variant Property 怎麼設計才不會失控？
Variant Property 的設計核心，是把「屬性」當成軸，把「值」當成選項。Button 可以有 Type、State、Size、Icon；Input 可以有 State、Type、Alignment；Table 和 Card 則要小心，內容越自由，越不適合硬做大量 Variants。
| 元件 | 適合的 Variant Property | 不建議硬塞的內容 |
|---|---|---|
| Button | Type、State、Size | 每一種 icon 都做成 Variant |
| Input | State、Type、Alignment | 每一段 helper text 都做成 Variant |
| Table | Density、Selection、Header style | 每一種欄位內容都做成 Variant |
| Card | Layout、Media、Action area | 每一種文案長度都做成 Variant |
Button 範例：Type / State / Size / Icon
Button 的 Variant Property 通常先拆 Type、State、Size，Icon 是否顯示則更適合交給 Boolean 或 Instance swap。這樣設計師在 Instance 上切換按鈕時，會看到接近前端 props 的控制方式。
| Property | Values | 建議 |
|---|---|---|
| Type | Primary、Secondary、Tertiary、Danger | 對應按鈕語意，不要用 Blue、Gray 當主要命名 |
| State | Default、Hover、Pressed、Disabled | 相同用途不同狀態才放進 Variant |
| Size | Small、Medium、Large | 尺寸要對應實際高度與 padding 規則 |
| Icon | None、Leading、Trailing | 若只是顯示與否，可改用 Boolean |
按鈕視覺規範可延伸到 Button Design Guidelines，但在 Component 階段要先把屬性軸收乾淨。
Input 範例：State / Type / Alignment
Input 的重點是狀態與內容區域。Default、Focus、Error、Disabled 適合成為 State；left icon、right icon、helper text 是否顯示，則常用 Boolean 或 Instance swap 管控。
| Property | Values | 常見錯誤 |
|---|---|---|
| State | Default、Focus、Error、Disabled | 把錯誤文案本身做成 Variant |
| Type | Text、Password、Search | 把每個 placeholder 都做成一顆元件 |
| Alignment | Left、Center、Right | 為了少數金額欄位新增整套 Input |
表單設計可搭配 Form Design Best Practices 一起看，Component 階段先處理結構，不要把內容策略混進屬性軸。
Table / Card 何時不要硬做成大量 Variants
Table 和 Card 的內容彈性很高，最容易出現元件爆炸。假設 Table 有 4 種欄位、3 種 density、3 種 selection state、2 種 header style，很快就會變成設計師不想維護的 component set。
比較務實的做法，是把 row、cell、checkbox、avatar、status badge 做成 Nested Component，再讓上層 Table 控制密度與選取狀態。Card 也是同理，圖片區、標題區、action 區可以拆清楚，但內文長短與自由內容不該全部變成 Variant。
Component Properties 有哪些？如何使用？
Component Properties 是控制 Instance 可調整內容的介面，常見類型包含 Boolean、Text、Instance swap、Variant、Slot。它讓設計師不用 deep select 到圖層深處，也能在右側面板改顯示、文案、替換實例與切換狀態。
| Property 類型 | 用途 | 適合例子 |
|---|---|---|
| Boolean | 控制圖層顯示或隱藏 | Show icon、Show helper text |
| Text | 讓 Instance 可改文字字串 | Button label、Input placeholder |
| Instance swap | 替換指定的 nested instance | Icon、Avatar、Trailing action |
| Variant | 切換 component set 裡的可預測版本 | State、Size、Type |
| Slot | 建立可自由編排的內容區域 | Modal body、Card content、Task list |
Boolean Property：控制 icon、label、輔助文字顯示
Boolean Property 適合處理 true 或 false 的顯示切換。例如 Button 是否顯示 leading icon，Input 是否顯示 helper text，Card 是否顯示 metadata。這類差異不值得新增一整組 Variant。
我通常會把 Boolean 命名成 Show icon、Show helper text、Show badge，而不是 Icon、Helper、Badge。使用者看到 Show 開頭，比較容易理解它是在控制顯示狀態。
Text Property：讓 Instance 可改文案
Text Property 適合讓 Instance 修改 label、placeholder、helper text。它比 deep select 進去改文字層更穩，因為使用者不需要知道內部圖層在哪裡，也比較不會誤改 Auto Layout 或樣式。
- 在 Main Component 選到文字圖層。
- 建立 Text Property，例如 Label 或 Placeholder。
- 拖出 Instance 後，在右側面板直接修改文字值。
Instance Swap Property：替換 icon 或 nested component
Instance swap 適合替換已被允許的 nested component，例如按鈕 icon、使用者頭像、卡片右上角操作按鈕。搭配 preferred instances，可以限制可替換範圍，避免設計師把不相干的元件塞進同一個位置。
以 Button 來看，leading icon 可以設定成只允許 Icon/Arrow、Icon/Search、Icon/Download 這類同尺寸 icon。這比讓每位設計師手動貼圖更穩，也更接近前端元件的 icon prop。
Slot Property：複雜內容區塊的彈性做法
Slot Property 適合處理 modal、card、task list 這種內容區塊自由度高的元件。它的價值在於讓 Instance 內部可以新增、編排內容，同時保留元件系統的外框與規則。
Slot 相關功能狀態應以 Figma 官方文件為準，特別是團隊正在跨檔案使用 library 時，不要把仍在調整中的行為寫進不可改的交付規範。2026 年的實務判斷是：自由內容用 Slot 或清楚的內容容器，固定狀態才用 Variant。
Nested Component 的實務用法
Nested Component 是把基礎元件放進高階元件裡重用，例如 Card 裡放 Button、Avatar、Badge。它能讓基礎元件的狀態和屬性被保留下來，也能避免每個高階元件都各自複製一份 icon 或 button。
真正好維護的 Figma Component Variants Properties 架構，通常不是一顆巨大元件包全部，而是基礎元件與高階元件分工清楚。這一點在多人協作檔案中特別明顯，因為元件越大，越容易讓使用者找不到該改哪裡。
什麼適合做成 Nested Component？
適合巢狀化的單元，通常是重複出現、具備狀態、會被其他元件引用的 UI。不要只因為畫面上出現一次就急著元件化，要看它是不是會被多處共用。
- Icon：常被 button、input、nav、card 使用。
- Button：常被 modal、card、empty state 使用。
- Input：常被 search bar、filter panel、form group 使用。
- Avatar：常被 comment、profile card、team list 使用。
- Badge：常被 table、card、notification 使用。
什麼不適合巢狀化？
一次性的 layout、特殊活動頁模組、只服務單一頁面的裝飾區塊，不一定要做成 Nested Component。過度拆分會讓設計師每次修改都要追三層元件，維護成本反而上升。
| 適合巢狀化 | 不適合巢狀化 |
|---|---|
| 多處共用的狀態元件 | 只出現一次的特殊版面 |
| 有固定尺寸與替換規則的 icon | 每次內容都不同的自由排版 |
| 高階元件裡會反覆使用的 button | 臨時活動頁的單次視覺模組 |
Figma Component 如何對應前端 Props？
Figma Property 可以視為設計端的 props 語言：Type、Size、State、Disabled、Icon 這些控制項，應該能對應到 React 或 Vue component 的 props。命名越一致，設計交付給前端時越不容易失真。
這裡不需要把設計師變成工程師，但需要讓元件語言能互相翻譯。當 Figma 裡叫 Type，前端卻叫 variant；Figma 裡叫 State，前端拆成 disabled、loading，交付文件就要把對應關係寫清楚。
Button 在 Figma 與 React Props 的對應
| Figma Property | React Props 思維 | 例子 |
|---|---|---|
| Type | variant | primary、secondary、danger |
| Size | size | sm、md、lg |
| State: Disabled | disabled | true、false |
| Icon | icon 或 iconPosition | leading、trailing、none |
<Button variant="primary" size="md" disabled={false} icon="arrow">
立即預約
</Button>這段 pseudo-code 的目的不是讓設計稿產生程式，而是讓設計師與工程師知道同一顆 Button 的控制邏輯是否一致。前端元件規劃可延伸看 Design System Component Library 實務整理。
命名要讓設計師與工程師都看得懂
命名規則要避免 Property 1、Variant 2、Blue Button 這種只有製作者懂的名稱。Type、State、Size、Icon、Alignment 這些字雖然普通，但跨設計與開發最穩。
- Figma 可用 Type，前端可對應 variant。
- Figma 可用 Size，前端維持 size。
- Figma 可用 State，前端依需要拆成 disabled、loading、selected。
- 設計端用 readable values，例如 Primary；前端可轉成 primary。
Figma Component 如何處理 RWD 與 Breakpoint？
Figma Component 可以模擬 responsive component 的不同 viewport 狀態，但不能取代真正的 CSS breakpoint。Desktop、Tablet、Mobile 可以用 Variant 表達設計版本；寬度伸縮、padding、hug/fill 則應交給 Auto Layout 與 Constraints。
以 Header 來看，Desktop 版可能有完整 nav、搜尋、會員按鈕；Mobile 版可能只保留 logo 與 menu icon。這種版型差異可枚舉，適合用 Variant。若只是內容區寬度變化，通常不需要新增 Mobile Variant。
何時用 Variant 模擬 Desktop / Mobile？
| 情境 | 建議 | 原因 |
|---|---|---|
| Header 結構不同 | 用 Viewport Variant | Desktop 與 Mobile 元素數量不同 |
| Card 排列方向不同 | 可用 Variant | 橫向與直向是明確版本 |
| 只是寬度變窄 | 先用 Auto Layout | 這是 layout 行為，不是元件狀態 |
| 每 100px 都有不同樣式 | 不要全做 Variant | 會造成難以維護的 viewport 組合 |
何時交給 Auto Layout 與 Constraints？
padding、hug content、fill container、min width、左右固定距離，這些屬於 layout 行為，應該先交給 Auto Layout 與 Constraints。Variant 適合描述狀態，Auto Layout 適合描述伸縮規則，兩者混用錯誤會讓檔案很快變亂。
基礎概念可以搭配 Figma 基礎操作、8pt Grid 與間距系統 閱讀，但 Component 本身要維持清楚：可枚舉差異才做 Variant，可伸縮行為先用 layout。
Figma Component 命名與維護規則
Figma Component 命名是搜尋、替換、交付的基礎。好的命名會讓設計師在 Assets 和 Swap instance 裡快速找到元件；壞命名會讓同一顆按鈕在 8 個頁面出現 8 種高度，最後沒人敢改 Main Component。
命名不用複雜，但要穩定。元件層級、用途、狀態、尺寸要有一致規則，並在 component set 裡補上描述與文件連結。命名規範可延伸看 Design System 命名規則。
Slash naming 怎麼用？
Slash naming 使用斜線建立資產層級，例如 UI/Button/Primary 或 Icon/Action/Search。這會影響 Assets 面板與 Swap instance 的搜尋體驗，也會讓同類元件更容易被分組理解。
| 命名 | 適合用途 |
|---|---|
| UI/Button/Primary | 主要按鈕 |
| UI/Input/Search | 搜尋輸入框 |
| Icon/Action/Download | 下載圖示 |
| Feedback/Badge/Success | 成功狀態標籤 |
避免元件爆炸的 5 條規則
- 同一用途的狀態差異用 Variants，不要拆成多顆獨立 Component。
- 只控制顯示或隱藏時，用 Boolean，不要新增整組 Variant。
- 可替換 icon 用 Instance swap，不要為每個 icon 建一個 Button Variant。
- 文案用 Text Property，不要把每一句文案做成元件版本。
- 稀有組合可以不建，讓實際需求決定是否補上。
維護成本可以粗略理解成元件數量乘上狀態數，再乘上使用檔案數。這不是精確公式，但足夠提醒團隊：每新增一個 Variant 軸，都會讓後續維護更重。
可以直接用免費 Figma Component Library 嗎？
免費 Figma Component Library 可以當起點，但不能直接等同可維護系統。拿到 UI kit 後，要先檢查 Variants、Component Properties、Auto Layout、命名、授權與更新狀態，再決定是否放進正式專案。
免費素材最大的風險不是不好看，而是結構不符合團隊工作方式。很多 UI kit 視覺完整，但沒有合理的 properties，或命名只方便展示，不方便交付。元件庫選型可參考 Figma Component Library 評估指南。
評估免費元件庫的 6 個標準
| 標準 | 檢查問題 |
|---|---|
| Variants | 狀態、尺寸、類型是否被清楚整理成 component set？ |
| Properties | 是否提供 Boolean、Text、Instance swap 等可控項？ |
| Auto Layout | 內容變長時是否能合理伸縮？ |
| 命名 | Assets 與 Swap instance 裡是否容易搜尋？ |
| 授權 | 是否允許商用，是否需要標示來源？ |
| 更新 | 是否仍符合目前 Figma Component Properties 的使用方式？ |
常見錯誤：Figma Component 為什麼越做越難用？
Figma Component 越做越難用，通常是架構失控，不是工具本身不好用。常見原因包含 Variant 軸太多、命名混亂、Detach Instance 濫用、Override 破壞結構，以及把所有差異都做成獨立元件。
| 問題 | 症狀 | 修正方向 |
|---|---|---|
| 狀態拆成獨立元件 | Button Default、Button Hover、Button Disabled 分散各處 | 合併成 component variants |
| Variant 軸太多 | 使用者找不到正確組合 | 把文字、icon、顯示控制移到 Properties |
| 命名混亂 | 出現 Final Button、New Button、Button 2 | 建立 slash naming 與固定屬性名稱 |
| 濫用 Detach | 主元件更新後畫面沒有同步 | 回到 Override 與 Properties 解決 |
每個狀態都做成獨立元件
Before：Button Default、Button Hover、Button Pressed、Button Disabled 都是獨立 Component。After：建立 Button component set，用 State 這個 Variant Property 管理 Default、Hover、Pressed、Disabled。
相同用途、不同狀態的元件，優先進 Variants。這樣使用者在 Instance 上切換狀態時，不需要重新找另一顆元件，也能保留同一套命名與結構。
Variant 軸太多，導致組合爆炸
Type x Size x State x Theme x Icon x Loading 會快速膨脹成難以維護的組合。更合理的流程是先保留 Type、Size、State 這種核心軸，再把 Icon、Loading、Label、Helper text 移到 Component Properties。
- 列出目前所有 Variant Property。
- 刪掉只是顯示或隱藏的軸，改用 Boolean。
- 刪掉只是換內容的軸，改用 Text 或 Instance swap。
- 保留真正代表元件版本的軸，例如 Type、Size、State。
- 檢查稀有組合是否真的需要存在。
一改 Instance 就 Detach
Detach Instance 會切斷元件與 Main Component 的更新關係，只適合少數特殊情境，例如一次性活動頁需要完全客製。日常產品介面不應該把 Detach 當成修改元件的第一反應。
如果你每次都想 Detach，通常代表主元件少了必要的 Property，或 Variant 軸設計不合理。先回頭補 Text、Boolean、Instance swap、Nested Component，比切斷連動更能保住後續維護性。
Figma Component 是什麼？
Figma Component 是可重複使用的 UI 元件，適合用來管理按鈕、輸入框、卡片、導覽列等會在多個畫面出現的設計物件。它由 Main Component 定義基礎結構，並透過 Instance 放到不同頁面使用。
Main Component 和 Instance 差在哪裡？
Main Component 是來源，Instance 是複本。修改 Main Component 的基礎樣式會同步到相關 Instance；Instance 可以保留允許的覆寫，例如文字、icon 或狀態切換。
Figma Variants 適合用在哪些情境？
Variants 適合同一種元件的可預測版本，例如 Button 的 Type、Size、State，或 Input 的 Default、Focus、Error、Disabled。不可預測的自由內容，不適合全部做成 Variant。
Component Properties 有哪幾種？
常見 Component Properties 包含 Boolean、Text、Instance swap、Variant、Slot。Boolean 控制顯示隱藏，Text 控制文字，Instance swap 控制替換實例，Variant 控制版本切換，Slot 處理彈性內容區域。
Button Component 的 Variant Property 應該怎麼拆？
Button 通常先拆 Type、State、Size。Type 可包含 Primary、Secondary、Danger；State 可包含 Default、Hover、Pressed、Disabled；Size 可包含 Small、Medium、Large。Icon 顯示與替換則多半交給 Boolean 或 Instance swap。
Figma Component 可以像前端 Props 一樣設計嗎？
可以用接近前端 props 的方式設計命名與控制項。例如 Figma 的 Type 可對應 React 的 variant，Size 對應 size，Disabled 對應 disabled。這能讓設計與開發在交付時使用同一套語言。
Nested Component 什麼時候該用？
當某個基礎元件會被多個高階元件重複使用，就適合做成 Nested Component。常見例子包含 icon、button、avatar、badge、input。只出現一次的特殊 layout 不必急著巢狀化。
Figma Component 可以處理 RWD breakpoint 嗎？
Figma Component 可以用 Variant 模擬 Desktop、Tablet、Mobile 等 viewport 狀態，但它不等同真正的 CSS breakpoint。尺寸伸縮應先交給 Auto Layout 與 Constraints，版型差異明確時再用 Variant。
免費 Figma Components 可以直接拿來做專案嗎？
可以當起點，但不建議不檢查就直接放進正式專案。要先確認授權、命名、Variants、Component Properties、Auto Layout 與更新狀態，避免素材好看但後續難維護。
需要用 plugin 管理 Figma Components 嗎？
Plugin 可以輔助檢查命名、整理圖層或產生文件，但不應取代元件架構決策。Component、Variants、Properties、Nested Component 的規則先定清楚，再考慮用 plugin 加速維護。
為什麼我的 Component Library 越做越亂？
常見原因是每個狀態都拆成獨立元件、Variant 軸太多、命名沒有規則、Instance 常被 Detach，或 Override 被拿來重做元件。先整理命名與屬性軸，通常比繼續新增元件更有效。
2026 年使用 Component Properties 有什麼要注意？
2026 年使用 Component Properties 時，要以 Figma 官方目前功能名稱與右側面板行為為準。特別是 Properties 會更集中顯示，設計系統文件應清楚寫出哪些內容可改、哪些狀態應切換、哪些結構不應 Detach。