Design Handoff 指南：設計師工程師協作最佳實踐

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）應該是獨立的環節。我會在工程師完成開發後，用以下流程做設計驗收：

像素比對：用瀏覽器外掛把設計稿疊在實際頁面上，檢查間距和對齊
互動檢查：每個按鈕、連結、表單都實際操作一遍
響應式測試：至少在 375px（手機）、768px（平板）、1440px（桌面）三個寬度下檢查
深色模式：如果有支援，切換到 Dark mode 確認
無障礙檢查：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 值非常高。