設計師如何與產品團隊高效合作？

 　　這一篇文章裡，我想談談在節奏飛快的小公司裡，設計師應該如何與程序員進行良好有效的溝通，保證產品可以無誤地從設計稿進入到代碼中去。因為在創業公司，這裡就默認了設計師與開發人員都對產品具有某種程度的ownership，並且產品開發是以小步快跑的模式前進。

　　三月份的時候，頂著巨大的時間壓力，終於在開Strata+Hadoop會議的時候(召開於加州聖何塞的一個大數據會議)，讓公司的產品如期和大家見面了。接下來一段時間，團隊裡針對之前從產品的設計和開發流程做了一定的反思。其中我們發現很重要的一點就是，在最後的30天沖刺時間內，因為設計師和程序員都是第一次進行合作，中間出現了很多溝通上的問題。譬如說，因為每次更改設計後，沒有及時召開design review，導致部分人對產品的認知出現了偏差。再譬如最後幾天內，因為產品的視覺設計和開發是完全並駕齊驅的狀態，所以一邊設計仍然在變動，另一邊開發已經在落實，造成有些已經被實現的部件仍然需要回去修改。

　　這一篇文章裡，我想談談在節奏飛快的小公司裡，設計師應該如何與程序員進行良好有效的溝通，保證產品可以無誤地從設計稿進入到代碼中去。因為在創業公司，這裡就默認了設計師與開發人員都對產品具有某種程度的ownership，並且產品開發是以小步快跑的模式前進。

　　我們公司的設計流程，主要遵照Five element of UX designer(用戶體驗設計五要素)的原則，先從產品戰略產品價值，再到產品結構，最後一步步清晰地落實到產品的視覺設計上去 。

　　每個階段都會有不同的輸出物。第一、二階段主要由產品經理負責，第三四五階段主要由產品設計師，也就是我來負責。我習慣把第三四個環節一起進行，統稱為交互設計階段，然後再進行第五個環節，也就是視覺設計階段。因為我之前做的並不是特別好，所以接下來主要談的是我個人對之前環節的反思以及未來的打算。

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

　　文檔是一個最直接高效地記錄產品發展過程的工具。即使在Lean UX的流程裡，很多時候撰寫詳細的產品文檔會顯得浪費時間並且多余。但為了讓團隊裡的所有成員，乃至未來新加入的成員都能理解產品設計的整體思路，完善而清晰的設計文檔必不可少。

　　原則上一個產品設計的過程中的主要生成物包括了調研報告，故事版，人物畫像，用戶流程圖，界面規劃與交互圖，視覺稿等。之前我都是把這些部分拆散開來，每個部分都是獨立的存在於共享雲盤裡，所以其他組員沒有辦法很好地找到他們。並且因為命名地不規范，大家也沒有辦法把不同的文件一一對應。

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

　　一個完整的交互文檔包含了：

　　1. 標題與版本號

　　2. 更改日志(Change Log)

　　3. 產品介紹與設計背景，主要是PRD裡的節選部分

　　4. 產品架構和用戶流程圖

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

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

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

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

　　過程中的設計溝通

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

　　非正式場合的閒聊，主要發生在廚房裡或者球桌上，大家聊聊自己平時做了什麼，互相update一下信息。這個主要起到一個headsup的作用，也很有利於增進同事感情，使得一部分人設計決定更加容易得到buy in。為什麼說設計師其實有的時候就是銷售人員呢。。。

　　小型設計反饋是最常見的活動。一個產品往往會涉及其他不同部門的人，我在做設計的時候，一般做到一半或者做完初版就會與幾個利益相關人schedule一個小型會議，來收集設計反饋。這樣做非常高效，但也容易造成信息不對稱——有的時候產品吸取了ABC的意見，然後EFG雖然對此也有想法，卻毫不知情。結合之前提到的交互文檔以及線上溝通工具，我覺得比較好的做法是在每進行小型設計反饋活動，並且更新的文檔之後，就將Change Log強調一下放在Slack的項目群裡，並且附上最新版的文檔。這樣對於更改部分有意見的人就可以通過查看文檔了解到我的設計思路，然後再和我進行溝通。

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

　　視覺稿件的交付

　　視覺稿件和style guide一般是產品設計的階段性最後一步(當然之後還有迭代啊修改之類的)。除了上述的一些交互文檔的規范之外，視覺稿件交付時還要考慮的一個問題在於：和程序員工作節奏的協調。

　　在創業公司，往往等交互文檔生成之後，程序員就開始開發環節了。所以生成視覺稿件和產品開發往往是一個同時進行的過程。我們上個產品遇到一個最大的問題就在於，當我還在更新視覺文件的時候，程序員們已經在implement一些視覺的細節了。所以有一些他們已經開發了的視覺細節，一旦我後面修改了一下，就需要重新寫代碼。項目時間越是緊張，這種狀況出現的可能性就越大。

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

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

　　目前想到的就是這些。歡迎交流用戶體驗設計中遇到的一切問題。