@凌霜設(shè)計 （Frog Design交互生）： 作為一名交互設(shè)計師，如何更好地與項目里的其他人合作？如何更好地利用大家的時間？團(tuán)隊經(jīng)理用畫圖的方式跟我解釋了一下，有些問題并沒有直接的答案，但是我覺得解釋的方式很有趣，我憑著記憶把它們重新畫了一下，和大家聊聊合作的問題。

今天和我的經(jīng)理聊了一下最近工作上發(fā)生的事：上周做了什么，這周和下周準(zhǔn)備要做什么。剛剛結(jié)束了設(shè)計階段（Design Sprint）1，和客戶開了遠(yuǎn)程會議，收到了許多的反饋意見，各個方面的都有。

現(xiàn)在項目正處于一種（我覺得）特別尷尬的階段：視覺設(shè)計師只出了初步的幾個概念圖，程序員還在準(zhǔn)備框架，尚未開始寫代碼，但是根據(jù)原先的計劃，這周就要開始開發(fā)了。作為交互設(shè)計師，一方面留著一大堆反饋意見還沒有反映到線框圖中，另一方面設(shè)計階段2的任務(wù)已經(jīng)要來了。雖然還沒有開始設(shè)計，但從可能的流程上來看，任務(wù)量巨大，是一個特別復(fù)雜的系統(tǒng)，不光是設(shè)計一個新的交互方式，還是新的工作方式和商業(yè)模式，心里真沒底。

我把自己的困惑告訴了經(jīng)理：作為一名交互設(shè)計師，如何更好地與項目里的其他人合作？如何更好地利用大家的時間？他用了畫圖的方式跟我解釋了一下，有些問題并沒有直接的答案，但是我覺得解釋的方式很有趣，我憑著記憶把它們重新畫了一下，和大家聊聊合作的問題。

什么是敏捷開發(fā)（Agile）

先說一下總體的合作方式，我們用的是敏捷開發(fā)（Agile）的方式。維基百科上是這么解釋的：

敏捷軟件開發(fā)（英語：Agile software development），又稱敏捷開發(fā)，是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。它們的具體名稱、理念、過程、術(shù)語都不盡相同，相對于“非敏捷”，更強調(diào)程序員團(tuán)隊與業(yè)務(wù)專家之間的緊密協(xié)作、面對面的溝通（認(rèn)為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊組織方法，也更注重軟件開發(fā)過程中人的作用。

如果把這種方法簡單視覺化一下，就如下圖：

IxD指的是交互設(shè)計（Interaction Design），VD指的是視覺設(shè)計（Visual Design）,Dev指的是開發(fā)（Development）。ABCDE在這里代表的是不同的階段或任務(wù)，在frog我們叫做設(shè)計階段（直接翻譯可能是設(shè)計沖刺Design Sprint）。

這個圖的意思就是：當(dāng)一個設(shè)計階段A結(jié)束時，交互設(shè)計師就會把工作移交給視覺設(shè)計師進(jìn)行A的設(shè)計，同時開始B的交互設(shè)計；視覺設(shè)計師隨后對A進(jìn)行視覺設(shè)計，然后交給程序員進(jìn)行A的開發(fā)；當(dāng)程序員進(jìn)行A的開發(fā)的時候，交互設(shè)計師的B也做好了，然后轉(zhuǎn)交給視覺設(shè)計師……如此往復(fù)，敏捷開發(fā)的最大的特點就是不需要設(shè)計師把ABCDE全部設(shè)計完后才開始設(shè)計，而是在某個階段結(jié)束后就開始進(jìn)行軟件開發(fā)。

什么是瀑布式開發(fā)（Waterfall Model）

與之相悖的方法叫做瀑布式開發(fā)（Waterfall Model），維基百科解釋如下：

瀑布模型（或稱瀑布式開發(fā)流程）是由W.W.Royce在1970年首次提出的軟體開發(fā)模型，在瀑布模型中，軟件開發(fā)被分為需求分析，設(shè)計，實現(xiàn)，測試（確認(rèn)），集成，和維護(hù)這樣的步驟依序進(jìn)行。

糾結(jié)的交互設(shè)計師

敏捷開發(fā)現(xiàn)在運用得越來越廣，但是據(jù)（經(jīng)理）說卻讓設(shè)計師更加糾結(jié)，這一點我確實有體會到。因為任務(wù)被劃分成了一個一個小階段，時間又很緊。我覺得任務(wù)A還沒做完時，就必須開始做B，把A移交給其他人去做他們該做的事了。而隨著任務(wù)BCD的進(jìn)行，可能是需求變了，可能是視覺或開發(fā)遇到了問題，經(jīng)常還要回頭去改A，一旦交互改了，后面的視覺設(shè)計、開發(fā)也要跟著改。因為沒有足夠的時間去思考透徹A甚至全局，導(dǎo)致回頭修改之前的設(shè)計的幾率大大增加。

更糟糕的情況可能是當(dāng)你做完了ABCDE，卻發(fā)現(xiàn)事情遠(yuǎn)遠(yuǎn)沒有那么簡單，其實還需要做FG等等才能把整個流程設(shè)計完畢（如下圖）。怎么辦？

可惜，并沒有直接的解決辦法！有兩種可能解決的方法：

1. 交互設(shè)計師早一點開始，先把ABC都設(shè)計得差不多了，才移交給視覺和開發(fā)。這樣做的原因是，給交互設(shè)計師更多的時間去理解問題，嘗試解決多個方案，把整個的設(shè)計概念調(diào)整得差不多了，才交給視覺開始做更高保真的界面圖（comps）。
2.交互設(shè)計師和視覺設(shè)計師更緊密地在一起工作，減少交互和視覺之間的時間間隔。更早地看到高保真（high fidelity）的界面圖，有問題可以立即調(diào)整，然后再把已經(jīng)比較成熟的方案移交給程序員。

切忌走得太深

再談?wù)勎壹m結(jié)的“還沒設(shè)計完善就就要進(jìn)入下一步”的感覺。之前在我的心目中，交互設(shè)計師把線框圖畫完，整個設(shè)計的基本框架就定下來了，包括信息架構(gòu)、交互模型（interaction model）、主要的模板，視覺設(shè)計師只是在線框之上錦上添花，表達(dá)更多的東西。而現(xiàn)在我移交給視覺設(shè)計師的線框圖非常地低保真（low fidelity）。有些交互模型還不是最佳的選擇，有些頁面的非主要信息還沒加上去，排版也不是特別好看，總之許多細(xì)節(jié)沒有敲定。而之前在學(xué)校做項目基本上是一人全部操辦，做完了線框圖馬上就做視覺稿了，甚至直接作出的線框圖就挺簡單好看了。我的經(jīng)理給我的建議是，不要在一個小流程里做得太深入。打個比方，假設(shè)這是你作為一名設(shè)計師可以做出的深度：

現(xiàn)在，作為一名交互設(shè)計師，要想辦法把一部分工作讓出來，給視覺設(shè)計師，自己只做到這么深就夠了：

交互設(shè)計師只負(fù)責(zé)低保真的線框圖，讓視覺設(shè)計師自己去操心怎么做出高保真的圖來。這么做的原因有二：

1. 這體現(xiàn)了交互設(shè)計師對視覺設(shè)計師的尊重。讓視覺做自己擅長的事去，不必要越俎代庖，把別人的活也干了。
2. 交互設(shè)計師節(jié)省了糾結(jié)細(xì)節(jié)的時間，把主要的精力放在“解決問題”上面去。讓自己的頭腦一直處于“解決問題”的模式。有利于項目整體的效率和成功。

初級交互設(shè)計師應(yīng)走得寬

公司對于初高級設(shè)計師的期待是不同的。初級設(shè)計師應(yīng)在同一個問題上走得更寬。假設(shè)下圖反映的是同一個問題的不同解決方案ABC：

假設(shè)現(xiàn)在有一個問題要解決，隨便舉個例子吧：如何讓用戶把商品放入購物車？一般來說，初級交互設(shè)計師會給出1-3個解決方案，這三個方案可能有的非常直接，可以做得很深入，有些比較麻煩，做得比較淺。有個幾個方案后，會選出一個來更深入地探索。然而，如果是更優(yōu)秀的初級設(shè)計師，應(yīng)走得更寬一些。同一個問題，可能會想出ABCDEFG7個方案，這當(dāng)中肯定會有一些看起來很荒謬或者行不通的方案，比如E。但是方案E中的某一個點很好，最后選中繼續(xù)發(fā)展的方案可能是A中的一部分，加上了E中的一點，一個有突破性的好設(shè)計就這么誕生了。這一切的根基則在于能夠產(chǎn)生足夠多的點子來挑選。

我身陷泥淖，你放心飛吧

關(guān)于為什么要把交互設(shè)計和視覺設(shè)計分開，讓不同的人負(fù)責(zé)，經(jīng)理打了個比喻，我覺得很有意思：

交互設(shè)計師生活在重力加速度g等于地球的10倍的地方，處理的是那些的最沉重最糾結(jié)的問題（heavy things）。視覺設(shè)計師則生活在加速度g等于地球1/6的地方，他們輕得可以飛起來。只有我們（交互設(shè)計師）竭盡全力在g等于10倍的地方把問題處理好了，他們（視覺設(shè)計師）才能夠飛得更高、更自由。（我：那我可以理解為，我們使用的是不同的大腦半球嗎？）部分是這樣，但是在交互設(shè)計師在對解決方案進(jìn)行發(fā)散分析的時候（所謂“走得寬”），也會用到右腦。

畫了個簡單的示意圖表示如下：

那么，就讓我專心地在泥淖中越陷越深，而你放心飛吧?。海?/span>