這篇文章是我在 2024 web conf 上演講的內容，後來想想「設計很豐滿，開發很骨感」，這個題目可能會讓大家誤以為我要聊過度設計的事，但其實現在這種情況比以前好多了，所以還是以「設計交付」當作這次主要分享的內容。
在N年前的某天，那時我想做自己的產品，正在研究一些前端的技術，工程師看到卻跟我說：「設計師不應該花時間研究程式，設計師應該專注在創意上。工程的實現方式，應該讓工程師煩惱。」
是這樣嗎？到底設計師該不該學寫程式？其實這就像是建築設計師，該不該了解建築的工法、材質、結構的問題一樣，我想答案是肯定，不一定要親自施工，但至少要了解一些工程的基礎，才能蓋出好看又堅固的房子對吧？
不過，設計師和工程師本質上是兩種截然不同的職業，對產品的思考方式也常有所差異。在這樣的情況下，如何縮小這些認知落差，讓雙方更好地協作，是一個可以深入討論的問題。
我認為做好「設計交付」是重要的，一般情況下，設計師完成設計稿後，後續的開發工作似乎就不再與設計師相關。然而，設計交付到功能實現之間往往會有最短幾週最長幾個月的時間差，最終能否實現設計效果，通常被視為工程師的責任。這種流程上的斷層容易導致問題。
解決這個問題的關鍵，是在產品開發流程中建立清晰的交付模式。透過更緊密的協作與明確的交付機制，可以確保設計意圖更準確地落實到最終產品中。
什麼是設計交付
設計交付（Design Delivery），比較可愛的說法是 hands-off，它是設計與開發之間的重要橋樑。設計交付的重點不僅僅在於移交設計稿，而是影響產品品質的關鍵「流程」。
設計交付的本質在於設計師與開發者之間的溝通，減少誤解和重複工作。通過清晰的規範、版本控制，以及協作工具的輔助，設計交付可以幫助團隊更快地完成開發，提昇產品品質，同時也提昇開發體驗。
設計交付的目的
為什麼「設計交付」？主要有兩個目的，
- 維持產品一致性
- 提昇產品的開發體驗
在一致性方面，除了產品在跨平台的一致性很重要外，在設計交付上還有三種關係需要思考：設計師之間的設計一致性、設計師與工程師之間的協作一致性，以及工程師之間的實作一致性。而設計交付的核心，正是針對設計師與工程師之間的協作一致性，確保設計能夠落實開發。
另外，開發體驗是比較容易被忽略的，優秀的產品體驗建立在好開發體驗之上。設計交付的過程不僅影響產品的最終呈現，還直接決定了開發的效率與品質。高品質的設計交付需要設計師深入理解技術，並在實戰中不斷精進。然而，這一重要環節卻常常被忽略。
設計交付與開發流程
如果設計交付與開發流程有關，那我們就可以從開發的流程中去了解，怎麼做好設計的交付。下面就以開發前、中、後來說明，每一個階段應該注意什麼事項。
- 開發前：建立交付基礎
- 安排「技術可行性評估」會議，確定技術可行性。
- 確定技術的對接窗口。
- 確定工程師對於設計規範（Design Guideline）文件的期待。
- 設計資源（Asset）的交付方式與管理。
- 開發中：高效協作
- 安排「設計交付會議」，說明設計稿細節，確保開發團隊對設計的全面理解。
- 持續跟進與溝通，確保設計意圖落地。
- 提供互動細節指引，減少誤解。
- 開發後：驗收與迭代
- 安排驗收與測試，檢查產品是否完全符合設計稿，包括像素對齊、動效流暢性、跨裝置表現等。
- 收集回饋，作為未來優化和改進設計交付流程的參考。
- 完善文檔，確保後續版本的開發能夠更順暢。
設計交付的流程其實非常符合 PDCA 循環（Plan, Do, Check, Adjust）。通過不斷積累交付經驗，設計與開發的協作自然會變得更加順暢。
設計交付的工具
數位產品設計工具的演變速度非常快，從過去的 photoshop、illustrator 到 sketch app 及 zeplin ，再到現在主流的 figma，我想從事數位產品設計超過五年以上的人都會很有感觸世界變化之快，但至少在設計交付這件事上，也變的比較容易了。我個人總結了以下幾個工具，來協助做好設計交付：
- figma（做設計也寫文件）
- figma dev mode（figma的開發者功能）、zeplin（老牌的文件標識app）
- Token Studio（figma plugin，需額外付費）
- github（版本控制軟體）
- storybook（建立 web component 用）
- google sheet（檔案管理）
這些工具足以支援完整的設計交付，並且其中不少工具也能幫助建立「設計系統」。接下來，我們來談談「設計系統」。
建立設計系統
在台灣的工作環境中，是否需要建立「設計系統」，主要取決於產品的規模。由於大多數產品的規模有限，通常不需要設計系統進行全面整合，更不用提進一步的「設計營運（Design Ops）」。許多公司在完成第一版設計系統後，因維護成本高、設計師技能門檻高，以及人員異動等因素，後續經常停止更新。因此，採用現有穩定且持續更新的「開源框架」（例如 Material Design 或 Ant Design）成為更常見的選擇。
儘管如此，我們仍可以部分導入設計系統，用於檔案管理或撰寫設計規範（Design Guideline）。設計系統的建立主要分為兩部分：設計資源（Assets）的整理與設計文件（Documents）的撰寫。
設計資源是需要打包提供給工程師的內容，主要包括以下幾項：
設計資源（Assets）
- Design Token: 將常用的顏色、字體、間距、尺寸等參數進行變數化處理。Figma 提供內建的 Variable 功能，但若需轉換為 Token，則需要依賴第三方工具，如 Token Studio。
- Icons（圖標）: 圖標應根據平台需求分類格式，例如 font、SVG、PDF、PNG 等，並妥善管理於資料夾中。
- Images（圖片）: 圖片資源應分類存放，常見格式包括 PNG 和 SVG。
- Motions（動態資源）: 常用格式為 Lottie，因其被主流設備廣泛支援，建議依設備需求分類存放。
整理完成後，建議將所有資源打包至 Git 的 Repo 中，統一由設計師管理。這樣可以方便後續的更新與替換，避免資料夾中出現重複但命名不同的檔案。
設計文件（Documents）
- Brand Book（品牌手冊）: 提供全公司使用的品牌相關文件。
- Design Guideline（設計規範/指南）: 建議直接在 Figma 撰寫，說明元件格式與使用方式，方便查閱與管理。
- UI Kit : 將完成的元件整理成頁面，供設計師快速使用。
- Templates（模版）: 針對功能流程中的重複頁面（例如關鍵頁、狀態頁），製作模板以提升效率並方便後續使用。
設計文件的撰寫建議集中於 Figma 內，避免依賴第三方工具，這樣可以減少同步問題並降低額外成本。而至於設計規範的撰寫方式可以參考我的另外一篇文章。
如何提升設計交付的能力
作為設計師，除了產出設計稿，為了讓產品符合開發的預期，可以透過閱讀設計規範及學習前端的框架來提昇交付能力，下面列出一些常見的規範與前端 UI 框架。
- 設計規範（design guideline）
- 前端框架
設計的實現需要團隊的配合，尤其是與工程師的合作。主動與工程師討論需求、技術限制與實現方式，不僅能避免設計落地時的問題，也能讓你的設計更符合實際需求。
設計交付會被 AI 取代嗎？
不能否認，AI 技術的確可能取代許多工作。然而，回到設計的本質，我認為設計是一種過程，一種體驗與參與社會的過程。過去常聽到「設計是解決問題的方法」，但這種說法過於目標導向，如果設計僅被視為解決問題的方法，那麼 AI 確實是解決問題的最佳工具。
然而，若我們將設計視為參與社會的過程，AI 無法取代我們的社會參與，也無法替代人類感知世界。因此，作為解決問題的工具，AI 無疑非常出色，但它仍無法代替我們與社會的互動。
回到設計交付的話題，其本質在於溝通，而溝通本身就是一種社會參與。只要人類世界存在分工，我們就需要溝通。透過 AI，我們可以提升溝通的效率，例如生成文檔、整理資訊。如何善用這些工具，讓我們在參與的過程中發揮更大的價值，才是值得深思的方向。
我常常在思考：「當人類有了 google，就以為自己無所不知；當人類有了 AI，就覺得自己無所不能；如果沒有這些工具，那我們還剩下什麼？」沒有了 google map，我們還找的到回家的路嗎？這才是我們需要思考的問題。
huangruilin 