Figma Variable 是什麼?和設計 Token 有什麼關係?
Figma Variable 是 Figma 裡可重複使用、可集中管理的設計值;設計 Token 則是把顏色、間距、尺寸、狀態等設計決策命名後保存下來。當團隊把 figma variable 當成設計 Token 使用時,重點會從「套一個值」變成「管理一組可延伸的設計規則」。
例如品牌主色不要只記成 #2563EB,而是先建立 color.blue.500,再透過 alias 指到 color.bg.primary。間距也不要只在元件上填 16,而是建立 space.4,讓 button padding、card gap、section spacing 都能引用同一套空間尺度。
| 概念 | 負責的事 | 範例 | 設計交付價值 |
|---|---|---|---|
| Figma Variable | 在 Figma 內儲存可套用的值 | space.4 = 16 |
設計師能在檔案內集中維護值 |
| Design Token | 把設計決策命名成跨角色可理解的值 | button.bg.default |
設計與工程能討論同一個命名值 |
| Figma Variable 設計 Token | 用 Figma Variables 承接 token 架構 | color.bg.primary alias 到 color.blue.500 |
變更上游 token 時,下游 UI 能一起更新 |
Alice Wang 在整理設計系統時通常會先看一件事:團隊是不是只把 Variable 當成色票替代品。如果只是把十幾個顏色搬進 Variables,檔案會比較整齊,但還不能算真正可維護的 token 系統。
Figma Variable 支援哪些類型?
Figma Variable 主要支援 Color、Number、String、Boolean 四種類型。Color 適合顏色,Number 適合尺寸與間距,String 適合文字與字型相關值,Boolean 適合顯示或隱藏狀態;選錯類型會讓後續套用位置變少,也會增加維護成本。
| Variable 類型 | 適合放什麼 | 設計 Token 範例 | 常見限制 |
|---|---|---|---|
| Color | 純色、填色、描邊、文字顏色、部分效果顏色 | color.blue.500、color.text.primary |
複雜漸層與多層效果通常仍需要 Style 輔助 |
| Number | 間距、尺寸、圓角、字級、行高、透明度、描邊粗細 | space.4、radius.md |
同一個 number token 要靠 scope 避免被亂套 |
| String | 文字內容、字型名稱、字重名稱、多語系原型文字 | copy.cta.primary、font.family.sans |
字型名稱與字重需要和 Figma 可識別值一致 |
| Boolean | 顯示狀態、隱藏狀態、原型中的開關條件 | state.showBadge、state.isExpanded |
比較適合 prototype 或狀態示意,不適合承載複雜元件邏輯 |
Pixelcake 在做設計交付時,會把 Color 和 Number 視為最先整理的兩類。String 與 Boolean 很有用,但它們更容易被拿去做原型展示,若沒有命名規則,會很快變成難以追蹤的狀態清單。
如何在 Figma 建立第一組 Variable?
建立第一組 Figma Variable 的順序是:開啟 Local Variables,建立 Collection,新增 Variable,選擇類型,填入 Value,最後命名。第一組不要貪多,先用 8px spacing 和 brand color 做出可套用、可修改、可驗證的最小範例。
- 在 Figma 檔案中取消選取畫面上的物件,從右側的 Local variables 進入 Variables 管理介面;Figma 官方的 Create and manage variables and collections 也以這個流程作為基礎。
- 建立一個 Collection,先命名為
Core或Foundation,避免一開始就拆太多集合。 - 新增 Color variable,命名為
color.brand.primary,值填入品牌主色,例如#2563EB。 - 新增 Number variable,命名為
space.2,值填入8。 - 再新增
space.4,值填入16,讓卡片 padding 或按鈕左右間距可以引用。 - 在變數描述中補上用途,例如「主要品牌色,僅用於主要操作與重點視覺」。
第一組 token 的目標不是完整,而是讓團隊看見更新方式。當 color.brand.primary 改變時,已套用的元件會一起反映變更,這比在每個按鈕手動改顏色更接近設計系統的工作方式。
如何把 Variable 套用到顏色、間距、圓角與文字?
Variable 可以套用在 Fill、Stroke、Radius、Gap、Width、Height、Text content、Visibility 等屬性上。最適合 token 化的欄位,是那些會重複出現、需要統一調整、又容易在交付時造成落差的設計值。
| 套用位置 | 建議 Variable 類型 | 適合 token 化的原因 | 範例命名 |
|---|---|---|---|
| Fill、Stroke、Text fill | Color | 顏色是最常跨元件重複的設計值 | color.bg.primary、color.border.default |
| Gap、Padding | Number | 能維持空間節奏,降低版面忽大忽小 | space.2、space.4 |
| Corner radius | Number | 圓角常牽涉品牌感與元件一致性 | radius.sm、radius.full |
| Width、Height | Number | 適合 icon size、button height、container width | size.icon.md、size.button.lg |
| Text content、Font family | String | 適合原型文案、多語系預覽與字型值管理 | copy.empty.title、font.family.body |
| Visibility | Boolean | 適合狀態切換與原型示意 | state.showHelper |
- 選取要套用的圖層或元件。
- 在右側屬性欄找到對應欄位,例如 Fill、Stroke、Gap 或 Radius。
- 點選 Apply variable,或在支援的 number 欄位用等號開啟變數選擇器。
- 搜尋 token 名稱,選擇正確的 Variable。
- 套用後修改 Variable 原始值,確認畫面上的 UI 是否跟著更新。
有些欄位看起來都能套 number variable,但不代表應該共用同一個 token。space.4 可以用在 padding,不一定適合當 icon size;這種邊界要靠命名與 scope 控制。
Variable、Style、Component Variant 該怎麼選?
Variable 管單一設計值,Style 管多屬性樣式集合,Component Variant 管元件狀態。三者不是互相取代的關係;成熟的 Figma design token 架構通常會混用 Variables、Styles 和 Component Variants。
| 工具 | 最適合管理 | 適合情境 | 不適合情境 |
|---|---|---|---|
| Variable | 單一值 | 顏色、間距、尺寸、圓角、mode 值、alias token | 一次管理多個視覺屬性的完整樣式 |
| Style | 樣式集合 | 文字樣式、效果樣式、複合色彩樣式 | 需要 primitive 到 semantic 的多層 alias 架構 |
| Component Variant | 元件狀態 | button 的 size、type、state,input 的 error 或 disabled | 儲存顏色、間距、字級這類底層值 |
建議混用的方式是:底層用 Variable 管 token,文字組合用 Text Style,互動與狀態用 Component Variant。例如 button 的背景色來自 button.bg.default,文字樣式用 Text/Button/M,元件狀態則用 Variant 的 state=hover 或 disabled=true。
很多團隊的問題不是工具不夠,而是把每個工具都拿來解同一件事。當顏色被 Style、Variable 和元件 override 同時管理,後續一定會有人不知道該改哪裡。
如何用 Variable 實作 Design Token 分層?
如果要把 Variable 當成 design token,最重要的是先分清 primitive、semantic、component 三層。Primitive 保存原始值,semantic 表示用途,component 表示元件語境;這樣才能同時保留彈性與可讀性。
| Token 層級 | 負責內容 | 命名範例 | 值或 alias |
|---|---|---|---|
| Primitive token | 品牌或基礎尺度的原始值 | color.blue.500 |
#2563EB |
| Semantic token | 產品介面中的用途 | color.bg.primary |
alias 到 color.blue.500 |
| Component token | 特定元件的語境 | button.bg.default |
alias 到 color.bg.primary |
一組可維護的命名鏈會長這樣:color.blue.500 → color.bg.primary → button.bg.default。當品牌色調整,只改 primitive;當主要背景用途改成另一個色階,只改 semantic;當只有 button 要調整,才改 component token。
這是 Figma Variable 設計 Token 最容易被忽略的地方。沒有分層時,改一個色票會牽動太多未知畫面;分層後,變更的影響範圍比較容易被預測。
Collection 和命名規則怎麼設計才不會失控?
Collection 是管理 Variables 的範圍,命名規則則是讓團隊能找到並正確套用 token 的路徑。大型檔案不要只靠資料夾感覺整理,應該用 collection、group、alias、scope 一起控制複雜度。
- 同一批 token 需要共用 modes 時,放在同一個 collection,例如顏色的 light、dark mode。
- 不同維度且不需要同時切 mode 的 token,可以拆 collection,例如
Color、Spacing、Typography。 - 命名用由大到小的層級,例如
color.text.primary,不要混用primaryTextColor、Text Primary、文字主要色。 - 會被設計師直接套用的 token,名稱要偏用途;只作為底層引用的 token,名稱可以偏數值或色階。
- 用 scope 限制 number token 的可用位置,例如 radius token 只出現在 corner radius,不出現在 font size。
- 用 alias 建立上下游關係,不要讓每個 semantic token 都直接填 hex 或數字。
| 情境 | 建議拆 Collection | 建議合併 Collection |
|---|---|---|
| 亮暗模式顏色 | 不建議拆成 Light Color 和 Dark Color | 同一個 Color collection,用 modes 管不同值 |
| 間距與圓角 | 可拆成 Space / Radius,避免 number token 過多 | 小型系統可先放 Foundation |
| 多品牌系統 | 品牌差異很大時可拆品牌 collection 或使用延伸 collection | 同一產品線且只改少量色彩時,可先用 modes |
命名不是美化工作,是降低誤用率的設計。當新人看到 color.blue.500 和 color.bg.primary,他應該知道前者不該直接套在每個 UI 上。
Mode 不只亮暗模式:如何支援品牌、裝置與情境?
Variable mode 是同一個 variable 在不同情境下的值。它可以用於 light/dark,也可以用於 mobile/desktop、品牌 A/B、day/night、登入前後狀態;只要情境切換會影響同一組 token,就適合評估 mode。
| Mode 情境 | 適合的 Variable 類型 | 範例 | 注意事項 |
|---|---|---|---|
| Light / Dark | Color | color.bg.surface 在 light 是白色,在 dark 是深灰 |
不要把 mode 名稱寫進 token 名稱,避免重複 |
| Mobile / Desktop | Number | space.page.margin 在 mobile 是 16,在 desktop 是 64 |
只適合關鍵尺度,不要把所有 RWD 規則塞進 Figma |
| Brand A / Brand B | Color、String | color.brand.primary 對應不同品牌色 |
多品牌差異太大時要評估 collection 架構 |
| Day / Night | Color、Number | 車載、地圖、活動頁依使用情境切換對比 | 要另外檢查可讀性與對比,不只改色 |
| Prototype state | String、Boolean、Number | 切換購物車數量、顯示提示、展開區塊 | 不要把正式設計 token 與一次性原型狀態混在同一組 |
Figma 官方的 Modes for variables 提到 mode 可用來處理不同設計情境。實務上,mode 最怕被拿來當分類資料夾;如果情境之間不會切換同一組 variable,就不一定要用 mode。
2026 重點:Figma Variable Formulas 可以解決什麼問題?
Figma Variable Formulas 的價值在於處理可推導的 token,例如 spacing scale、尺寸比例、原型中的數值計算。它不應該被當成完整程式語言;適合放在規則清楚、計算關係穩定、團隊看得懂的地方。
截至 2026 年,Figma 官方文件中較明確的原生計算能力主要出現在 prototype expressions,例如用 number variables 做加減乘除、用 string variables 組合文字、用 boolean expressions 做條件判斷;可參考 Figma 的 Use expressions in prototypes。若團隊使用外掛、API 或內部同步工具來做 variables formulas,務必把來源、更新時機與責任人寫清楚。
| 問題 | 公式或 expression 適合嗎 | 範例 | 判斷 |
|---|---|---|---|
| spacing scale | 適合 | space.4 = baseSpace * 4 |
基準值穩定,推導關係清楚 |
| 卡片寬度推導 | 可評估 | cardWidth = containerWidth / 3 |
若只是設計稿尺寸,直接 token 可能更直覺 |
| 購物車原型小計 | 適合 prototype expressions | total = price * quantity |
屬於互動展示,不一定是正式 design token |
| 品牌色自動產生色階 | 不建議完全自動 | 由單一色彩推導整組色階 | 可讀性與對比需要人工檢查 |
我的判斷是:公式最適合輔助 number token,不適合取代設計判斷。尤其顏色、文字階層、可讀性這些項目,算得出來不代表用起來正確。
如何把 Variables 發布到 Library,讓團隊跨檔案共享?
Variables 要跨檔案共享,需要從來源檔案發布到 Figma Library。發布後,其他檔案才能啟用該 library 並套用 published variables;後續變更也要重新 publish,使用者才能接收更新。
- 準備一個設計系統來源檔案,集中放主要 components、styles 和 variables。
- 確認 variables 命名、description、scope、alias 都已整理完畢。
- 從 Assets 或 Library 入口進入發布流程。
- 選擇要發布的 variables、styles 或 components。
- 填寫更新描述,讓團隊知道這次改了什麼。
- 發布後,讓使用檔案啟用該 library 並檢查變數是否能套用。
Figma 官方 Publish a library 說明指出,components、styles、variables 起初只存在於目前檔案,要跨檔案使用就需要發布成 library;library 相關能力與方案限制可能調整,正式導入前應以 Figma 當前方案頁與工作區權限為準。
- 發布前檢查:是否有測試用 token 混在正式 collection。
- 發布前檢查:是否有命名重複或語意不清的 variable。
- 發布前檢查:alias 鏈是否能追到 primitive token。
- 發布前檢查:scope 是否讓 token 出現在正確欄位。
- 發布前檢查:更新描述是否能讓團隊理解影響範圍。
Variable Starter Kit:一套可直接開始的 Token 起手架
Variable Starter Kit 應該是最小可維護 token 集合,不是把所有可能用到的值一次塞滿。第一版建議先包含顏色、字級、間距、圓角、陰影顏色、狀態 token,讓團隊可以先完成主要元件與頁面驗證。
| 類別 | MVP token | 用途 | 備註 |
|---|---|---|---|
| Color primitive | color.neutral.0、color.neutral.900、color.blue.500 |
底層色階 | 不要直接大量套在 UI 上 |
| Color semantic | color.bg.default、color.text.primary、color.border.default |
介面用途 | 設計師最常直接套用 |
| Spacing | space.1、space.2、space.4、space.6 |
gap、padding、section spacing | 先用少量尺度,不要建立過密數列 |
| Radius | radius.sm、radius.md、radius.full |
卡片、按鈕、標籤圓角 | 用 scope 限制在 corner radius |
| Typography number | font.size.body、font.size.title、line.height.body |
字級與行高基礎值 | 仍可搭配 Text Style 管完整文字樣式 |
| Component token | button.bg.default、button.text.default、input.border.focus |
主要元件語境 | 先支援高頻元件,不要全元件一次做完 |
起手架越大,越容易在第一週就沒人敢改。比較務實的做法是先讓 button、input、card、page background 能跑通,再看哪些 token 真的被重複使用。
常見錯誤與排查:為什麼我的 Variable 找不到、套不上、Mode 沒生效?
Variable 找不到、套不上或 mode 沒生效,通常不是單一 bug,而是 collection、library、scope、mode 繼承或 used variables 清理出了問題。排查時要先確認變數是否存在,再確認它是否能出現在該屬性欄位。
| 錯誤 | 原因 | 檢查 | 解法 |
|---|---|---|---|
| Variable 套用時沒有出現在清單 | 類型不支援或 scope 限制 | 檢查 variable type 與 scope 設定 | 調整 scope,或建立正確類型的 variable |
| 跨檔案找不到 variable | 尚未發布 library,或目前檔案未啟用 library | 檢查來源檔案發布狀態與使用檔案 library 設定 | 發布 variables,並在目標檔案啟用 library |
| Mode 切換後畫面沒變 | 物件沒有套 variable,或 mode 套在錯誤層級 | 檢查 page、frame、object 的 mode 設定 | 把 mode 套在正確容器,並確認子層沒有覆寫 |
| on-canvas 調整後 variable 斷開 | 部分直接拖拉或手動調整會 detach number variable | 看欄位是否仍顯示 variable 綁定 | 重新套用 variable,並減少用畫布控制點改 token 欄位 |
| 刪掉 variable 後很多 UI 失去連動 | used variables 沒先清查 | 檢查 variable details、Dev Mode 或使用清單 | 先建立替代 token,再替換使用處,最後刪除 |
| 工程師看到的是 raw value | 設計稿曾 detach,或該值沒有對應 variable | 在 Dev Mode 檢查 variable details 或 suggested variables | 補套正確 variable,並整理 code syntax |
清理 used variables 時不要急著刪。比較穩的流程是先標記疑似不用的 token,搜尋使用處,替換到新 token,檢查主要元件與頁面,再做刪除。大型檔案裡,刪除比新增更需要紀錄。
哪些情境不該用 Figma Variable?
Figma Variable 不適合每一種設計值。當專案很小、值只用一次、樣式包含多個屬性、或變更後無法帶來維護價值時,用 Variable 反而會讓檔案更難讀。
- 小型一次性活動頁:如果只有一頁、視覺不會延伸成系統,直接使用局部樣式可能更快。
- 複雜文字樣式:字級、行高、字重、段落間距通常還是需要 Text Style 組合管理。
- 圖片與素材:Variable 不是圖片管理工具,不適合承載視覺素材規劃。
- 多層陰影與複合效果:可以用 Color variable 輔助效果顏色,但完整 effect style 仍適合由 Style 管。
- 只為了看起來專業而建立 token:沒有命名規則與維護流程,Variable 會變成另一種雜物櫃。
- 高變動探索稿:早期探索階段可以先保留彈性,等方向穩定後再 token 化。
反面案例很常見:一個 banner 只用一次,卻建立了 banner.special.bg、banner.special.text、banner.special.radius。這些 token 沒有重用價值,只會讓真正重要的 design token 更難被找到。
實作順序建議:從 10 個 token 開始,不要一次搬完整系統
導入 Figma Variable 設計 Token,建議從 10 個左右的高頻 token 開始,先驗證命名、套用、mode、發布與清理流程。一次搬完整系統看起來完整,實際上更容易把舊問題搬進新架構。
| 階段 | 目標 | 建議工作 | 完成標準 |
|---|---|---|---|
| MVP | 讓核心元件可用 | 建立顏色、間距、圓角各少量 token,套到 button、input、card | 修改 token 後,主要元件會正確更新 |
| 擴充 | 補足語意與 mode | 加入 semantic token、light/dark 或 mobile/desktop mode | 至少一個頁面能用 mode 完成情境切換 |
| 治理 | 讓團隊能長期使用 | 整理 scope、description、library 發布、used variables 清理流程 | 其他檔案能啟用 library 並正確套用 token |
- 先 audit 現有檔案,找出最常重複的顏色與間距。
- 建立第一批 primitive 與 semantic token。
- 套用到少數高頻元件,不要全檔案一次替換。
- 測試 mode、scope、alias 是否符合預期。
- 發布到 library,讓另一個檔案實際引用。
- 建立清理節奏,定期移除重複、未使用或命名失準的 variables。
好的 token 系統不是 token 數量最多,而是每個 token 都知道自己為什麼存在。從少量開始,團隊比較能建立共同語言,也比較不會在第一版就被維護成本壓垮。
Figma Variable 是什麼?
Figma Variable 是 Figma 中可重複使用並集中管理的設計值,可套用到顏色、數字、文字與布林狀態等屬性。它常用來承接設計 Token,讓顏色、間距、尺寸、模式與元件狀態更容易維護。
Figma Variable 跟 Design Token 一樣嗎?
不完全一樣。Design Token 是一種命名設計值的方法,Figma Variable 則是 Figma 裡實作這些命名值的工具。可以把 Figma Variable 視為設計端管理 design token 的方式之一。
Figma Variable 免費版可以用嗎?
Figma 官方文件目前指出,建立與使用 variables 的基本能力可在任何方案使用,但 modes、prototype variables、library 發布等功能可能受方案限制。方案與權限會調整,正式導入前請以 Figma 當前方案頁與工作區設定為準。
如何在 Figma 設定 Variable?
先取消選取物件,開啟 Local Variables,建立 collection,再新增 variable、選擇 Color、Number、String 或 Boolean 類型,填入值並命名。第一組建議從品牌主色與 8px spacing 開始,方便測試套用與更新。
如何套用 Variable Mode?
先在同一個 collection 裡建立多個 mode,例如 Light 與 Dark,並為每個 variable 填入各 mode 的值。套用 variable 後,可在 page、frame 或物件層級選擇 mode;若物件維持 Auto,通常會繼承上層容器的 mode。
Variable 和 Style 差在哪裡?
Variable 儲存單一原始值,例如一個顏色或一個數字;Style 儲存多屬性樣式集合,例如完整文字樣式或效果樣式。設計系統裡常見做法是用 Variable 管底層 token,再讓 Style 引用這些 token。
Color、Number、String、Boolean Variable 分別適合用在哪裡?
Color 適合填色、描邊、文字顏色;Number 適合 spacing、radius、size、font size、line height;String 適合文字內容、字型名稱、原型文案;Boolean 適合顯示隱藏與原型狀態。若不確定,先從 Color 與 Number 開始最穩。
Figma Variable Formulas 可以拿來做 spacing scale 嗎?
可以評估,但要看團隊使用的是 Figma 原生 prototype expressions、外掛,還是內部同步工具。spacing scale 這類數字推導很適合公式化,例如以 base spacing 推出 8、16、24、32;但正式設計 token 仍要保留清楚命名與人工檢查。
如何找出某個 Variable 被哪些元件使用?
可先從 variable details、Dev Mode 檢查使用資訊,並在主要元件與頁面中搜尋相關命名。清理前不要直接刪除,先建立替代 token、替換使用處、確認畫面沒有斷連,再刪除舊 variable。
為什麼我的 Variable 套用時沒有出現在清單裡?
常見原因是 variable 類型不支援該欄位、scope 限制了可用位置、library 沒啟用,或該 variable 尚未發布到跨檔案可用的 library。先檢查 type 與 scope,再確認來源檔案與目標檔案的 library 狀態。
什麼情況應該用 Style,而不是 Variable?
當你要管理的是多屬性組合,而不是單一值,就應該優先考慮 Style。例如完整文字樣式、陰影效果、複合色彩樣式,都比單一 variable 更適合用 Style 管理。Variable 可以作為 Style 裡的底層值。
團隊要怎麼把 Variables 發布到 Library 共用?
先在設計系統來源檔案整理 variables,確認命名、scope、alias 與 description,再從 Library 發布流程選擇要發布的 variables。發布後,其他檔案需啟用該 library 才能跨檔案套用;後續每次修改也要重新 publish,團隊才會收到更新。