平面設計師如何與團隊高效合作

 　　每個(gè)階段都會(huì )有不同的輸出物。第一、二階段主要由產(chǎn)品經(jīng)理負責，第三四五階段主要由產(chǎn)品設計師，也就是我來(lái)負責。我習慣把第三四個(gè)環(huán)節一起進(jìn)行，統稱(chēng)為交互設計階段，然后再進(jìn)行第五個(gè)環(huán)節，也就是視覺(jué)設計階段。因為我之前做的并不是特別好，所以接下來(lái)主要談的是我個(gè)人對之前環(huán)節的反思以及未來(lái)的打算。

　　小公司也需要詳細的交互文檔

　　文檔是一個(gè)最直接高效地記錄產(chǎn)品發(fā)展過(guò)程的工具。即使在Lean UX的流程里，很多時(shí)候撰寫(xiě)詳細的產(chǎn)品文檔會(huì )顯得浪費時(shí)間并且多余。但為了讓團隊里的所有成員，乃至未來(lái)新加入的成員都能理解產(chǎn)品設計的整體思路，完善而清晰的設計文檔必不可少。

　　原則上一個(gè)產(chǎn)品設計的過(guò)程中的主要生成物包括了調研報告，故事版，人物畫(huà)像，用戶(hù)流程圖，界面規劃與交互圖，視覺(jué)稿等。之前我都是把這些部分拆散開(kāi)來(lái)，每個(gè)部分都是獨立的存在于共享云盤(pán)里，所以其他組員沒(méi)有辦法很好地找到他們。并且因為命名地不規范，大家也沒(méi)有辦法把不同的文件一一對應。

　　目前我想到的最好的一個(gè)解決辦法是：提供完整的交互文檔框架。這在大公司也許已經(jīng)很普遍了，但是經(jīng)歷了上一次的流程問(wèn)題后，我才明白到完整的交互文檔的重要性。

　　一個(gè)完整的交互文檔包含了：

　　1. 標題與版本號

　　2. 更改日志(Change Log)

　　3. 產(chǎn)品介紹與設計背景，主要是PRD里的節選部分

　　4. 產(chǎn)品架構和用戶(hù)流程圖

　　5. 界面流程(界面之間)規劃，內容布局和交互操作與反饋(界面內)

　　6. 視覺(jué)稿以及Style Guide (可選)

　　設計師可以隨著(zhù)設計過(guò)程得不斷向前推移，往里面添入新的內容。如果新方案需要對原有方案進(jìn)行微調，也可以直接在更改日志中標注清楚，然后直接在具體的章節里進(jìn)行修改。如果需要對產(chǎn)品的概念或者用戶(hù)流程進(jìn)行大幅度的修改，則可以開(kāi)啟新的交互文檔版本。交互文檔的命名可以是：產(chǎn)品名_平臺_版本_最新修改日期.pdf，例如：Stickleback_desktop_v1_20160424.pdf

　　制作交互文檔的好處在于：第一，人人都可以很直接的了解到整個(gè)項目的過(guò)程，掌握最新的設計變化，只用一個(gè)文檔就可以通行全公司。第二，在設計輸出的過(guò)程中，設計文檔是設計師的語(yǔ)言。制作一個(gè)賞心悅目細節精準的設計文檔，對于自己是一個(gè)好的鍛煉，也能讓其他人看到以及理解設計的價(jià)值。

　　過(guò)程中的設計溝通

　　不同公司的設計文化會(huì )有很大差異。在我們公司整個(gè)設計過(guò)程中的設計溝通，我認為可以分為四部分: 非正式場(chǎng)合下的閑聊，小型設計反饋，線(xiàn)上溝通(我們用的是slack)以及大型的設計評估。

　　非正式場(chǎng)合的閑聊，主要發(fā)生在廚房里或者球桌上，大家聊聊自己平時(shí)做了什么，互相update一下信息。這個(gè)主要起到一個(gè)headsup的作用，也很有利于增進(jìn)同事感情，使得一部分人設計決定更加容易得到buy in。為什么說(shuō)設計師其實(shí)有的時(shí)候就是銷(xiāo)售人員呢。。。

　　小型設計反饋是最常見(jiàn)的活動(dòng)。一個(gè)產(chǎn)品往往會(huì )涉及其他不同部門(mén)的人，我在做設計的時(shí)候，一般做到一半或者做完初版就會(huì )與幾個(gè)利益相關(guān)人schedule一個(gè)小型會(huì )議，來(lái)收集設計反饋。這樣做非常高效，但也容易造成信息不對稱(chēng)——有的時(shí)候產(chǎn)品吸取了ABC的意見(jiàn)，然后EFG雖然對此也有想法，卻毫不知情。結合之前提到的交互文檔以及線(xiàn)上溝通工具，我覺(jué)得比較好的做法是在每進(jìn)行小型設計反饋活動(dòng)，并且更新的文檔之后，就將Change Log強調一下放在Slack的項目群里，并且附上最新版的文檔。這樣對于更改部分有意見(jiàn)的人就可以通過(guò)查看文檔了解到我的設計思路，然后再和我進(jìn)行溝通。

　　大型設計評估一般發(fā)生在設計上有了一些方向性轉變的時(shí)候，參與者不僅包括了全體的組員(dev, PM, designer, reseacher)，有時(shí)候也會(huì )有公司高層參與，提供一些產(chǎn)品商業(yè)策略上的支持。但是基于上次流程中，很多人抱怨他們對于產(chǎn)品設計的方向沒(méi)有完全up to date，我決定在開(kāi)發(fā)下一款產(chǎn)品的時(shí)候，適當增加會(huì )議的頻率。有時(shí)候總是抱著(zhù)“經(jīng)常召集開(kāi)會(huì )，會(huì )不會(huì )浪費大家時(shí)間”的顧慮，現在想想，如果是出于將產(chǎn)品做好的態(tài)度，增加全組成員坐下來(lái)一起溝通的時(shí)間絕對是磨刀石。

　　視覺(jué)稿件的交付

　　視覺(jué)稿件和style guide一般是產(chǎn)品設計的階段性最后一步(當然之后還有迭代啊修改之類(lèi)的)。除了上述的一些交互文檔的規范之外，視覺(jué)稿件交付時(shí)還要考慮的一個(gè)問(wèn)題在于：和程序員工作節奏的協(xié)調。

　　在創(chuàng )業(yè)公司，往往等交互文檔生成之后，程序員就開(kāi)始開(kāi)發(fā)環(huán)節了。所以生成視覺(jué)稿件和產(chǎn)品開(kāi)發(fā)往往是一個(gè)同時(shí)進(jìn)行的過(guò)程。我們上個(gè)產(chǎn)品遇到一個(gè)最大的問(wèn)題就在于，當我還在更新視覺(jué)文件的時(shí)候，程序員們已經(jīng)在implement一些視覺(jué)的細節了。所以有一些他們已經(jīng)開(kāi)發(fā)了的視覺(jué)細節，一旦我后面修改了一下，就需要重新寫(xiě)代碼。項目時(shí)間越是緊張，這種狀況出現的可能性就越大。

　　所以在這里的建議的是，作為設計師可以先針對產(chǎn)品基本的組件：一些具有較高可復用性且具備完善設計、使用說(shuō)明的部分，以及產(chǎn)品使用的字體，基本的間距規則，給出style guide。另外，可以在給出設計稿的時(shí)候，將仍然需要修改的，不確定的部分標注上黃色的小圓圈，所以程序員就明白可以把這部分的設計細節先放一放了。

　　最后一點(diǎn)，遵守design freeze time(設計冰凍時(shí)間)很重要。整個(gè)產(chǎn)品組要對進(jìn)度有一個(gè)共識。因為設計的迭代是沒(méi)有止境的，尤其是小公司，從設計到開(kāi)發(fā)沒(méi)有一個(gè)明確的界限，就更需要對程序員的能力有所尊重。超過(guò)一個(gè)特定日子之后，設計師和PM就應該將修改的內容放入到下一個(gè)周期里去，而不是繼續修改視覺(jué)稿件，給程序員帶去更多開(kāi)發(fā)的壓力。