@董弈?：這一篇文章里，我想談談在節奏飛快的小公司里，設計師應該如何與程序員進行良好有效的溝通，保證產品可以無誤地從設計稿進入到代碼中去。因為在創業公司，這里就默認了設計師與開發人員都對產品具有某種程度的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就應該將修改的內容放入到下一個周期里去，而不是繼續修改視覺稿件，給程序員帶去更多開發的壓力。
目前想到的就是這些。歡迎交流用戶體驗設計中遇到的一切問題。

延伸閱讀

1. Yoyo在他的回答里給出了很好的交互文檔的例子，還附送了模板，一定要強烈推薦給大家！https://www.zhihu.com

2. 《專業干貨！如何寫一份全面易讀的交互說明文檔？》

「技多不壓身的設計師才有高薪資！」

1. 平面設計：《超贊！設計師完全自學指南》
2. 交互設計：《交互設計師修煉指南！教你從零開始成為優秀交互設計師》
3. UI設計：《超實用新手指南！零基礎如何自學UI設計？》
4. 前端開發：《天貓高手來教你！零基礎如何系統地學習前端開發？》
5. 摳圖技巧：《從菜鳥到高手！PHOTOSHOP摳圖全方位攻略》
6. 配色方案：《色彩搭配速成！3個實用方法幫你全面搞定配色》
7. DPI指南：《基礎知識學起來！為設計師量身打造的DPI指南》
8. 交互設計自學路徑圖：《零基礎入門！給非科班生的自學路徑圖之交互設計篇》

原文地址：zhuanlan.zhihu

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

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