Design Handoff

設計交付具體指的是什麼，跟「把 Figma 連結傳給工程師」是同一件事嗎？

設計交付常被簡化理解成「把設計檔案的連結傳過去」，但實際範圍遠不只如此。完整的設計交付要傳遞的不只是視覺畫面，還包含元件規格（間距、顏色、字級）、互動行為說明、狀態文件（正常、載入中、錯誤、空白）、以及不同螢幕尺寸下的版型變化。只丟一個連結，工程師拿到的往往只有「畫面長什麼樣」，卻要自己猜「這個功能在資料是空的時候要顯示什麼」「這個按鈕按下去之後發生什麼事」。

多數交付流程只交出了視覺畫面，卻漏掉了其餘部分——這正是實作結果經常跟設計稿逐漸走樣、修改循環一再拉長專案時程的常見原因之一。

設計交付這個環節為什麼需要被特別重視，它解決了什麼問題？

設計和開發是兩種不同的思考模式：設計師常常是為「理想情境」設計——資料齊全、內容剛好、使用者照著預期路徑操作；工程師則必須為「真實情境」寫程式——資料可能是空的、內容可能太長被截斷、使用者可能亂點、網路可能斷線。這個落差如果沒有在交付階段被明確處理，工程師只能自己猜測或直接跳過，結果就是上線後出現大量設計稿裡沒畫過的「意外畫面」。

有研究指出，糟糕的使用者體驗每年在全球造成約 1.4 兆美元的生產力損失，而不完整的交付流程正是產品團隊裡最常見的浪費來源之一。設計交付要解決的核心問題，就是把設計師腦中「這裡應該要這樣」的隱性判斷，變成工程師看得到、查得到的明確規格，減少雙方來回猜測的溝通成本。

設計交付實務上要包含哪些具體內容，怎麼準備才算完整？

一份完整的設計交付通常需要涵蓋：

1. 元件規格：顏色、間距、字級等，如果設計工具有內建的檢視模式（例如 Figma 的 Dev Mode），這部分通常能自動帶出，前提是設計檔案本身建置正確、有套用統一的設計代幣
2. 邊界情況畫面：資料為空、內容過長被截斷、發生錯誤、沒有網路連線時，畫面各自該長什麼樣——工程師是為真實資料寫程式，設計師卻常常只為理想資料設計，這個落差必須明確補上
3. 響應式版型：同一個畫面在桌面、平板、手機不同尺寸下的版型差異，尤其是版面差異明顯的螢幕
4. 就緒標記：哪些畫面已經定案可以開始實作，哪些還在探索階段——檔案裡如果混雜大量未定案的草稿版本，會讓工程師難以判斷該做哪個版本，反而浪費時間

實務上常見的疏漏是只做了第一項（元件規格），卻跳過第二、三項，導致上線後出現大量設計稿沒處理過的畫面。

如果你用 Claude Design 或類似工具產出設計稿，這對交付流程有什麼實際影響？

AI 生成的設計稿通常擅長產出「理想情境」的畫面——內容剛好、資料完整、版面漂亮，這正好是傳統交付流程裡最容易被忽略的那一塊（邊界情況、真實資料）的反面。如果你打算把 AI 生成的稿子直接交給工程師實作，額外花時間補上「資料為空時長什麼樣」「內容超長時怎麼處理」這幾張畫面，往往比補其他任何東西都更能減少後續來回修改。

如果生成工具本身有 handoff bundle 這類打包交付機制，能省下的通常只是規格傳遞的手續（顏色、間距這些數值不用重新謄寫），但邊界情況與真實資料下的行為，仍然是工具產出時預設不會涵蓋的部分，這一步沒有辦法完全交給生成流程自動補完，需要人工額外確認。