本文是一個全面的設(shè)計交付指南，其中將為大家分享一些技巧，幫助設(shè)計師能夠順利完成團隊在執(zhí)行階段的協(xié)作工作。

創(chuàng)造一個好產(chǎn)品是一個不斷打磨和實現(xiàn)想法的過程，但完成一個有序且經(jīng)過深思熟慮的設(shè)計開發(fā)過程并不簡單。在執(zhí)行階段的后期，需要解決一些可能導(dǎo)致不必要的升級和重復(fù)修改的問題。

作為設(shè)計師，我們是執(zhí)行力的守護者，對成品中可能存在的瑕疵負有同等的責(zé)任。因此，對于設(shè)計師來說，在每次發(fā)布之前完成設(shè)計的構(gòu)建是非常必要的。

但并不是所有的設(shè)計質(zhì)量檢查都是在過程中進行的，大多數(shù)產(chǎn)品的發(fā)布都是在緊湊的時間安排下完成的。繞過設(shè)計質(zhì)量檢查產(chǎn)生的問題是,擠在那些珍貴的幾小時前發(fā)布，這看起來像一個更簡單的“權(quán)衡“。

但比直接的質(zhì)量損失更有害的是它將這個步驟遺留到即將發(fā)布的版本中，有時它幾乎會在產(chǎn)品的生命周期中徘徊。這樣做的后果不堪設(shè)想！

在強調(diào)了設(shè)計質(zhì)量檢查的重要性之后，設(shè)計師應(yīng)該明確自己也肩負著減輕質(zhì)量檢查和清除bug的重擔(dān)。

在很大程度上，這個擔(dān)子的重量取決于設(shè)計師向涉眾發(fā)布的設(shè)計有多全面。設(shè)計師往往喜歡把自己看成是思考者，而不是執(zhí)行者。通過觀察開發(fā)人員的操作方式來了解交付中的一兩件事情是可以的。

但保持版本控制的嚴謹性、文件/模塊的命名空間、記錄迭代或提交消息或補丁注釋等實質(zhì)性的工作，會幫助設(shè)計人員在工作中獲得更多的生產(chǎn)力和有用的東西。

作了這么多鋪墊，接下來我將分享關(guān)于設(shè)計師如何通過一些技巧來順利完成團隊在執(zhí)行階段的協(xié)作工作，即一個全面的設(shè)計交付指南。

當(dāng)一個設(shè)計成果移交給開發(fā)人員時，它需要傳遞多層信息。除了原型、規(guī)格和資源之外，還必須共享交互、副本和檢查表。所有這些都涉及到設(shè)計解決方案的不同方面，并且需要在一個簡單的、可訪問的文檔中進行比較。我們可以將其稱為設(shè)計交付文檔。

設(shè)計交付文檔應(yīng)該是一站式文件，它的目標(biāo)在于表達產(chǎn)品從設(shè)計到開發(fā)完成的全過程。而一個完整的設(shè)計交付文檔應(yīng)該包括以下5個方面：原型，交互設(shè)置，副本，規(guī)格和資源，檢查表。

一、原型

這個版塊不需多說，大家都很熟悉。從業(yè)多年，我們都能輕松地創(chuàng)建和分享UI原型。這里跟大家分享兩點訣竅，可以幫助設(shè)計師們更好地交付設(shè)計成果：

1. 文件命名保持一致: 讓文件/屏幕名稱不具有任何版本控制形式，簡單地描述它的功能。需要注意的是：在給屏幕命名時，無論你是選擇使用“駝峰命名法”還是其他任意命名法，一定要使用一致的命名法。
2. 有必要的話，把原型相關(guān)內(nèi)容存檔。在交付成果的時候，對于要構(gòu)建的選項?，總的來說是零。所以清除所有舊的迭代和設(shè)計探索，只保存最終原型相關(guān)內(nèi)容，可以讓你在查找或記錄文件名時更方便。

2. 交互

1. 創(chuàng)建流程圖: 將所有原型圖放在一起僅僅完成了一半的工作。你需要使用熱點 (或者制作一個交互式原型) 根據(jù)流程將界面串聯(lián)在一起，這個成果被成為流程圖。創(chuàng)建流程圖可以幫助產(chǎn)品經(jīng)理理解用戶旅程是如何進行的；并幫助開發(fā)人員提前規(guī)劃其使用代碼的方法。
2. 指出保真度: 并不是每個界面都必須用高保真原型來充實。根據(jù)不同的情況，有時候它們可以是帶有批注的靜態(tài)界面；也可以是迎合標(biāo)準交互方式的界面；也有少數(shù)情況下需要與定制原型的保真度保持一致。所有的界面都沒有統(tǒng)一的保真度，因此與開發(fā)人員進行討論并規(guī)定相應(yīng)頁面的保真度。不要花費大量的時間去為一個已經(jīng)存在的簡單交互式原型填充高保真圖片。

無論是通過制作交互式原型還是在每個靜態(tài)屏幕上的添加批注來表達交互，都可以由你自己決定。它們的最終目的都是將交互記錄下來或表達出來。

人們傾向于把這個部分留到最后階段，這時你會聽到設(shè)計師說:“這個部分我會和開發(fā)人員討論一下”；但其實這并沒什么效果。

三、視覺設(shè)計稿交付

UI設(shè)計師完成設(shè)計稿后，少不了和上游的產(chǎn)品經(jīng)理和下游的開發(fā)工程師進行對接。那么，如何才能做到無縫對接呢？在這里，向大家推薦一款快速簡單的產(chǎn)品協(xié)作設(shè)計平臺，摹客iDoc。支持Sketch、PS、XD的設(shè)計原稿和設(shè)計圖，智能標(biāo)注、一鍵切圖、多樣批注、交互原型、全貌畫板、團隊管理，從產(chǎn)品到開發(fā)，只要一個文檔。

（1）智能標(biāo)注：

1. 間距標(biāo)注；
2. 尺寸智能標(biāo)注；
3. 百分比標(biāo)注，兼容多屏幕分辨率；
4. 多選標(biāo)注，告別點擊；
5. 放大鏡，查看微小間距。

（2）智能切圖：

1. 自動切圖；
2. 自動生成不同高倍率；
3. 自由切換平臺；
4. 一鍵下載全部切圖。

（3）繪制交互：

1. 設(shè)置交互動畫；
2. 設(shè)置返回鏈接；
3. 自動跳轉(zhuǎn)；
4. 克隆交互；
5. 支持多種觸發(fā)方式。

四、副本

我的建議是團隊可以選擇使用任意云工具 (Paper by Dropbox或Sheet by Google) 將所有副本列在一個三列的表格中。通常，總是有大量的副本不能被硬塞進UI原型，因此我們需要在其他地方記錄它們。

作為參考，我繪制了一個簡潔的副本表格模板。

首先，指定副本的類型。這有助于開發(fā)人員快速解析列表。這些行可以按照界面的名稱(主頁、購物車、結(jié)帳等)進行分組。

其次，指定副本的情況和上下文(例如，用戶是否登錄或是否是已有用戶。否則，一個短暫的事件也可能會影響到一個特定的用戶體驗)。提及上下文或啟發(fā)式方法有助于開發(fā)人員明白消息何時出現(xiàn)/消失。

最后，匹配實際信息。

大多數(shù)情況下，許多產(chǎn)品和設(shè)計人員沒有足夠的文案寫作能力，不同的團隊組成將決定你是否需要一個專業(yè)的文案。但本文的主題并不是討論設(shè)計師是否應(yīng)該自己寫稿子; 也不是對“抄襲為王”的內(nèi)容進行咆哮的。我只是建議，當(dāng)你在分享設(shè)計的時候，可以把所有的副本都記錄下來。

另外，無論如何，你都不希望你的開發(fā)伙伴在發(fā)布前的最后一個小時為你“填寫”副本吧。(此時你可能已經(jīng)不在這個項目中，而已經(jīng)為其他項目忙碌一天了。對吧？設(shè)計師朋友們。) 因此，創(chuàng)建一個副本表格和督促開發(fā)伙伴填寫尤為重要。

五、規(guī)隔和資源

（1）?自動化操作：在工期緊迫的設(shè)計階段中，還需要耗費時間去整理資源和標(biāo)注？如今，有了摹客iDoc這樣的產(chǎn)品，設(shè)計師不用浪費任何時間用規(guī)格、尺寸和風(fēng)格指南來標(biāo)注設(shè)計，它能夠自動生成智能標(biāo)注。使用這款智能標(biāo)注切圖工具，能夠有效節(jié)省我們團隊協(xié)作的時間。

此外，無論何時你都應(yīng)該學(xué)習(xí)和精煉視覺詞匯。熟悉或?qū)⑾嚓P(guān)術(shù)語爛記于心，這樣有助于創(chuàng)建一個共享度更高的風(fēng)格指南。

（2）?建立問責(zé)制:自動化的交付過程使設(shè)計師有權(quán)在開發(fā)人員偏離規(guī)定的設(shè)計時向開發(fā)人員提出問題。

例如，在發(fā)現(xiàn)構(gòu)建中的差異時，可以在jira上向負責(zé)的開發(fā)人員提交Bug或反饋。通過這種方式，可以在一個時間段內(nèi)有組織地問責(zé)，從而不會出現(xiàn)對設(shè)計師的郵件轟炸而又沒落實到位的現(xiàn)象。

嗯，對了，關(guān)于本版塊的分享，這里分享我在設(shè)計交付中的2個小經(jīng)驗：

在分享你的規(guī)格時，不要忘記與開發(fā)人員交流你在設(shè)計中使用的網(wǎng)格系統(tǒng)。我一般使用8點網(wǎng)格系統(tǒng)，因為市場上幾乎所有的屏幕尺寸都能被8整除。 如果你的設(shè)計涉及到許多按鈕或標(biāo)簽的狀態(tài)更改，那么PaintCode可以很好地滿足這種需求。另外，它將SVG路徑和ColorData轉(zhuǎn)換為生成Swift或ObjC類，您可以簡單地與開發(fā)人員共享Swift / ObjC /java文件。我聽說很多開發(fā)人員都很喜歡PaintCode，盡管我個人并沒有使用過。

六、檢查表

任何設(shè)計執(zhí)行過程中最令人揪心的部分就是“設(shè)計缺失”。共享的設(shè)計中總是會有一兩個邊緣案例缺失，這通常出現(xiàn)在設(shè)計執(zhí)行的最后環(huán)節(jié)，而迫在眉睫的最后期限通常會讓人感到恐慌。這需要設(shè)計師根據(jù)實際情況進行處理，而不是以公式化的方案做出反應(yīng)。

給大家推薦一個實用的解決辦法，可以避免在設(shè)計執(zhí)行的最后關(guān)頭慌亂。

維護所有需要設(shè)計的案例和特性的清單;由設(shè)計師在項目中創(chuàng)建和管理。 檢查表將標(biāo)記正在提取的特性的狀態(tài)，包括它是否已完成或正在工作。同時，所有完成的行都應(yīng)該附有到相應(yīng)設(shè)計的鏈接。 ?如果某個特性因為某個從屬項而移動到下一個版本，那么相應(yīng)的團隊將被標(biāo)記相關(guān)描述評論。

任何不在清單內(nèi)的東西，都不需要對執(zhí)行負責(zé)，這種共鳴是早在產(chǎn)品、設(shè)計和工程師設(shè)計解決方案的就應(yīng)該建立的。通過這種方式，檢查表就成為了一個參考和唯一的真理來源，可以有效防止溝通中出現(xiàn)僵局或關(guān)于是否同意構(gòu)建特性的困惑。

我們設(shè)計師在為用戶設(shè)計的時候確實花費了許多心思和精力；同時我們也應(yīng)該對隊友的工作表示同樣的支持和理解。因此，我們應(yīng)該盡量保持設(shè)計交付文檔的簡單和易用性；不使用設(shè)計術(shù)語和時髦的首字母縮略詞。這種做法讓我想起了一句流行的編程格言：

永遠要這樣寫代碼，就好像最終維護你代碼的人是個狂暴的、知道你住在哪里的精神病患者。

在我們的工作中，開發(fā)人員不會忽略你設(shè)計的每個細節(jié)，而會深入剖析并實現(xiàn)它們。難道他不應(yīng)該得到最多的理解嗎? 當(dāng)然也應(yīng)該。

原文作者：Mohammed Bilal

原文地址：https://uxdesign.cc/https-medium-com-91bilal-guide-to-successful-design-handoffs-18345f42d5d6

本文由 @Mockplus 團隊翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議