接着上次的外包項目總結說。
三、定義公共交互
如果說前面的模塊化是爲以後的設計做準備，那麼公共交互這一塊其實就是貫穿整個設計的過程。在做設計的過程中，其實會發現很多小流程的處理，之前已經做過了，做過了我當然不會再畫一遍，再寫一遍邏輯，我一般只會寫“此處XX邏輯參考XX頁的XX圖”，不過慢慢地，這些一多，就發現自己也會亂掉。當出現次數超過四次時，我就每次寫那句話都有點不太放心，怕自己引用的那個地方也是缺省的，所以每次都要把交互稿翻一下，然後才能信心滿滿地寫下這句“此處XX邏輯參考XX頁的XX圖”。
碰巧之前在一家公司遇到過他們的交互稿，一個公司的產品那就是相當複雜了，所以他們會把一些公共的交互給羅列出來，放在交互稿的前面部分，然後每次引用的時候就是引用公共交互的東西。我覺得這個可以借鑑到小項目的交互稿裏面。也就是說，交互稿除了一開始的說明以及後面的線框圖之外，中間再加入一張畫布“公共交互”，然後把所有出現過兩次以上的交互都可以總結到這張圖上，這個公共交互當然是自己一邊做一邊維護的，不過想來，這樣子做，既可以保證自己畫圖的質量和效率，對於開發來說也是很有裨益的吧。
一些常見的公共交互有：刪除操作、編輯操作、分享操作。只要把這些操作流程在公共交互裏完整地寫一遍，後面的就可以大膽地複用這些公共交互了。
四、溝通方式
正如我一開始說的，我們是一個新的團隊，大家彼此之間都沒有合作過，也不清楚各自的工作方式，導致在設計過程中會暴露出很多問題。我是交互設計師，可能對於整體的把控會更加良好一些，視覺設計師天生比較浪漫主義一些，所以一些事情需要我爲他們考慮到，如果沒有考慮到，他們可能就會耽誤項目的進度。
說兩點在溝通方式上出現的問題，供大家參考一下。
第一點出現在進度安排上，在我做完交互稿之後，發現頁面的數量大大超出了預期，結果他們一聽到就開始信心大受打擊。雖然我一直反覆跟他們說，增加的頁面都比較簡單，但是他們完全都聽不進去，直到後面他們兩個人的分工出現了問題。所以這時候我就只能跳出來做協調人。首先當然是統計頁面的數量，然後給頁面分級，分爲“主-次-送”三個等級，主要頁面當然是比較複雜的頁面，次要頁面是簡單頁面，考慮到有一些頁面實在太簡單了，就當作贈送給公司的。分級的好處就是，他們對於項目的難度有一個較爲良好的認識，壓力沒有那麼大。然後我根據他們的工作能力（一個工作經驗較爲豐富，另一個經驗稍顯欠缺）、剩餘的時間以及他們之前的協商結果，把整個計劃表表做出來，計劃表一是可以方面地查看進度，更加重要的是對視覺設計師的一種“束縛”，束縛他們的浪漫主義。所以計劃表一出來，整個項目才得以順利實施下去。
第二點出現在成果交付上，首先就是他們的視覺稿。他們習慣用Photoshop作圖，然後也比較隨性，隨性的結果就是雖然界面看起來很乾淨整潔，但是圖層的管理就一坨shit，各種“組1”、“圖層1”、“方塊1”的命名層出不窮，外人根本沒法看。你要問爲什麼這會是溝通的問題？因爲我也要審覈他們的視覺稿，有些小問題我自己就改掉了，但是面對這麼雜亂的圖層結構，真的是沒什麼改動的慾望。
接着，就是視覺稿PSD的命名了。我在做交互稿的時候已經將功能模塊化了，每個模塊都會有各自的命名和編號，注意這裏的編號纔是最重要的，因爲可以方便地回溯。但是他們在命名的時候恰恰忘了把這個編號加到每一張PSD上，所以後面整理的時候出了糾紛，還是在我的強烈要求下，他們才全部改了一遍。然後是這麼一堆PSD文件，不可能就隨便打個包吧，至少按每個模塊建立一個文件夾吧。然後如果PSD文件有改動，要怎麼命名吧。這些問題都是一開始沒有想到的，也沒有協商好，結果導致合作上出現了問題。雖然都是小問題的，但是這些都是會在項目的末尾暴露出來，說實話，影響最大的其實是心情，真的是心好累。
林林總總，寫下這四點，當作是給自己的一個總結吧。