三月份的時(shí)候，頂著巨大的時(shí)間壓力，終于在開Strata+Hadoop會(huì)議的時(shí)候（召開于加州圣何塞的一個(gè)大數(shù)據(jù)會(huì)議），讓公司的產(chǎn)品如期和大家見面了。接下來一段時(shí)間，團(tuán)隊(duì)里針對(duì)之前從產(chǎn)品的設(shè)計(jì)和開發(fā)流程做了一定的反思。其中我們發(fā)現(xiàn)很重要的一點(diǎn)就是，在最后的30天沖刺時(shí)間內(nèi)，因?yàn)樵O(shè)計(jì)師和程序員都是第一次進(jìn)行合作，中間出現(xiàn)了很多溝通上的問題。譬如說，因?yàn)槊看胃脑O(shè)計(jì)后，沒有及時(shí)召開design review，導(dǎo)致部分人對(duì)產(chǎn)品的認(rèn)知出現(xiàn)了偏差。再譬如最后幾天內(nèi)，因?yàn)楫a(chǎn)品的視覺設(shè)計(jì)和開發(fā)是完全并駕齊驅(qū)的狀態(tài)，所以一邊設(shè)計(jì)仍然在變動(dòng)，另一邊開發(fā)已經(jīng)在落實(shí)，造成有些已經(jīng)被實(shí)現(xiàn)的部件仍然需要回去修改。這一篇文章里，我想談?wù)勗诠?jié)奏飛快的小公司里，設(shè)計(jì)師應(yīng)該如何與程序員進(jìn)行良好有效的溝通，保證產(chǎn)品可以無誤地從設(shè)計(jì)稿進(jìn)入到代碼中去。因?yàn)樵趧?chuàng)業(yè)公司，這里就默認(rèn)了設(shè)計(jì)師與開發(fā)人員都對(duì)產(chǎn)品具有某種程度的ownership，并且產(chǎn)品開發(fā)是以小步快跑的模式前進(jìn)。

我們公司的設(shè)計(jì)流程，主要遵照Five element of UX designer（用戶體驗(yàn)設(shè)計(jì)五要素）的原則，先從產(chǎn)品戰(zhàn)略產(chǎn)品價(jià)值，再到產(chǎn)品結(jié)構(gòu)，最后一步步清晰地落實(shí)到產(chǎn)品的視覺設(shè)計(jì)上去。

每個(gè)階段都會(huì)有不同的輸出物。第一、二階段主要由產(chǎn)品經(jīng)理負(fù)責(zé)。

第三四五階段主要由產(chǎn)品設(shè)計(jì)師，也就是我來負(fù)責(zé)。我習(xí)慣把第三四個(gè)環(huán)節(jié)一起進(jìn)行，統(tǒng)稱為交互設(shè)計(jì)階段，然后再進(jìn)行第五個(gè)環(huán)節(jié)，也就是視覺設(shè)計(jì)階段。因?yàn)槲抑白龅牟⒉皇翘貏e好，所以接下來主要談的是我個(gè)人對(duì)之前環(huán)節(jié)的反思以及未來的打算。

小公司也需要詳細(xì)的交互文檔

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

原則上一個(gè)產(chǎn)品設(shè)計(jì)的過程中的主要生成物包括了調(diào)研報(bào)告，故事版，人物畫像，用戶流程圖，界面規(guī)劃與交互圖，視覺稿等。之前我都是把這些部分拆散開來，每個(gè)部分都是獨(dú)立的存在于共享云盤里，所以其他組員沒有辦法很好地找到他們。并且因?yàn)槊夭灰?guī)范，大家也沒有辦法把不同的文件一一對(duì)應(yīng)。

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

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

1. 標(biāo)題與版本號(hào)

2. 更改日志（Change Log）

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

4. 產(chǎn)品架構(gòu)和用戶流程圖

5. 界面流程（界面之間）規(guī)劃，內(nèi)容布局和交互操作與反饋（界面內(nèi)）

6. 視覺稿以及Style Guide （可選）

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

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

過程中的設(shè)計(jì)溝通

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

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

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

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

視覺稿件的交付

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

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

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

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

目前想到的就是這些。歡迎交流用戶體驗(yàn)設(shè)計(jì)中遇到的一切問題。

 

作者：董弈

原文來自：https://zhuanlan.zhihu.com/p/20799449