設計交給工程是整個產品開發裡最常被討論、也最常被誤診的一種交接。常見診斷是「溝通不足,多開幾次會就好」。真正的問題在別處:設計稿描述的是一組狀態中最理想的那一個,而實作必須處理全部狀態。這個落差不是溝通問題,是產物完整性問題,開會補不起來。

三個具體的失效點

只畫理想螢幕。 設計師把有三筆資料、名字剛好兩個字、網路良好、權限完整的那一版打磨到像素完美,然後交出去。工程師必須處理的是:沒有資料、正在載入、載入失敗、資料一萬筆、名字二十個字、使用者沒有權限、離線、i18n 之後德文標籤長 1.8 倍、RTL 語言鏡像。這些狀態工程師終究要寫出來,只是現在由他當場發明——發明出來的設計會在 design review 時被打回,這就是返工。

Token drift。 設計檔裡的變數與程式碼裡的常數各自演化,之後悄悄分岔。UI 看起來「差了一點但說不出哪裡」,通常就是這個。它的危險在於沒有任何錯誤訊息,只有累積的視覺不一致。

用截圖傳遞規格。 一張圖沒有語意:間距是 12 還是 13、這個灰色是哪個 token、這個元件是設計系統裡的 Button 還是一次性的按鈕。接手者(不論是人還是 AI agent)只能猜。AI 讀截圖時猜錯的機率更高,而且它不會告訴你它在猜。

讓 design tokens 當單一事實來源

Design tokens 把設計決策(顏色、間距、字級、圓角、動畫時長)抽成具名的值,讓設計檔與程式碼引用同一個來源而不是各自抄一份數字。W3C Design Tokens Community Group 已經制定了 token 的標準交換格式,Figma 的 Variables 系統也支援這個格式,這讓 token 從「團隊約定」變成「可以進 CI 的資料」。

這一步的關鍵不是工具,是方向性:token 必須有一個上游來源,其他地方都是下游。可以是設計檔為上游、由 CI 產生程式碼常數;也可以是 repo 為上游、同步回設計檔。兩種都行,同時當上游就不行——那正是 token drift 的定義。

讓元件對映消除「這是什麼元件」的猜測

Figma 的 Code Connect 把 repo 裡的元件與設計檔裡的元件建立明確對映,並可透過 UI 或 CLI 維護。它解決的是設計交接裡一個看似瑣碎但影響巨大的資訊缺口:接手者知道「這裡有一顆按鈕」,但不知道「這是我們設計系統裡的哪一顆」。

在 AI 輔助實作的場景,這個對映的價值被放大。Figma 的 Dev Mode MCP server 讓 AI 工具透過 Model Context Protocol 直接讀取設計檔的結構化內容,而不是解讀一張截圖;當 Code Connect 的對映存在時,MCP 回傳的不只是「一個圓角矩形」,而是「你們 repo 裡的 <Button variant="primary">」。這把 design→dev 的交接從像素比對變成元件層級的契約,也就是把一次高損耗的交接換成一次低損耗的交接。

需要誠實標記的是:這些功能能減少多少返工,官方與第三方都沒有公開對照數據(見 客觀檢視:主張 vs 可佐證)。機制上的改善很清楚,效果量不清楚。

驗收標準必須寫進交接物

設計交接最常缺的不是圖,是怎樣算做對了。可驗收的設計交接至少要回答四件事:

響應行為——在哪幾個斷點各長什麼樣。實務上先定三個代表性寬度(例如 375 / 768 / 1440),並明說中間的行為是流動還是跳變。「自己看著辦」在此處等於未定義行為。

互動狀態——default、hover、focus、active、disabled、loading、error 全部要有。focus 狀態最常被漏,而它同時是無障礙需求。

無障礙需求——對比度、focus 可見性、鍵盤操作順序、螢幕閱讀器標籤。把目標標準寫明(例如 WCAG 2.2 AA)比逐條抄規範有效,因為標準本身就是清單。

邊界情境——下面這份清單可以直接當 checklist 貼進交接文件,完整版在 交接產物模板:空狀態、首次使用(還沒有任何資料)、載入中、載入失敗與重試、部分失敗、資料極少與資料極多(分頁/虛擬滾動的門檻在哪)、超長文字截斷規則、i18n 字串膨脹、RTL、權限不足、離線、時區與日期格式。

邊界的另一側:工程也要回交

好的 design→dev 交接是雙向的。工程實作完成後回交給設計的內容,跟設計交出來的一樣重要:哪些地方因為技術約束偏離了設計稿、哪些狀態設計沒定義而由工程決定了、實際的效能表現如何(動畫在低階裝置上掉不掉格)。這個回交如果不存在,設計系統會與實作慢慢分岔,而設計師會在下一次設計時繼續假設一個不存在的實作。

這正是 接收者回述 在這個場景的形式。

延伸