第一次組隊接設計外包，我學到了這4個經驗

@Yeah秋強 ：這段時間和朋友接了一個設計外包項目，我是交互設計師，其他兩個負責視覺設計，第一次組團隊，無論團隊內部還是合作公司那邊，都是邊磨合邊工作，進行不是很順利。磕磕碰碰做完后，回顧這次項目經驗，有4點經驗想跟大家分享一下。

設計外包三板斧：

1. 甲方應該給多少錢？《說說設計談談錢！不可不知的設計師接活報價公式》
2. 如何讓甲方給錢？《這才是真相！為什么中國的甲方都不愿意為設計付出高額費用？》
3. 如何讓甲方愉快地給錢：《大牛的7條經驗！插畫師在接外包時都需要注意些什么？》

一、項目需要一張數據表

這次算是一個全新的項目，從零開始，但是實際上第一版出來的功能已經非常多了。產品那邊沒有一個完整的功能列表給我，需求也是時不時進行改動。所以，在做設計的時候，總感覺會遺漏某些狀態的變化，所以，針對這一點，我覺得可以有一張數據表。這張表就是工程師后臺的數據記錄，產品在規劃功能的時候就需要把這張表格給羅列出來，然后在設計交互流程的時候，每進行一個步驟，都需要考慮這個步驟對于這個數據表格的影響，然后把這些變化完整地寫進交互文檔里面。

舉個例子，由于我們的平臺是一個優惠券發放的平臺，那么這個時候涉及到兩個主體：優惠券和領券的人，優惠券的數據就是一個數量的問題。不過對于領券人，數據表有如下：1、未使用的券；2、已使用的券；3、已過期的券；4、待付款的訂單；5、已付款的訂單；6、已退款的訂單；7、積分；8、返利。

羅列了一下，這些是最主要的數據，然后比如說訂單的數據，因為訂單是進行購買優惠券的活動的，所以訂單的數據也會影響優惠券的數據。優惠券消費會有返積分或者返利，所以，優惠券的狀態也會影響積分或者返利的數據。那么也就是說訂單的變化也會影響積分或者返利。這些數據之間關系錯綜復雜，如果有一張詳細的表格，可以把這些變化寫進交互設計文檔里面，我覺得邏輯會更加完整，對于開發人員來說也比較便捷。只是可惜，這些都是做完了才發現的，所以當時就沒有做。

二、將功能模塊化

這次的項目是我有史以來接到的最大的項目，項目功能比較多也比較雜亂，特別是后期加入了一個支付功能，導致整個交互邏輯的復雜度大大增加了。復雜度變大的壞處有三個：①難以梳理邏輯；②容易遺忘一些邏輯；③難以恰當地闡述設計。針對這三個缺點，我在做的過程中嘗試將功能進行模塊化。模塊化的意思是將一些功能進行打包，然后只梳理這些功能之間的關系。梳理完之后，這些功能就形成了一個整體，然后其他功能只和這個整體進行交互而不和其中的功能進行交互。

這么說有點不形象，舉個例子吧，就說電腦吧，電腦可以看成是由顯示器、CPU、內存、硬盤等部件構成的，而其實顯示器里面又是由各種零件構成的，顯示器里面的零件就相當于我的功能，我所做的就是先把一部分打包成“顯示器”，一部分打包成“CPU”，然后把他們當成一個整體來考慮。

顯而易見就是，這么做首先每次處理都只是一部分問題，邏輯比較容易梳理，也不容易遺忘邏輯。當然，更重要的就是表達的問題。如果不進行模塊化的話，我真的不知道該如何在一張畫布上把這些邏輯流程表達出來，所以，模塊化之后，我可以在每張畫布只表達其中一個模塊，當我把所有模塊都闡述清楚了，整個項目也就清楚了。

當然，除了以上的種種優點之外，模塊化還有一個優點就是方便復用。一些常見的模塊，比如注冊登錄模塊，消息通知模塊，個人中心模塊，這些模塊在當今的APP里基本都存在，也就是說他們的復用率都比較高。如果在設計的過程中就已經將這些功能進行模塊化了，之后如果需要設計新產品的功能時，這些模塊就可以直接拿過來復用，省時省力。這個省時省力節約的是功能規劃、界面設計、邏輯推演等等這些時間和精力，所以還是相當可觀的。

三、定義公共交互

如果說前面的模塊化是為以后的設計做準備，那么公共交互這一塊其實就是貫穿整個設計的過程。在做設計的過程中，其實會發現很多小流程的處理，之前已經做過了，做過了我當然不會再畫一遍，再寫一遍邏輯，我一般只會寫“此處XX邏輯參考XX頁的XX圖”，不過慢慢地，這些一多，就發現自己也會亂掉。當出現次數超過四次時，我就每次寫那句話都有點不太放心，怕自己引用的那個地方也是缺省的，所以每次都要把交互稿翻一下，然后才能信心滿滿地寫下這句“此處XX邏輯參考XX頁的XX圖”。

碰巧之前在一家公司遇到過他們的交互稿，一個公司的產品那就是相當復雜了，所以他們會把一些公共的交互給羅列出來，放在交互稿的前面部分，然后每次引用的時候就是引用公共交互的東西。我覺得這個可以借鑒到小項目的交互稿里面。也就是說，交互稿除了一開始的說明以及后面的線框圖之外，中間再加入一張畫布“公共交互”，然后把所有出現過兩次以上的交互都可以總結到這張圖上，這個公共交互當然是自己一邊做一邊維護的，不過想來，這樣子做，既可以保證自己畫圖的質量和效率，對于開發來說也是很有裨益的吧。

一些常見的公共交互有：刪除操作、編輯操作、分享操作。只要把這些操作流程在公共交互里完整地寫一遍，后面的就可以大膽地復用這些公共交互了。

四、溝通方式

正如我一開始說的，我們是一個新的團隊，大家彼此之間都沒有合作過，也不清楚各自的工作方式，導致在設計過程中會暴露出很多問題。我是交互設計師，可能對于整體的把控會更加良好一些，視覺設計師天生比較浪漫主義一些，所以一些事情需要我為他們考慮到，如果沒有考慮到，他們可能就會耽誤項目的進度。

說兩點在溝通方式上出現的問題，供大家參考一下。

第一點出現在進度安排上，在我做完交互稿之后，發現頁面的數量大大超出了預期，結果他們一聽到就開始信心大受打擊。雖然我一直反復跟他們說，增加的頁面都比較簡單，但是他們完全都聽不進去，直到后面他們兩個人的分工出現了問題。所以這時候我就只能跳出來做協調人。首先當然是統計頁面的數量，然后給頁面分級，分為“主-次-送”三個等級，主要頁面當然是比較復雜的頁面，次要頁面是簡單頁面，考慮到有一些頁面實在太簡單了，就當作贈送給公司的。分級的好處就是，他們對于項目的難度有一個較為良好的認識，壓力沒有那么大。然后我根據他們的工作能力（一個工作經驗較為豐富，另一個經驗稍顯欠缺）、剩余的時間以及他們之前的協商結果，把整個計劃表表做出來，計劃表一是可以方面地查看進度，更加重要的是對視覺設計師的一種“束縛”，束縛他們的浪漫主義。所以計劃表一出來，整個項目才得以順利實施下去。

第二點出現在成果交付上，首先就是他們的視覺稿。他們習慣用Photoshop作圖，然后也比較隨性，隨性的結果就是雖然界面看起來很干凈整潔，但是圖層的管理就一坨shit，各種“組1”、“圖層1”、“方塊1”的命名層出不窮，外人根本沒法看。你要問為什么這會是溝通的問題？因為我也要審核他們的視覺稿，有些小問題我自己就改掉了，但是面對這么雜亂的圖層結構，真的是沒什么改動的欲望。

接著，就是視覺稿PSD的命名了。我在做交互稿的時候已經將功能模塊化了，每個模塊都會有各自的命名和編號，注意這里的編號才是最重要的，因為可以方便地回溯。但是他們在命名的時候恰恰忘了把這個編號加到每一張PSD上，所以后面整理的時候出了糾紛，還是在我的強烈要求下，他們才全部改了一遍。然后是這么一堆PSD文件，不可能就隨便打個包吧，至少按每個模塊建立一個文件夾吧。然后如果PSD文件有改動，要怎么命名吧。這些問題都是一開始沒有想到的，也沒有協商好，結果導致合作上出現了問題。雖然都是小問題的，但是這些都是會在項目的末尾暴露出來，說實話，影響最大的其實是心情，真的是心好累。

「優設八月份人氣最高的好文」

1. 一個常見問題：《為什么你的設計作品看上去不夠專業？》
2. 自學的正確姿勢：《光臨摹可不行！平面設計師在空余時間應該怎樣自學？》
3. 大家最喜歡的中文字體：《超實用！有哪些免費的中文字體可以下載？》

原文地址：jianshu

【優設網 原創文章 投稿郵箱：yuan@uisdc.com】

================關于優設網================
"優設網uisdc.com"是國內人氣最高的網頁設計師學習平臺，專注分享網頁設計、無線端設計以及PS教程。
【特色推薦】
設計師需要讀的100本書：史上最全的設計師圖書導航：http://hao.uisdc.com/book/。
設計微博：擁有粉絲量150萬的人氣微博@優秀網頁設計 ，歡迎關注獲取網頁設計資源、下載頂尖設計素材。
設計導航：全球頂尖設計網站推薦，設計師必備導航：http://hao.uisdc.com