起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識身為設計師，如何成功地交付設計成果？
本文是一個全面的設計交付指南，其中將為大家分享一些技巧，幫助設計師能夠順利完成團隊在執行階段的協作工作。
創造一個好產品是一個不斷打磨和實現想法的過程，但完成一個有序且經過深思熟慮的設計開發過程并不簡單。在執行階段的后期，需要解決一些可能導致不必要的升級和重復修改的問題。
作為設計師，我們是執行力的守護者，對成品中可能存在的瑕疵負有同等的責任。因此，對于設計師來說，在每次發布之前完成設計的構建是非常必要的。
但并不是所有的設計質量檢查都是在過程中進行的，大多數產品的發布都是在緊湊的時間安排下完成的。繞過設計質量檢查產生的問題是,擠在那些珍貴的幾小時前發布，這看起來像一個更簡單的“權衡“。
但比直接的質量損失更有害的是它將這個步驟遺留到即將發布的版本中，有時它幾乎會在產品的生命周期中徘徊。這樣做的后果不堪設想！
在強調了設計質量檢查的重要性之后，設計師應該明確自己也肩負著減輕質量檢查和清除bug的重擔。
在很大程度上，這個擔子的重量取決于設計師向涉眾發布的設計有多全面。設計師往往喜歡把自己看成是思考者，而不是執行者。通過觀察開發人員的操作方式來了解交付中的一兩件事情是可以的。
但保持版本控制的嚴謹性、文件/模塊的命名空間、記錄迭代或提交消息或補丁注釋等實質性的工作，會幫助設計人員在工作中獲得更多的生產力和有用的東西。
作了這么多鋪墊，接下來我將分享關于設計師如何通過一些技巧來順利完成團隊在執行階段的協作工作，即一個全面的設計交付指南。
當一個設計成果移交給開發人員時，它需要傳遞多層信息。除了原型、規格和資源之外，還必須共享交互、副本和檢查表。所有這些都涉及到設計解決方案的不同方面，并且需要在一個簡單的、可訪問的文檔中進行比較。我們可以將其稱為設計交付文檔。
設計交付文檔應該是一站式文件，它的目標在于表達產品從設計到開發完成的全過程。而一個完整的設計交付文檔應該包括以下5個方面：原型，交互設置，副本，規格和資源，檢查表。
一、原型
這個版塊不需多說，大家都很熟悉。從業多年，我們都能輕松地創建和分享UI原型。這里跟大家分享兩點訣竅，可以幫助設計師們更好地交付設計成果：
- 文件命名保持一致: 讓文件/屏幕名稱不具有任何版本控制形式，簡單地描述它的功能。需要注意的是：在給屏幕命名時，無論你是選擇使用“駝峰命名法”還是其他任意命名法，一定要使用一致的命名法。
- 有必要的話，把原型相關內容存檔。在交付成果的時候，對于要構建的選項?，總的來說是零。所以清除所有舊的迭代和設計探索，只保存最終原型相關內容，可以讓你在查找或記錄文件名時更方便。
2. 交互
- 創建流程圖: 將所有原型圖放在一起僅僅完成了一半的工作。你需要使用熱點 (或者制作一個交互式原型) 根據流程將界面串聯在一起，這個成果被成為流程圖。創建流程圖可以幫助產品經理理解用戶旅程是如何進行的；并幫助開發人員提前規劃其使用代碼的方法。
- 指出保真度: 并不是每個界面都必須用高保真原型來充實。根據不同的情況，有時候它們可以是帶有批注的靜態界面；也可以是迎合標準交互方式的界面；也有少數情況下需要與定制原型的保真度保持一致。所有的界面都沒有統一的保真度，因此與開發人員進行討論并規定相應頁面的保真度。不要花費大量的時間去為一個已經存在的簡單交互式原型填充高保真圖片。
無論是通過制作交互式原型還是在每個靜態屏幕上的添加批注來表達交互，都可以由你自己決定。它們的最終目的都是將交互記錄下來或表達出來。
人們傾向于把這個部分留到最后階段，這時你會聽到設計師說:“這個部分我會和開發人員討論一下”；但其實這并沒什么效果。
三、視覺設計稿交付
UI設計師完成設計稿后，少不了和上游的產品經理和下游的開發工程師進行對接。那么，如何才能做到無縫對接呢？在這里，向大家推薦一款快速簡單的產品協作設計平臺，摹客iDoc。支持Sketch、PS、XD的設計原稿和設計圖，智能標注、一鍵切圖、多樣批注、交互原型、全貌畫板、團隊管理，從產品到開發，只要一個文檔。
（1）智能標注：
- 間距標注；
- 尺寸智能標注；
- 百分比標注，兼容多屏幕分辨率；
- 多選標注，告別點擊；
- 放大鏡，查看微小間距。
（2）智能切圖：
- 自動切圖；
- 自動生成不同高倍率；
- 自由切換平臺；
- 一鍵下載全部切圖。
（3）繪制交互：
- 設置交互動畫；
- 設置返回鏈接；
- 自動跳轉；
- 克隆交互；
- 支持多種觸發方式。
四、副本
我的建議是團隊可以選擇使用任意云工具 (Paper by Dropbox或Sheet by Google) 將所有副本列在一個三列的表格中。通常，總是有大量的副本不能被硬塞進UI原型，因此我們需要在其他地方記錄它們。
作為參考，我繪制了一個簡潔的副本表格模板。
首先，指定副本的類型。這有助于開發人員快速解析列表。這些行可以按照界面的名稱(主頁、購物車、結帳等)進行分組。
其次，指定副本的情況和上下文(例如，用戶是否登錄或是否是已有用戶。否則，一個短暫的事件也可能會影響到一個特定的用戶體驗)。提及上下文或啟發式方法有助于開發人員明白消息何時出現/消失。
最后，匹配實際信息。
大多數情況下，許多產品和設計人員沒有足夠的文案寫作能力，不同的團隊組成將決定你是否需要一個專業的文案。但本文的主題并不是討論設計師是否應該自己寫稿子; 也不是對“抄襲為王”的內容進行咆哮的。我只是建議，當你在分享設計的時候，可以把所有的副本都記錄下來。
另外，無論如何，你都不希望你的開發伙伴在發布前的最后一個小時為你“填寫”副本吧。(此時你可能已經不在這個項目中，而已經為其他項目忙碌一天了。對吧？設計師朋友們。) 因此，創建一個副本表格和督促開發伙伴填寫尤為重要。
五、規隔和資源
（1）?自動化操作：在工期緊迫的設計階段中，還需要耗費時間去整理資源和標注？如今，有了摹客iDoc這樣的產品，設計師不用浪費任何時間用規格、尺寸和風格指南來標注設計，它能夠自動生成智能標注。使用這款智能標注切圖工具，能夠有效節省我們團隊協作的時間。
此外，無論何時你都應該學習和精煉視覺詞匯。熟悉或將相關術語爛記于心，這樣有助于創建一個共享度更高的風格指南。
（2）?建立問責制:自動化的交付過程使設計師有權在開發人員偏離規定的設計時向開發人員提出問題。
例如，在發現構建中的差異時，可以在jira上向負責的開發人員提交Bug或反饋。通過這種方式，可以在一個時間段內有組織地問責，從而不會出現對設計師的郵件轟炸而又沒落實到位的現象。
嗯，對了，關于本版塊的分享，這里分享我在設計交付中的2個小經驗：
在分享你的規格時，不要忘記與開發人員交流你在設計中使用的網格系統。我一般使用8點網格系統，因為市場上幾乎所有的屏幕尺寸都能被8整除。 如果你的設計涉及到許多按鈕或標簽的狀態更改，那么PaintCode可以很好地滿足這種需求。另外，它將SVG路徑和ColorData轉換為生成Swift或ObjC類，您可以簡單地與開發人員共享Swift / ObjC /java文件。我聽說很多開發人員都很喜歡PaintCode，盡管我個人并沒有使用過。
六、檢查表
任何設計執行過程中最令人揪心的部分就是“設計缺失”。共享的設計中總是會有一兩個邊緣案例缺失，這通常出現在設計執行的最后環節，而迫在眉睫的最后期限通常會讓人感到恐慌。這需要設計師根據實際情況進行處理，而不是以公式化的方案做出反應。
給大家推薦一個實用的解決辦法，可以避免在設計執行的最后關頭慌亂。
維護所有需要設計的案例和特性的清單;由設計師在項目中創建和管理。 檢查表將標記正在提取的特性的狀態，包括它是否已完成或正在工作。同時，所有完成的行都應該附有到相應設計的鏈接。 ?如果某個特性因為某個從屬項而移動到下一個版本，那么相應的團隊將被標記相關描述評論。
任何不在清單內的東西，都不需要對執行負責，這種共鳴是早在產品、設計和工程師設計解決方案的就應該建立的。通過這種方式，檢查表就成為了一個參考和唯一的真理來源，可以有效防止溝通中出現僵局或關于是否同意構建特性的困惑。
我們設計師在為用戶設計的時候確實花費了許多心思和精力；同時我們也應該對隊友的工作表示同樣的支持和理解。因此，我們應該盡量保持設計交付文檔的簡單和易用性；不使用設計術語和時髦的首字母縮略詞。這種做法讓我想起了一句流行的編程格言：
永遠要這樣寫代碼，就好像最終維護你代碼的人是個狂暴的、知道你住在哪里的精神病患者。
在我們的工作中，開發人員不會忽略你設計的每個細節，而會深入剖析并實現它們。難道他不應該得到最多的理解嗎? 當然也應該。
原文作者：Mohammed Bilal
原文地址：https://uxdesign.cc/https-medium-com-91bilal-guide-to-successful-design-handoffs-18345f42d5d6
本文由 @Mockplus 團隊翻譯發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
那個是什么軟件