設計交付指南：設計師與開發如何才能好好協做？

如下內容由摹客團隊翻譯整理，僅供學習交流，摹客iDoc是支持智能標註和切圖的產品協做設計神器。

從定義上來看，設計交付通常發生在完成的設計送達至開發人員實現它的階段。接下來就讓咱們一塊兒學習在交付過程當中，設計人員與開發人員須知的協做基礎知識和相關建議吧！

咱們在UX Studio項目中有長時間與開發人員協做的經驗，值得慶幸的是，咱們每次都作得愈來愈好。事實上，咱們如今已經擁有本身的開發人員，而且正在開發一個Dev Studio，以便爲咱們的客戶提供完整的服務。

在本文中，筆者將分享一些關於設計交付的重要結論。記住這些要點，對於設計師和開發人員，以及產品團隊負責人和其餘經理都很是有益。

「設計交付」是什麼意思？

首先，我必須聲明，數字產品的「完成設計」狀態是並不存在的。由於咱們總能在這個「完成設計」的基礎上作得更多。所以，在本文中「設計交付/移交」指的是設計師將本身的設計想法轉達給開發人員。

因爲設計交付指的是一個階段的結束，所以你們很容易犯只關注上傳、導出和指定設計等典例作法的錯誤(我就常常犯這樣的錯誤)。其實除了這些，還有更多須要咱們注意的地方。

使用同一種語言

設計師應該與開發人員使用同一種語言也很重要。不管規範多麼漂亮和整潔，若是設計師在設計交接以前沒有真正與開發人員進行交談，那麼開發人員也不能很好地理解設計。即便公司準備了成員隨時扮演信息傳遞者的角色，設計師也應該本身具有與開發人員溝通的能力。設計交接的準備工做應從整個設計過程的一開始就進行。設計人員與開發人員討論的檢查點應反覆出現，全部這些大家均可以使用同一種工具同一種語言，從而更容易進行檢查和溝通。

圖片：Intercom關於設計師 - 開發者合做的價值的文章的插圖。

從屏幕設計到屏幕流程

從必定的角度來看，屏幕設計能夠做爲開發人員的參考點。但在過去糟糕的設計階段中，設計師難覺得其產品團隊的不一樣成員導出PNG文件，爲開發組織資源和PSD文件，而且和成員進行評論、討論和輸入版本控制信息等。

正在設計師爲此煩惱之際，摹客iDoc應運而生，解決了設計師的痛點！ 摹客iDoc（以及相似的解決方案，如Zeplin）極大地改善設計師和開發人員的工做流程。它幫助設計師上傳設計，輸入用於版本控制的提交消息，評論和討論，或者使用此功能來指定詳細信息，它還包含了全部可導出的資源。還有比這更方便的工具嗎！？

如何使用摹客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 產品經理： 全心全意鼓勵設計師與開發人員的合做。

末了，再次向你們提出強烈建議：不要在設計過程開始就簡單地經過提升設計交付技術來代替協做（以及通訊）。利用設計師 - 開發人員團隊合做的優點效果更佳！

若是你任何團隊應用的步驟或技巧，使設計交接過程更加流暢嗎？ 不妨在評論中與咱們分享！

原文做者：Katica Babarczi

原文連接：https://uxstudioteam.com/ux-blog/design-handoff/

學習工具，但不受限於某種工具。摹客iDoc，高效協做，從產品到開發，只要一個文檔，讓你的團隊高效協做！