Figma Dev Mode 是什麼？它解決哪個設計交付問題
Figma Dev Mode 是設計稿交付給工程師時使用的開發者模式，重點是讓工程師快速讀取尺寸、間距、色彩、字體、資產與程式碼參考。
在一般設計協作裡，工程師常要問設計師：「這裡幾 px？這個狀態有沒有 hover？icon 要匯出哪種格式？」Dev Mode 把這些資訊集中在同一個介面，讓設計稿從「看起來完成」變成「可以被開發接收」。Figma 官方也把 Dev Mode 定位在設計到開發的協作流程，可參考 Figma Dev Mode Guide。
Dev Mode 和一般 Design Mode 差在哪
| 模式 | 主要使用者 | 重點工作 | 常見操作 |
|---|---|---|---|
| Design Mode | 設計師 | 編輯設計稿、調整圖層、建立元件 | 畫面設計、Auto Layout、Prototype、Variants |
| Dev Mode | 工程師與交付者 | 讀取規格、確認狀態、取得資產與程式碼參考 | Inspect、Measure、Code、Export、Ready for development |
誰會用 Dev Mode：設計師、工程師、PM 的分工
設計師負責把 Frame、元件、狀態與註解整理到工程師看得懂；工程師負責讀取規格、確認資產、回報缺漏；PM 或產品負責人則用 Dev Mode 檢查哪些畫面已經可開發。我的判斷是，Dev Mode 最有價值的地方不在「少開一個畫面」，而是讓每個角色對交付狀態有同一套語言。
Dev Mode 適合解決的交付痛點
- 工程師不用反覆截圖問尺寸、間距、顏色與字體。
- 設計師可以標記 Ready for development，避免工程師拿到未定稿畫面。
- Annotations 可以補足圖層名稱看不出來的設計意圖。
- Dev resources 可以把 Jira、Linear、Storybook、GitHub 或規格文件放在同一個交付脈絡。
如何開啟 Figma Dev Mode：切換方式與介面導覽
開啟 Figma Dev Mode 的方式很直接：在 Figma Design 檔案中點擊 Dev Mode 切換鈕，或使用快捷鍵 Shift + D。
方法一：從工具列切換 Dev Mode
- 打開一個 Figma Design 檔案。
- 在上方工具列找到 Dev Mode 切換鈕。
- 切換後，畫面會進入以檢視規格為主的介面。
如果你是工程師，第一次進入檔案時先不要急著看圖層細節，先確認設計師有沒有標記 Ready for development。這一步可以避免你把草稿當正式規格。
方法二：使用快捷鍵 Shift + D
在 Figma 檔案中按 Shift + D，可以在 Design Mode 與 Dev Mode 之間切換。這個快捷鍵很適合需要一邊看設計、一邊確認規格的設計師或前端工程師。
Dev Mode 介面會多出哪些面板與狀態
Dev Mode 的介面會把「編輯設計」的權重降低，把「讀規格、找狀態、拿資產」放到前面。工程師常用的是左側導覽與右側 Inspect 面板。
左側 Pages / Layers
左側可以瀏覽 Pages、Layers，以及已標記 Ready for development 的 Frame 或 Section。大型專案裡，這比從整份設計稿裡慢慢找頁面可靠很多。
右側 Inspect / Code / Export
右側 Inspect 會顯示選取物件的尺寸、位置、樣式、字體、顏色、Code 與 Export 設定。前端工程師通常會在這裡確認 spacing、padding、margin 與資產格式。
Comments、Search、Ready for development
Comments 用來處理討論，Search 用來找元件或圖層，Ready for development 則是設計交付狀態。團隊真正導入 Dev Mode 時，這三個功能要一起用，單看 Inspect 反而容易漏掉設計狀態。
工程師在 Dev Mode 裡可以取得哪些規格
工程師可以在 Dev Mode 裡取得尺寸、間距、顏色、字體、CSS、iOS、Android 程式碼參考，以及 SVG、PNG 等資產匯出資訊。
| 規格類型 | Dev Mode 可提供的資訊 | 工程使用方式 |
|---|---|---|
| 尺寸與間距 | 寬高、座標、padding、margin、物件距離 | 轉成 CSS spacing、layout token 或元件屬性 |
| Typography | 字型、字重、字級、行高、字距 | 對應專案 typography scale |
| Colors | 色碼、透明度、樣式或變數線索 | 對應色票、CSS variables 或 design tokens |
| Code | CSS、iOS、Android 參考片段 | 作為規格參考，不直接當正式實作 |
| Assets | SVG、PNG、PDF、倍率與匯出設定 | 匯出 icon、圖片、插圖或 App 圖檔 |
尺寸與間距：Measure 如何看距離與對齊
選取圖層後，Dev Mode 可以顯示物件寬高與相對距離。前端工程師看 spacing 時，最好同時確認 Frame 是否使用 Auto Layout，否則設計稿上的距離可能只是手動擺放結果。若團隊還在熟悉排版規則，可延伸閱讀 Figma Auto Layout 教學。
Typography：字型、字重、行高、字距
文字圖層會顯示 font family、font weight、font size、line height 與 letter spacing。台灣團隊常見問題是設計稿用了本機字型，但工程端沒有相同字型檔，交付前要先確認字型授權與替代字型。
Colors：色票、透明度、變數與 token 線索
Dev Mode 可以顯示色碼、透明度，也可能顯示變數或樣式來源。成熟團隊不應只複製 hex code，而要追到該顏色在設計系統裡的角色，例如 primary、surface、border、text-muted。若已導入 token，可參考 Figma design tokens 指南。
Code：CSS、iOS、Android code 能怎麼用
Dev Mode 的 Code 區塊會依選取物件產生 CSS、iOS 或 Android 參考。它適合拿來確認樣式值、box model 與文字資訊，但不會理解你專案裡的 component API、狀態管理與 RWD 架構。
Assets：圖片、icon、SVG、PNG 如何匯出
如果設計師有設定 Export，工程師可以在 Dev Mode 匯出對應資產。icon 通常建議用 SVG，點陣圖片依使用情境選 PNG 或 WebP。App 專案還要確認倍率與平台命名規範，不能只看 Figma 裡有沒有匯出按鈕。
Content：文案內容與文字圖層檢查
工程師也可以從文字圖層複製文案。這對多語系、錯字修正、空狀態與錯誤訊息很有幫助。我的經驗是，很多交付問題不是 UI 畫錯，而是文案版本沒有同步；Dev Mode 至少能讓工程端看到目前設計稿上的實際文字。
設計師如何用 Dev Mode 交付設計稿
設計師用 Dev Mode 交付設計稿時，應先整理命名與狀態，再標記 Ready for development，補 annotations、Dev resources 與元件狀態。
| 交付步驟 | 設計師要做什麼 | 工程師會得到什麼 |
|---|---|---|
| 整理命名 | Frame、Section、Component 命名清楚 | 快速找到正確畫面 |
| 標記狀態 | 把可開發範圍標成 Ready for development | 知道哪些畫面可以開始做 |
| 補註解 | 用 annotations 補互動、邏輯與例外狀態 | 減少猜測與私訊確認 |
| 補資源 | 加入 Jira、Linear、文件、Storybook 或 GitHub | 規格、任務與程式脈絡連在一起 |
| 檢查元件 | 確認 variants、properties、狀態完整 | 避免做出一次性 UI |
Step 1：整理頁面、Frame 與圖層命名
交付前先整理 Page、Section、Frame 與主要元件名稱。命名可以使用產品語境，例如 Checkout / Payment failed / Empty cart，而不是 Screen 12、Frame 483。命名越接近產品功能，工程師越容易對應路由、元件與任務。
Step 2：標記 Ready for development
Ready for development 是交付狀態，不是漂亮標籤。只有完成設計確認、文案確認、狀態確認與資產確認的畫面才應標記。設計師如果把半成品也標起來，Dev Mode 的信任感會很快消失。
Step 3：用 annotations 補足設計意圖
Annotations 適合補充無法從圖層直接看出的資訊，例如輸入錯誤後的提示邏輯、按鈕 disabled 條件、列表空狀態、資料載入中狀態。這些內容不要藏在會議紀錄裡，放在設計稿旁邊最容易被工程師看到。
Step 4：補上 Dev resources、文件或 Jira/Linear 連結
Dev resources 可以把外部任務與規格帶進 Dev Mode。常見連結包含 Jira ticket、Linear issue、產品規格文件、Storybook、GitHub PR 或 API 文件。這裡的重點不是連結很多，而是工程師不用在 Slack、Notion、Figma、任務系統之間來回找。
Step 5：交付前確認 component、variants、狀態是否完整
如果一個按鈕有 default、hover、pressed、disabled、loading 狀態，設計稿就不該只交 default。component、variants 與 properties 要能反映真實產品狀態。若團隊正在整理元件規則，可延伸看 Figma component variants 教學。
Dev Mode 的 Code 可以直接拿來用嗎？
Dev Mode 的 Code 可以當規格參考，但通常不能直接貼進正式專案上線，因為它不理解你的前端架構、互動邏輯與 RWD 規則。
| Code 內容 | 可直接參考程度 | 工程判斷 |
|---|---|---|
| 顏色、字級、行高 | 高 | 對照 design token 或 CSS variable 後使用 |
| padding、margin、尺寸 | 中高 | 需確認是否符合 RWD 與元件 spacing 規則 |
| layout code | 中低 | 依專案 Grid、Flex、Container 規範重寫 |
| 互動狀態 | 低 | 需由工程依產品邏輯實作 |
| 元件邏輯 | 低 | 需回到 React、Vue、SwiftUI 或 Android 架構處理 |
可以直接參考的部分：尺寸、色彩、字體、spacing
顏色、字型、字重、行高、間距這些規格很適合從 Dev Mode 讀取，再轉成專案內的 class、token 或樣式設定。對前端來說，Dev Mode 最穩的是「值的來源」，不是「程式碼的架構」。
不能直接照貼的部分：layout、互動、RWD、元件邏輯
Figma 畫面是一個靜態設計狀態，正式產品會遇到不同螢幕寬度、資料長短、權限狀態、錯誤處理與載入時間。這些不是 Dev Mode code 能完整判斷的內容。把 code 照貼上線，常會在資料一變長或螢幕一變窄時破版。
前端工程師應該怎麼把 Dev Mode 規格轉成實作
- 先確認 Frame 是否已 Ready for development。
- 讀取主要 layout、spacing、typography、color 與 assets。
- 把樣式值對應到現有元件、class、token 或 theme。
- 檢查互動狀態、錯誤狀態、空狀態與 RWD。
- 遇到缺漏規格時，直接在 Figma 留 comment，不要只在私訊裡問。
Dev Mode 與設計系統：如何讓 component 真正接上前端
Dev Mode 在有設計系統的團隊裡價值更高，因為它可以把 component、variants、design tokens 與前端元件關係放進同一個交付流程。
為什麼 Dev Mode 不只是看規格
只把 Dev Mode 當 Inspect 使用，會低估它在團隊流程裡的價值。當設計師使用穩定元件，工程師在 Dev Mode 看到 component、variants、token 與相關文件，交付就不只是讀 px，而是確認「這個 UI 應該使用哪一個前端元件」。
component、variants、properties 如何降低交付誤差
component 負責定義 UI 的基本形狀，variants 負責處理狀態差異，properties 則讓元件更容易調整內容或行為。設計稿如果每次都手動畫相似按鈕，工程師就很難判斷要復用哪個前端元件。這也是我會建議團隊先整理常用元件，再談 Dev Mode 導入成效的原因。
design tokens 與前端變數應如何對齊
設計端的 color、spacing、radius、typography 如果能對應到前端變數，工程師就不用猜 #2563EB 到底是 primary-600 還是臨時色。token 對齊後，Dev Mode 的 Inspect 資訊會更接近正式開發語言。相關基礎可參考 設計系統指南 與 component library 建置。
Code Connect 適合什麼規模的團隊
Code Connect 適合已有設計系統、前端元件庫與跨團隊開發需求的組織。依 Figma 官方說明，Code Connect 可把程式碼庫中的元件連到 Figma Dev Mode，讓工程師看到更接近實際專案的元件片段；目前官方文件標示它適用於 Organization 與 Enterprise 方案，並需要 Full 或 Dev seat。小團隊若還沒有穩定元件庫，先把 component、variants 與 token 整理好，通常比急著導入 Code Connect 更實際。
Figma Dev Mode 權限、席次與費用怎麼判斷
Figma Dev Mode 的權限與費用要看方案與 seat 類型；截至 2026 年 5 月 11 日，官方標示 Dev Mode 包含在付費方案的 Full seat 與 Dev seat。
| 角色 | 常見需求 | 可能需要的 seat | 判斷方式 |
|---|---|---|---|
| 產品設計師 | 編輯設計稿、整理元件、標記交付狀態 | Full seat | 需要設計與編輯能力 |
| 前端或 App 工程師 | Inspect、Code、Export、Dev resources | Dev seat | 不需要改設計，但需要完整 Dev Mode |
| PM 或主管 | 查看進度、留言、確認交付範圍 | 依需求判斷 | 只看與留言可能不需要 Dev seat |
| 外部合作工程師 | 短期看規格與匯出資產 | 依檔案與方案判斷 | 先確認存取權與合約週期 |
誰需要 Dev Mode 席次
需要長期讀規格、看 Code、匯出資產、比對變更、使用開發整合的工程師，通常是 Dev seat 的主要對象。設計師若本來就需要完整編輯能力，通常會使用 Full seat。實際價格與功能請以 Figma 官方 pricing 頁 為準。
工程師需要編輯權限才能看 Dev Mode 嗎
工程師不一定需要設計編輯權限。Dev seat 的概念就是讓工程師取得開發需要的 Dev Mode 能力，而不用給他們完整設計編輯權限。這對團隊管理很重要，因為工程師應該能讀規格，但不必因此能改壞設計稿。
Dev Mode link 是什麼，什麼時候要分享
Dev Mode link 是讓接收者直接進入 Dev Mode 脈絡的連結。當設計師交付特定 Frame、Section 或流程時，分享 Dev Mode link 比丟整份檔案更清楚。工程師打開後會更快進到可開發範圍，不必自己從 Pages 裡找。
費用細節應以 Figma 官方最新方案為準
Figma 的方案、seat 名稱與價格可能調整，不建議在團隊文件裡寫死。比較穩妥的做法是文件寫「需要 Full 或 Dev seat」，價格欄位連到官方 pricing。若站內有價格整理，可把延伸閱讀放到 Figma pricing 方案整理，不要在這篇把價格頁完整重寫。
Figma Dev Mode 值得付費嗎？適合與不適合的團隊
Figma Dev Mode 是否值得付費，取決於交付頻率、工程師人數、設計系統成熟度與反覆溝通成本；小型低頻專案不一定需要。
| 團隊情境 | 導入價值 | 付費優先度 | 判斷理由 |
|---|---|---|---|
| 多人產品團隊 | 高 | 高 | 交付頻繁，少問一次規格就能省大量時間 |
| 有設計系統的團隊 | 高 | 高 | component、tokens、Code Connect 能放大效益 |
| 接案型小團隊 | 中 | 中 | 看案量與合作工程師數量 |
| 一次性形象網站 | 低到中 | 低 | 交付次數少，可能用基本檢視與文件即可 |
| 沒有元件規範的團隊 | 不穩定 | 先觀望 | Dev Mode 會暴露規格混亂，不會自動整理規範 |
適合導入的團隊：多人協作、設計系統、頻繁交付
如果你的團隊每週都有設計稿交付，工程師經常問規格、設計師經常補截圖，Dev Mode 很可能值得。尤其是設計師、前端、App、QA、PM 都會碰同一份設計稿時，統一交付入口會直接降低溝通成本。
不一定值得的團隊：小型專案、低頻交付、沒有元件規範
如果只是偶爾做一個 Landing Page，工程師和設計師又坐得很近，Dev Mode 的付費價值可能不明顯。我的建議是，小團隊不要因為工具看起來專業就急著買，先看最近三個專案有多少時間花在問規格、找資產、確認版本。
用時間成本評估 Dev Mode 是否划算
可以用一個務實算法：每位工程師每週因設計交付問題花多少時間，再乘上參與人數與月數。只要這些時間高於 seat 成本，導入就有討論空間。相反地，如果問題來自需求常變或設計系統不存在，Dev Mode 只能改善交付，不會替團隊補上產品決策。
可引用 HP 案例作為大型團隊效益參考
Figma 的 HP 客戶案例提到，HP 使用 Dev Mode 與 Code Connect 後，受訪團隊回報平均每人每週節省 98 分鐘，並把 Dev Mode 用在大型設計系統 Veneer 的交付流程。這是大型組織的參考，不代表所有團隊都會得到相同數字；它比較能說明 Dev Mode 的效益來自減少切換工具、降低反覆確認與提高元件對應清楚度。
建議的新手練習流程：用官方 Playground 熟悉 Dev Mode
新手可以先用 Figma 官方 Dev Mode Playground 練習 Inspect、Measure、Annotations、Comments 與 Export，不必等真實專案才開始熟悉。
先練 Inspect 與 Measure
先選取不同 Frame、文字、按鈕與 icon，看右側 Inspect 顯示哪些規格。接著練習量測物件距離，分辨 padding、margin 與元件內部 spacing。這一步要練到你能快速回答「這個按鈕寬高多少、文字樣式是什麼、上下間距多少」。
再練 annotations 與 comments
Annotations 用來寫規格與設計意圖，comments 用來討論問題。新手常把兩者混用，結果工程師找不到正式規格。練習時可以把互動條件寫成 annotations，把疑問或待確認事項留在 comments。
最後練 export assets
最後練習匯出 icon、圖片與 SVG。檢查設計師是否有設定 Export，確認倍率與格式是否符合 Web、iOS 或 Android 需求。資產匯出看似小事，但實務上常是工程師卡住的第一個地方。
Dev Mode 交付檢查表：設計師與工程師各自要確認什麼
Dev Mode 交付檢查表應分成設計師交付前與工程師開發前兩側，分別確認狀態、規格、元件、資產與缺漏回報。
設計師交付前 checklist
- Frame、Section、Page 命名是否能讓工程師找到正確流程。
- 可開發範圍是否已標記 Ready for development。
- 主要互動、錯誤、空狀態、載入狀態是否有 annotations。
- component、variants、properties 是否使用正確元件。
- icon、圖片與插圖是否設定 Export。
- Dev resources 是否補上任務、規格文件或程式相關連結。
- 文案是否為最新版本，避免工程師拿到舊文字。
工程師開發前 checklist
- 確認自己看的 Frame 是 Ready for development，而不是草稿。
- 檢查尺寸、間距、字體、顏色是否能對應到現有 token 或樣式。
- 確認 assets 是否能匯出，格式是否符合平台需求。
- 確認互動狀態、錯誤狀態、空狀態與 RWD 是否足夠。
- 判斷 Dev Mode code 哪些可參考、哪些要依專案架構重寫。
- 缺規格時在 Figma comment 回報，保留討論脈絡。
- 若有元件庫，確認設計稿對應哪個前端 component。
常見交付失敗原因
最常見的失敗不是工具不會用，而是設計狀態不清楚、元件規則不一致、資產沒有設定、文案版本不同步，或工程師拿到的只是截圖。Dev Mode 可以讓問題更早被看見，但團隊仍要建立交付規則。這也是成熟團隊會把 Dev Mode、設計系統、任務管理與前端元件庫一起看的原因。
Figma Dev Mode 是什麼？
Figma Dev Mode 是 Figma 裡給工程師與交付流程使用的開發者模式，可用來查看設計稿尺寸、間距、顏色、字體、程式碼參考、資產匯出與 Ready for development 狀態。
Figma Dev Mode 怎麼開啟？
打開 Figma Design 檔案後，可以點擊工具列上的 Dev Mode 切換鈕，或直接按 Shift + D 在 Design Mode 與 Dev Mode 之間切換。
Dev Mode 跟以前的 Inspect 差在哪？
Inspect 主要是查看單一圖層規格；Dev Mode 則把 Inspect、Code、Export、Ready for development、annotations、Dev resources、版本變更與開發整合放在同一個交付介面。
Figma Dev Mode 免費嗎？
截至 2026 年 5 月 11 日，Figma 官方標示 Dev Mode 可在付費方案中透過 Full seat 或 Dev seat 使用。實際方案與價格可能調整，應以 Figma 官方 pricing 頁為準。
工程師需要 Figma 編輯權限才能使用 Dev Mode 嗎？
不一定。工程師通常需要讀取規格與使用 Dev Mode 功能，不一定需要完整設計編輯權限。團隊可以依方案與 seat 類型分配 Full seat 或 Dev seat。
Dev Mode link 是什麼？
Dev Mode link 是指向 Dev Mode 脈絡的分享連結。設計師交付特定畫面或流程時，可用 Dev Mode link 讓工程師直接進入要開發的 Frame 或 Section。
Dev Mode 產出的 CSS code 可以直接用嗎？
通常只能當參考。Dev Mode CSS 適合確認顏色、字體、間距與尺寸，但正式專案仍要依照前端架構、RWD、元件邏輯與設計系統規則重寫。
設計師一定要標記 Ready for development 嗎？
如果團隊使用 Dev Mode 交付，建議一定要標記。Ready for development 可以讓工程師知道哪些畫面已確認可開發，降低拿到草稿或舊版本的風險。
Annotations 跟 comments 差在哪？
Annotations 適合寫正式規格、互動條件與設計意圖；comments 適合討論問題、請人確認或提出修改意見。交付時不要把正式規格只放在 comments 裡。
Dev Mode 適合小團隊嗎？
小團隊可以使用 Dev Mode，但不一定都值得付費導入。若交付頻率低、工程師人數少、設計師能直接溝通，效益可能有限；若反覆問規格很耗時，就值得評估。
Dev Mode 和設計系統、design tokens 有什麼關係？
Dev Mode 可以顯示 component、variants、variables 或 token 線索，幫助工程師把設計稿規格對應到前端元件與樣式變數。設計系統越成熟，Dev Mode 的交付價值通常越高。
新手可以去哪裡練習 Figma Dev Mode？
新手可以使用 Figma 官方 Dev Mode Playground 或範例檔練習。建議先練 Inspect 與 Measure，再練 annotations、comments，最後練習匯出 assets。