以下內容由摹客團隊翻譯整理，僅供學習交流， 摹客iDoc是支持智能標註和切圖的產品協作設計神器。
從定義上來看，設計交付一般發生在完成的設計送達至開發人員實現它的階段。接下來就讓我們一起學習在交付過程中，設計人員與開發人員須知的協作基礎知識和相關建議吧！
我們在UX Studio項目中有長時間與開發人員協作的經驗，值得慶幸的是，我們每次都做得越來越好。事實上，我們現在已經擁有自己的開發人員，並且正在開發一個Dev Studio，以便為我們的客戶提供完整的服務。
在本文中，筆者將分享一些關於設計交付的重要結論。記住這些要點，對於設計師和開發人員，以及產品團隊負責人和其他經理都非常有益。
“設計交付”是什麼意思？
首先，我必須聲明，數字產品的“完成設計”狀態是並不存在的。因為我們總能在這個“完成設計”的基礎上做得更多。因此，在本文中“設計交付/移交”指的是設計師將自己的設計想法轉達給開發人員。
由於設計交付指的是一個階段的結束，因此大家很容易犯只關注上傳、導出和指定設計等典例做法的錯誤(我就經常犯這樣的錯誤)。其實除了這些，還有更多需要我們注意的地方。
使用同一種語言
設計師應該與開發人員使用同一種語言也很重要。無論規範多麼漂亮和整潔，如果設計師在設計交接之前沒有真正與開發人員進行交談，那麼開發人員也不能很好地理解設計。即使公司準備了成員隨時扮演信息傳遞者的角色，設計師也應該自己具備與開發人員溝通的能力。設計交接的準備工作應從整個設計過程的一開始就進行。設計人員與開發人員討論的檢查點應反覆出現，所有這些你們都可以使用同一種工具同一種語言，從而更容易進行檢查和溝通。
Intercom關於設計師 - 開發者合作的價值的文章的插圖
從屏幕設計到屏幕流程
從一定的角度來看，屏幕設計可以作為開發人員的參考點。但在過去糟糕的設計階段中，設計師難以為其產品團隊的不同成員導出PNG文件，為開發組織資源和PSD文件，並且和成員進行評論、討論和輸入版本控制信息等。
正在設計師為此煩惱之際，摹客iDoc應運而生，解決了設計師的痛點！ 摹客iDoc（以及類似的解決方案，如Zeplin）極大地改善設計師和開發人員的工作流程。它幫助設計師上傳設計，輸入用於版本控制的提交消息，評論和討論，或者使用此功能來指定詳細信息，它還包含了所有可導出的資源。還有比這更方便的工具嗎！？
如何使用摹客iDoc呢？ 首先，你必須擁有一個基礎的原型（可以是Axure,Justinmind 或Mockplus中的原型），但是開發人員通常會要求它以更加教學意味的視覺形式提供所有基本屏幕及其關係的靜態地圖。
設計交付不僅在整個項目中非常重要，還可以揭示設計中缺失的步驟和邊緣案例，迫使設計師重新思考流程中不合邏輯的步驟等。這簡直就是一項雙贏的工作！
手繪草圖的流程為我們的客戶風格
像上圖我們在Stylelike中所做的那樣，在草圖階段的早期就開始討論。討論的要點仍然是深思熟慮，使其具有描述性並開始討論!完善的版本將成為一個偉大的清單!
高保真屏幕流程完美地幫助開發解釋功能的工作原理
設計中面臨的挑戰
1. 邊緣情況和空狀態
我特意將這一點放在挑戰清單上，以確保它們也能列入你的清單。屏幕流中包括 邊緣情況和較少的空狀態設計，設計師需要提供具體存在情況。從項目開始就考慮屏幕流中是否存在空狀態，這樣在設計交付後就不會再面對意料之外的問題。邊緣情況包括設計最長德語版本的標籤，但這並不能涵蓋所有內容，可能會出現非典型用例。在電子表格中收集邊緣案例並提供一些書面規範，可以有助於簡化開發人員的工作。
2. 資源：圖標和圖片
在設計交付過程中，設計師需要手工設計所有圖片資源，然後將它們移交給開發人員，這讓設計師感到十分痛苦。iDoc和Zeplin 就很好地解決了這個問題，從Zeplin來看：設計師只需正確對圖層進行分組和切圖。對於開發人員來說， 除了Android以外，導出圖標從來不是易事。大多數設計師使用顏色蒙版圖標（這是迄今為止在Sketch中重新著色圖標最方便的方式），Android Studio無法導入這些圖標。複雜的網頁圖標設計也經常出現，同時將像素完美的設計交給開發人員即可。不過目前使用Zeplin中有個問題是，設計師從Zeplin導出到Illustrator的圖標：在某些情況下，會出現圖層混亂，文件變得更大，圖標設計變形的情況。
（Sketch似乎正忙於解決這些問題，但在此之前，可以試著簡化Illustrator中有問題的圖標，並單獨與開發人員共享即可。）
3. 動畫
我們可以將用戶界面的動畫看作設計頂部的櫻桃，但我們不應該低估設計過程中的這一階段。動畫和微交互不僅僅是對我們的產品進行個性化的最後潤色。如果做得好，它們還可以作為描述性的附加功能來改善用戶體驗。
由於常用的工具（比如流行的Principle）僅僅提供視覺效果，因此動畫切換存在一些輕微的問題。為了讓開發人員能夠理解動畫中發生的所有細微的，幾乎看不見的東西（比如自定義緩和曲線），我們需要：
l 一份寫得不錯的文檔說明和與前端人員的深入交談
l 一個優秀的前端人員，因為他能懂你精心設計的交互和每一個細節
自Airbnb推出開源 Lottie 動畫工具以來，我們已經朝著完美的設計交付邁出了好幾步。設計人員可以在AfterEffects中處理動畫，然後在導出JSON文件時，開發人員無需猜測所使用的任何字符串和時間。最重要的是，NI 還可以在交付之前對其進行測試。
在涉及動畫和交互的情況下，我們不得不提及 Framer。由於編碼的原因，設計人員需要做出具備挑戰性的學習曲線，這不僅會讓開發人員感激不盡，而且還提供了一個將複雜的原型流組合在一起的絕佳機會（使可用性測試和迭代更快）。
要查看示例，請查看我 在業餘愛好項目中的 第一個個人Framer 實驗 。
如何保證設計移交期間的一致性？
設計規範
一致性對於設計師而言非常重要，對嗎？確實如此。為開發人員構建樣式指南 並將其轉換為設計規範，這將使設計人員與開發人員協作方式更加輕鬆，並使產品也更加一致。
特定於平臺的指導方針
重申一遍：在這個主題中找到設計師和前端人員之間的共同點。另外，請查看特定於平臺的指南方針，並充分了解和理性地超越平臺準則:)。
命名規範
在許多方面和原則中，設計規範不僅能夠統一設計元素，而且還能對設計和編碼過程中所有階段的命名進行規範，以Zeplin為例。
資源命名規範：Zeplin啟用首選項設置，如果選中，下劃線將替換為大寫字母
設計與開發不能處於孤立狀態
在一個理想的狀態裡，一切都將按照設計師的意願而實行。在這個場景中，設計師交付了像素完美的設計，然後開發人員只是一言不發地把它放到代碼中，兩者沒有任何交流。看似流暢的交付過程，卻遺漏了設計師與開發人員合作中最有創意和樂趣的部分。設計過程彼此越孤立，你的設計投入生產的準確性就越低。上述建議可以拉近兩者的距離。
因此，具體建議如下：
l 設計師： 讓開發人員參與交互設計過程。
l 開發人員： 從已開始就參與其中。
l 產品經理： 全心全意鼓勵設計師與開發人員的合作。
末了，再次向大家提出強烈建議：不要在設計過程開始就簡單地通過提高設計交付技術來代替協作（以及通信）。利用設計師 - 開發人員團隊合作的優勢效果更佳！
如果你任何團隊應用的步驟或技巧，使設計交接過程更加流暢嗎？ 不妨在評論中與我們分享！
原文作者：Katica Babarczi
原文鏈接：https://uxstudioteam.com/ux-blog/design-handoff/
閱讀更多 Mockplus摹客 的文章
