為什麼設計到開發交接常常出問題？
典型的情境：設計師做了一個漂亮的 Figma 設計稿，丟給開發者說「就照這個做」。
然後開發者問：這個字型是哪個？這個間距是多少？這個顏色的 hex 是什麼？這個 hover 狀態是什麼效果？這個排版在手機上是怎樣的？
如果沒有事先準備好這些資訊，開發者要花大量時間「猜測」設計意圖，結果往往和預期差很多，需要來回修改。
設計稿中應該提供的資訊
設計規範（Design Tokens）
好的交接設計稿應該包含：
顏色系統：每個顏色的 Hex 或 RGB 值，以及它的用途（主色、輔色、文字色等）
字型系統：使用的字型名稱、各層級的字體大小、行高、字重
間距規則：基本間距單位（例如基於 4px 的倍數系統）
邊框和陰影的具體數值
Figma 的 Variables 和 Styles 功能可以讓這些值在整個設計稿中保持一致，也方便開發者直接從面板中查閱。
互動狀態說明
這是最常被遺漏的部分：
按鈕的 hover、active、disabled 狀態
表單的 focus 狀態和錯誤狀態
導航欄在滾動後的行為（是否固定、是否改變樣式）
動畫或過渡效果的描述
如果沒有明確說明這些，開發者要猜，或者乾脆不做互動效果。
RWD 版本說明
至少提供手機版（375px）和桌機版（1280px）兩個版本的設計稿。
更好的做法：加上斷點說明（在什麼寬度時版面改變）和關鍵元素的自適應行為（例如「桌機三欄，手機改成一欄」）。
如果你是一人包辦設計和開發
即使你一個人做設計和開發，養成設計規範的習慣仍然有很大的好處：
以後換成 Tailwind CSS 或其他框架時，有明確的設計系統可以對應
修改設計時，知道修改一個地方不會影響其他地方
和客戶確認設計費時有清楚的資料可以參考
建議在每個專案開始時建立一個「設計規範」頁面，列出核心的顏色、字型和間距。
Figma 的實用交接功能
Figma 內建了一些幫助交接的功能：
Dev Mode：切換到開發者模式，可以直接查看每個元件的 CSS 屬性
Inspect Panel：點選任何元素，右側面板顯示精確的尺寸、間距、字型資訊
Export：可以一鍵將圖片資源匯出為各種格式（PNG、SVG、WebP）
Prototype：用Figma 的原型功能展示互動流程，讓開發者了解動線邏輯
讓交接更順暢的溝通習慣
技術之外，溝通習慣更重要：
定義「完成」：什麼狀態下設計稿是可以交接了？（是否所有頁面都完成？是否包含 RWD？）
問題集中處理：開發時遇到的問題，集中起來統一回答，而不是每遇到一個問題就中斷工作
命名規範：Figma 元件和程式碼元件用相同的命名，方便對照
變更記錄：如果設計在開發中途改變，要清楚標記什麼改了、在哪裡、改成什麼
好的設計到開發交接，是設計師工程素養和工程師設計理解相互配合的結果。無論你在哪一端，減少對方的猜測工作，就是提升整個協作品質最直接的方式。