Design Handoff 完全指南：設計師與工程師高效協作的 7 個實踐

Design Handoff 的痛點

做了三年 UI 設計之後，我最怕聽到工程師說：「這個跟設計稿不一樣耶。」字型差一號、間距多了 4px、顏色用到舊版色票、hover 效果完全沒做——這些問題幾乎每個專案都會出現。更痛苦的是，當你花了兩天仔細標註的設計稿，工程師只看了五分鐘就開始刻，結果上線後你打開瀏覽器，心裡只有一個想法：「這不是我設計的東西。」

Design Handoff 之所以是 UI/UX 設計流程中最容易出錯的環節，不是因為工程師不認真，也不是設計師不用心，而是雙方用不同的語言在描述同一件事。設計師看到的是視覺，工程師看到的是邏輯。這中間的落差，就是 Handoff 流程要解決的核心問題。

從交接到協作：Design Handoff 的思維轉變

傳統的 Handoff 像是接力賽——設計師跑完自己那棒，把檔案丟給工程師，然後就不管了。但實際上，好的 Handoff 應該像雙人舞，從頭到尾都在配合。

我在團隊裡推動的最大改變，就是把 Handoff 從「一次性交付」變成「持續協作」。設計不是在 Figma 按下 Share 的那一刻結束的，而是在產品上線、使用者實際操作的那一刻才算完成。這個觀念轉變，讓我們團隊的來回修改次數從平均 7 次降到 2 次以內。

實踐一：從設計初期讓工程師參與

很多設計師會等到高保真稿完成後才找工程師 review，但這時候要改架構已經太遲了。我的做法是在 wireframe 階段就邀請前端工程師參加設計評審。

工程師在早期參與有幾個好處：第一，他們能提前告訴你哪些互動效果實作成本很高；第二，他們會指出你沒考慮到的邊界情況，例如文字超出容器怎麼辦、列表為空要顯示什麼；第三，當工程師從頭就理解設計意圖，後續實作的還原度會高很多。

每週安排一次 30 分鐘的設計同步會議就夠了，不需要額外佔用太多時間。

實踐二：建立共用設計系統

如果你的團隊還沒有設計系統，Handoff 的效率永遠不會好。設計系統不只是一堆 UI 元件，它是設計師和工程師之間的共同語言。

一套基本的設計系統至少要包含：色彩系統（Primary、Secondary、Neutral、Semantic 色票）、字型規範（字級、行高、字重的組合）、間距系統（4px 或 8px grid）、以及常用元件（Button、Input、Card、Modal 等）。更多細節可以參考我們的 Design Token 與元件系統指南。

重點是設計系統要跟程式碼保持同步。Figma 裡的 Primary/500 必須對應到 CSS 的 --color-primary-500，這樣溝通時講同一個名字，就不會出錯。

實踐三：善用 Figma Dev Mode

Figma 的 Dev Mode 是目前最強大的 Handoff 工具之一。它讓工程師可以直接在設計稿上查看 CSS 屬性、測量間距、複製色碼，不需要設計師額外標註。

我特別推薦幾個 Dev Mode 的使用技巧：用 Section 把頁面切成開發任務單位、在 Component 上加 description 說明用法、善用 Ready for dev 標記來告訴工程師哪些畫面可以開始實作了。如果你還沒用過，可以先看 Figma Dev Mode 設計交付教學 快速上手。

Dev Mode 搭配 VS Code 的 Figma 外掛，工程師甚至可以在寫 code 的時候即時檢查設計稿，大幅減少切換視窗的時間。

實踐四：撰寫設計規格文件

光有視覺稿是不夠的。互動效果、動畫時間、邊界情況這些東西，靜態的 Figma 畫面表達不出來。我會針對每個重要功能寫一份簡短的設計規格文件，包含以下內容：

• 互動行為：點擊後發生什麼、滑動方向、手勢操作
• 動畫參數：duration（建議 200-300ms）、easing function（ease-in-out）、delay
• 邊界情況：空狀態、錯誤狀態、載入中、文字過長截斷規則
• 響應式行為：不同斷點下的版面變化

這份文件不用很長，每個功能大約半頁到一頁就夠了。重點是把設計稿上看不到的資訊補齊。

實踐五：定義元件互動狀態

一個按鈕有多少種狀態？至少六種：Default、Hover、Active（按下）、Focus（鍵盤聚焦）、Disabled、Loading。很多設計師只畫了 Default 和 Hover，工程師就得自己猜其他狀態長什麼樣。

我的建議是在 Figma 裡用 Component Variants 把所有狀態都建出來。這不只是方便 Handoff，也是在逼自己思考完整的使用者體驗。特別是 Focus 狀態，很多人會忽略，但它對鍵盤使用者和輔助科技使用者來說非常重要。

除了按鈕，Input、Select、Checkbox、Toggle 這些表單元件也都要完整定義每個狀態，包含驗證成功和驗證失敗的樣式。

實踐六：用 Design Token 統一語言

Design Token 是設計系統的最小單位，它把顏色、字級、間距、圓角這些值用有語意的名稱封裝起來。例如，不要跟工程師說「這個背景色是 #F5F5F5」，而是說「用 surface-secondary」。

Figma Variables 功能讓你可以直接在設計工具裡建立 Token，而且支援 Light/Dark mode 的切換。搭配 Token Studio 或 Figma 原生的 Variable export，你可以自動產出 JSON 格式的 Token 檔，工程師直接匯入就能用，完全不需要手動對照色碼。

Token 的命名建議採用三層結構：category-property-variant，例如 color-text-primary、spacing-padding-lg、radius-card-default。統一的命名規則讓設計師跟工程師講的是同一套語言。

實踐七：建立 QA 驗收流程

很多團隊把 QA 只當成抓 bug，但設計驗收（Visual QA）應該是獨立的環節。我會在工程師完成開發後，用以下流程做設計驗收：

1. 像素比對：用瀏覽器外掛把設計稿疊在實際頁面上，檢查間距和對齊
2. 互動檢查：每個按鈕、連結、表單都實際操作一遍
3. 響應式測試：至少在 375px（手機）、768px（平板）、1440px（桌面）三個寬度下檢查
4. 深色模式：如果有支援，切換到 Dark mode 確認
5. 無障礙檢查：Tab 鍵巡覽順序是否合理、對比度是否足夠

把問題統一記錄在一個 Notion 或 Linear 的清單裡，標記嚴重等級（P0 必修 / P1 建議修 / P2 下次再改），讓工程師有優先順序地修正。

AI 時代的新工具：讓 Handoff 更快更準

2025 年以後，AI 工具正在改變 Handoff 的方式。Figma AI 的 Auto Layout 建議和 Component 辨識功能，幫助設計師在設計階段就產出更規範的結構。

Design-to-code 工具（如 Locofy、Anima、Builder.io）可以把 Figma 設計直接轉換成 React 或 Vue 元件。雖然產出的程式碼品質還不完美，但已經能當作很好的起點，工程師在上面調整比從零開始快得多。

另一個值得關注的方向是 LLM 結合設計系統。你可以把設計系統的 Token 和元件文件餵給 AI，讓它幫你檢查設計稿是否符合規範、自動產生設計規格文件、甚至直接生成符合設計系統的程式碼。這不是取代設計師或工程師，而是讓雙方把時間花在更有價值的決策上。

Design Handoff 檢查清單

每次交付前，我會跑一遍這個清單確認：

• 所有頁面都有完整的互動狀態嗎？
• 響應式斷點的版面都設計好了嗎？
• Design Token 有跟程式碼同步嗎？
• 設計規格文件寫了嗎（互動、動畫、邊界情況）？
• Figma 的 Section 有標記 Ready for dev 嗎？
• 有跟工程師做過一次 walkthrough 嗎？
• QA 驗收的標準有先對齊嗎？

常見問題

設計師需要學程式嗎？

不需要會寫程式，但需要懂基本概念。理解 CSS Box Model、Flexbox、Grid 的運作方式，會讓你設計出更容易實作的版面。知道什麼是 component state、什麼是 responsive breakpoint，溝通時就不會雞同鴨講。我建議至少花一個週末學一下 HTML 和 CSS 基礎，這個投資的 CP 值非常高。

小團隊也需要設計系統嗎？

絕對需要，只是規模不同。兩個人的團隊不需要像 Google Material Design 那麼完整，但至少要有統一的色票、字型規範和基本元件。一個簡單的 Figma Library 加上一頁的使用說明就夠了。重點不是完美，而是有一個大家都同意的標準。隨著團隊成長，設計系統也跟著長大就好。

如何說服工程師配合新的 Handoff 流程？

最有效的方法是用數據說話。記錄一下目前每個 sprint 花在來回修改 UI 的時間，再算算新流程能省多少。通常工程師會發現新流程其實是在幫他們減少不必要的返工，因為設計稿更完整了，他們不用一直猜或一直問。先從一個小專案試跑，有了成功經驗後再推廣到整個團隊。