以下內容由摹客團隊翻譯整理，僅供學習交流，摹客idoc是支援智慧型標註和切圖的產品協作設計神器。
從定義上來看，設計交付一般發生在完成的設計送達至開發人員實現它的階段。接下來就讓我們一起學習在交付過程中，設計人員與開發人員須知的協作基礎知識和相關建議吧！
我們在ux studio專案中有長時間與開發人員協作的經驗，值得慶幸的是，我們每次都做得越來越好。事實上，我們現在已經擁有自己的開發人員，並且正在開發乙個dev studio，以便為我們的客戶提供完整的服務。
在本文中，筆者將分享一些關於設計交付的重要結論。記住這些要點，對於設計師和開發人員，以及產品團隊負責人和其他經理都非常有益。
「設計交付」是什麼意思？
使用同一種語言
設計師應該與開發人員使用同一種語言也很重要。無論規範多麼漂亮和整潔，如果設計師在設計交接之前沒有真正與開發人員進行交談，那麼開發人員也不能很好地理解設計。即使公司準備了成員隨時扮演資訊傳遞者的角色，設計師也應該自己具備與開發人員溝通的能力。設計交接的準備工作應從整個設計過程的一開始就進行。設計人員與開發人員討論的檢查點應反覆出現，所有這些你們都可以使用同一種工具同一種語言，從而更容易進行檢查和溝通。
從螢幕設計到螢幕流程
如何使用摹客idoc呢？ 首先，你必須擁有乙個基礎的原型（可以是axure,justinmind 或mockplus中的原型），但是開發人員通常會要求它以更加教學意味的視覺形式提供所有基本螢幕及其關係的靜態地圖。
設計交付不僅在整個專案中非常重要，還可以揭示設計中缺失的步驟和邊緣案例，迫使設計師重新思考流程中不合邏輯的步驟等。這簡直就是一項雙贏的工作！
摹客idoc，更快更簡單的產品協作設計神器
：手繪草圖的流程為我們的客戶風格。
像上圖我們在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產品經理： 全心全意鼓勵設計師與開發人員的合作。
學習工具，但不受限於某種工具。摹客idoc，高效協作，從產品到開發，只要乙個文件，讓你的團隊高效協作！
設計師完全自學指南
我不是畢業於設計學系，但我得到了乙份設計師的工作。我想換工作，成為一位設計師，但我沒有四年和十萬元美金讓我回到學校上課，所以我決定自修。起初，我相當懷疑乙個人到底能不能靠著自修來找到相關的工作。答案是 可以 一 學會觀察 新手最容易犯的錯誤是直接上手photoshop，要清楚學會photoshop並...
設計師如何跟開發打好關係？
本文講的是設計師如何跟開發打好關係？在製作原型時 在產品中 或者在 web 檢視中我應該如何載入 css？載入字型圖示的最佳方式是什麼？它們對效能有什麼影響？我應該在 發現檔案錯誤，又應該在 尋找其他人解決自身問題的辦法 問題追蹤，知識基礎 我該如何為設計系統做貢獻 修復 bug 增加乙個圖示 我是...
設計師如何培養良好的設計思維？
1戴著枷鎖跳舞 做ui設計是圍繞產品與使用者的一項工作，乙個產品設計的表現風格，用什麼顏色，什麼字型，怎樣布局受諸多因素影響，其中最重要的是行業特性與產品理念，使用者的心理與審美習慣，設計流行趨勢也是很重要的。有時候甚至是老闆與客戶的一廂情願就決定了產品的設計走向。在諸多影響因素的作用下，設計師的創...