敏捷交互設(shè)計(jì)是敏捷方法論向交互設(shè)計(jì)領(lǐng)域的延伸，它提倡讓所有相關(guān)人參與到設(shè)計(jì)過程中，迭代演進(jìn)式地進(jìn)行交互設(shè)計(jì)，
從敏捷宣言理解敏捷交互設(shè)計(jì)
。從2010年開始，已經(jīng)有越來越的團(tuán)隊(duì)在不同程度上使用敏捷交互設(shè)計(jì)的方法，而放棄了流程化的傳統(tǒng)產(chǎn)品設(shè)計(jì)過程。事實(shí)上，敏捷交互設(shè)計(jì)方法在很多方面都充分體現(xiàn)了敏捷價值觀，因此，理解敏捷交互設(shè)計(jì)實(shí)踐的最好方法是從記錄在敏捷宣言中的價值觀開始。
個體和交互勝過流程和工具
一個傳統(tǒng)交互設(shè)計(jì)的流程一般分成以下幾個步驟進(jìn)行：
任務(wù)分析：任務(wù)分析基于功能列表（一般來自于客戶的功能說明書）──在功能性需求的基礎(chǔ)上拆分出人物流程和場景；
頁面流程：根據(jù)任務(wù)分析的結(jié)果，為每一個大任務(wù)下的子任務(wù)中覆蓋的功能制作頁面流程；
信息建模：根據(jù)頁面流程的設(shè)計(jì)出一套完整的信息框架，滿足用戶所有功能性需求；
原型設(shè)計(jì)：基于信息建模，設(shè)計(jì)出低保真原型，交給美工進(jìn)行頁面美化；
視覺設(shè)計(jì)：基于原型設(shè)計(jì)，對頁面進(jìn)行美化，最終產(chǎn)出高保真原型，同時編寫設(shè)計(jì)說明；
在傳統(tǒng)流程中，我們可以看到非常細(xì)致的分工──產(chǎn)品經(jīng)理負(fù)責(zé)功能的拆解和分類，以及頁面流轉(zhuǎn)；交互設(shè)計(jì)師設(shè)計(jì)信息架構(gòu)和具體交互行為；視覺設(shè)計(jì)師負(fù)責(zé)美化頁面；前端開發(fā)人員負(fù)責(zé)高保真原型。
你是否體看見了傳統(tǒng)瀑布式開發(fā)的影子？弊端顯而易見：
分工造成的局限性──每個人都用自己的視角進(jìn)行工作，無法形成統(tǒng)一的產(chǎn)品視角（Vision）；
分工造成的“不可評價性”──你沒權(quán)利對產(chǎn)品經(jīng)理的功能拆解有異義，因?yàn)槟悴皇沁@方面的專家；
需求在傳遞中產(chǎn)生了失真的風(fēng)險──需要靠大量文檔進(jìn)行記錄；
客戶沒法說不──當(dāng)客戶需要到整個流程的最后看到一個或者兩個大而全的設(shè)計(jì)方案時，他無法提出任何有價值的反饋，這本身就是用一個貴重的半成品綁架客戶；
跟軟件交付中的敏捷實(shí)踐一樣，敏捷交互設(shè)計(jì)倡導(dǎo)全功能團(tuán)隊(duì)，避免過于明顯的分工，和基于分工特有的流程。僅有的流程是基于產(chǎn)品逐步清晰化的過程，而非基于人員的技能，所有人都應(yīng)該參與到這個過程中來。敏捷交互設(shè)計(jì)主要分以下幾個步驟：
尋找產(chǎn)品方向(Inspire)：拋開需求列表，從目標(biāo)人群的期待體驗(yàn)出發(fā)，尋找可能存在的產(chǎn)品方向；
定位產(chǎn)品需求(Identify)：定位本產(chǎn)品需要提供什么樣的消費(fèi)者體驗(yàn)；
設(shè)計(jì)產(chǎn)品體驗(yàn)(Ideate)：對決定的目標(biāo)體驗(yàn)進(jìn)行設(shè)計(jì)；
驗(yàn)證產(chǎn)品設(shè)計(jì)(Implement)：快速制作原型，并頻繁進(jìn)行用戶測試，迭代式改進(jìn)。
圖1. 從體驗(yàn)中尋找交付范圍，把功能列表放在一邊
除了流程簡化和分工融合，在工具的選擇上，敏捷交互設(shè)計(jì)也與傳統(tǒng)方式有所不同──對于交互的推崇高于對特定工具的選擇。
所有在敏捷交互設(shè)計(jì)中使用的工具，都應(yīng)該遵循一條原則：它必須推動設(shè)計(jì)團(tuán)隊(duì)成員間的交互，而不是簡單提升單個成員的工作效率。
基于此，敏捷交互設(shè)計(jì)中推崇各種輕量級工具，而不是大型的第三方軟件，例如紙質(zhì)原型Paper Protityping而非Visio或Axure此類原型工具。過于精細(xì)的結(jié)果往往會增加協(xié)作和反饋的門檻，雖然可能提升單個成員工作效率，卻達(dá)不到鼓勵交互的目的。
圖2. 使用輕量級的工具進(jìn)行交互設(shè)計(jì)
可工作的軟件勝過完備的文檔
敏捷軟件交付過程中，每個迭代的核心產(chǎn)出是不足夠完美，但卻滿足一個完整業(yè)務(wù)場景的軟件──端到端流程的可完成，而不需要面面俱到的完美。
而傳統(tǒng)開發(fā)方式中在長時間內(nèi)只是各個功能模塊中功能的堆砌，無法在短時間內(nèi)實(shí)現(xiàn)端到端場景，那么文檔便成為串聯(lián)各個功能保證有序開發(fā)的必需品。
傳統(tǒng)交互設(shè)計(jì)也存在這個問題。往往一個標(biāo)準(zhǔn)交互設(shè)計(jì)階段的文檔分三個方面，它們是：
內(nèi)容方面(Content)：內(nèi)容的層次和整體信息架構(gòu)設(shè)計(jì)；
視覺方面(Visual)：整站風(fēng)格的視覺設(shè)計(jì)文檔；
交互方面(Interaction)：整站高保真交互設(shè)計(jì)原型；
仔細(xì)分析這些文檔的生產(chǎn)過程，我們不難發(fā)現(xiàn)以下特點(diǎn)：
它們都是以整站為目標(biāo)，試圖覆蓋所有使用場景；
它們的生產(chǎn)過程是線性的，直到三者全部完成才能夠指導(dǎo)開發(fā)；
正因?yàn)槊總�環(huán)節(jié)的過程是孤立的，無法形成統(tǒng)一的認(rèn)識，文檔傳遞經(jīng)常發(fā)生失真；
一個完美的東西很難得到產(chǎn)品方向性的關(guān)鍵反饋；
敏捷交互設(shè)計(jì)試圖在解決以上問題。
敏捷交付的核心在于盡早地交付出可進(jìn)行端到端測試的代碼，而非完備文檔，而敏捷交互設(shè)計(jì)的核心則在于盡早地交付出可以進(jìn)行端到端可測試的原型，同樣亦非完備文檔。
而這里說的“端到端可測試的原型”包含以下含義：
端到端：必須設(shè)計(jì)出符合合理使用場景的端到端流程，這個流程會覆蓋一個典型用戶最核心的使用場景，所有的交互設(shè)計(jì)應(yīng)該第一時間收斂在這個端到端場景周圍，而非“整站”功能的分割展示；
可測試原型：不需要完美的原型，只需要所設(shè)計(jì)端到端場景中涉及到的原型，同時，原型的完備性上必須達(dá)到內(nèi)容、視覺、交互三者細(xì)致力度一致，在測試中，三者力度的不一致往往會隱藏問題，例如，如果測試的原型視覺上過于完美，就會減弱用戶在交互上的關(guān)注；
假設(shè)我們把交互設(shè)計(jì)的四周拆分成每周一個迭代，每周交付一個覆蓋端到端場景，且在內(nèi)容、視覺和交互方面都相對完備的原型收集反饋或進(jìn)行測試，和傳統(tǒng)項(xiàng)目相比，我們是否可以更早地得到客戶反饋，是否可以讓設(shè)計(jì)過程更透明，是否毋須完備的過程文檔？答案自然是肯定的。
圖3 逐步細(xì)化的原型，不停進(jìn)行用戶測試
當(dāng)然，這樣的過程必然需要多模塊（這里的模塊指技能的差別）之間的融合，實(shí)現(xiàn)全團(tuán)隊(duì)的運(yùn)作。
你會問我，這是否意味著我們的交互設(shè)計(jì)師需要學(xué)會使用IIlustrtor進(jìn)行視覺設(shè)計(jì)？或者視覺設(shè)計(jì)師需要學(xué)會HTML+CSS+jQuery制作高保真原型？
是的，在很多情況下，敏捷交互設(shè)計(jì)團(tuán)隊(duì)中的設(shè)計(jì)師確實(shí)需要具備多種功能的T型人才──他們有專業(yè)的技能，也可以在其他方面有足夠的貢獻(xiàn)。
分工的結(jié)果只能導(dǎo)致能力的停滯不前、產(chǎn)品視角的缺失、職能不可替代的風(fēng)險、協(xié)作軟的低效、溝通的浪費(fèi)等等，而唯一的好處在于，可以更快和“更不被抱怨（如德魯克說過程文檔的價值在于管理抱怨）”產(chǎn)生一堆堆相互分裂且無法讓客戶挑錯的文檔。
客戶協(xié)作勝過合同談判
讓我們舉例說明在傳統(tǒng)交互設(shè)計(jì)階段出現(xiàn)的場景：一份標(biāo)書、一份功能列表、一份到處使用的所謂用戶體驗(yàn)調(diào)查問卷，在交互設(shè)計(jì)的開始階段，我們和客戶在一起進(jìn)行“需求調(diào)研”，其實(shí)這些不重要，我們只需要對比我們之前的產(chǎn)品都有哪些功能可能有重復(fù)，類似產(chǎn)品有哪些可以借鑒，調(diào)研往往只是形式，關(guān)鍵還是未來的二至四周；
然后最后一次見客戶也許就是最終文檔提交的那天，給客戶看一套精美的PSD文檔，一般我們會做出A和B方案，其中不乏我們臆想出來的需求，有時只為讓那個區(qū)域看起來不那么空，客戶高興地選擇了其中的一套方案后，交付正式開始，
管理資料
《從敏捷宣言理解敏捷交互設(shè)計(jì)》(http://www.msguai.com)。這就是基于合同進(jìn)行設(shè)計(jì)的典型場景，誰也不知道合同中的功能列表意味著什么，而對于客戶來說，它確實(shí)是購物單，真正交付時已忘記為什么需要。
但這不妨礙交互設(shè)計(jì)師進(jìn)行設(shè)計(jì)，大部分時候他們并沒有仔細(xì)思考這個功能真正的使用場景，而是把它“畫”出來，讓它看起來很美，卻不管它如何實(shí)現(xiàn)和如何被用戶使用。
這是基于合同進(jìn)行設(shè)計(jì)自然而然的結(jié)果，在每個功能上，設(shè)計(jì)師都希望當(dāng)成對自己的挑戰(zhàn)，他們絞盡腦汁收集類似產(chǎn)品類似功能，盡可能取悅客戶，說服他們采用更炫更豐富的交互方式，而作為不對交付負(fù)責(zé)的人他們毋須承擔(dān)責(zé)任。
而敏捷交互設(shè)計(jì)希望打破這種基于合同或者換言之，基于功能列表的設(shè)計(jì)模式。它希望在設(shè)計(jì)的全過程將客戶參與進(jìn)來，讓客戶了解某個標(biāo)書上的功能也許沒有意義，或者不是當(dāng)下應(yīng)該解決的問題──一個交付項(xiàng)目范圍的最好確定時機(jī)就是在交互設(shè)計(jì)過程中客戶的全程參與�？蛻魠⑴c的優(yōu)勢有以下幾點(diǎn)：
過程的透明化提升客戶的安全感，隨時保持對設(shè)計(jì)進(jìn)度的了解；
最好的反饋模式就是讓客戶親身參與設(shè)計(jì)過程；
了解最終用戶和業(yè)務(wù)模式的是客戶，客戶是不可多得的資源；
當(dāng)設(shè)計(jì)結(jié)果是功能列表的重新確認(rèn)，對于合同中的內(nèi)容便達(dá)成了新的共識；
客戶參與的過程是建立信任的最佳機(jī)會，良好的信任關(guān)系應(yīng)該在最開始就建立；
在產(chǎn)品設(shè)計(jì)方向上和客戶達(dá)成一致，而不是僅靠標(biāo)書或者訪談結(jié)果的支言片語；
提升參與感有助于培養(yǎng)更負(fù)責(zé)的客戶，在交付階段，之前的努力將會獲得巨大的回報(bào)；
有效控制設(shè)計(jì)的變化，當(dāng)客戶親身參與設(shè)計(jì)決定過程時，很多盲目的設(shè)計(jì)變化會減少很多；
圖4 和客戶一起進(jìn)行設(shè)計(jì)
擁抱變化勝過遵循計(jì)劃
當(dāng)你的設(shè)計(jì)不能和客戶一起進(jìn)行，你只是個標(biāo)書需求列表的簡單執(zhí)行者，需求的變化便是理所當(dāng)然的事情。
在有些傳統(tǒng)交互設(shè)計(jì)流程里甚至出現(xiàn)“需求凍結(jié)”這樣的流程──如果你已經(jīng)對某個環(huán)節(jié)的文檔進(jìn)行進(jìn)行簽收，就不能在“需求凍結(jié)”后改變主意。這樣的結(jié)果無非兩個：一盡量不要簽收那個環(huán)節(jié)的文檔；二在需求沒有凍結(jié)的時候抓緊機(jī)會改變主意。
從敏捷宣言的角度來看，之前的三句話是最后一句話的基礎(chǔ)，如果不能做到對個體和交互的尊重，把可用軟件當(dāng)作產(chǎn)生核心價值的東西，并且努力和客戶進(jìn)行協(xié)作，談?chuàng)肀ё兓皇强赵�。在敏捷交互設(shè)計(jì)中，遵循同樣的道理：
對個體和交互的尊重──當(dāng)需求發(fā)生變化時，因?yàn)樵谛碌牧鞒讨袑Ξa(chǎn)品視角的重視，可首先對需求變化的價值進(jìn)行判斷，即它是不是匹配達(dá)成一致的產(chǎn)品視角；真正需求變化時，因?yàn)榉止さ哪：约傲鞒痰暮喕筛`活地調(diào)配資源進(jìn)行處理；再者因?yàn)榇罅渴褂幂p量級的工具，修改成本大大降低；
關(guān)注可工作的軟件──因?yàn)槲覀儼芽蛇M(jìn)行的端到端場景測試作為敏捷交互設(shè)計(jì)過程中最重要的目標(biāo)，當(dāng)出現(xiàn)需求變化時，可通過審視變化本身“是否包含在端到端場景中？如果不產(chǎn)生這樣的變化，用戶因此有何種損失”來判斷需求變化本身的價值；同時，因?yàn)槟軌虮M早的得到端到端場景原型設(shè)計(jì)，需求本身往往來自于用戶測試的結(jié)果，這樣的需求變化往往是有價值的，有理可依的；
客戶協(xié)作的重要性──需求變化往往來自于客戶的不確定性，很多情況下這種不確定又來自于一個新產(chǎn)品背后業(yè)務(wù)模式的不確定，客戶協(xié)作幫助在設(shè)計(jì)過程中及早發(fā)現(xiàn)和解決這種來自業(yè)務(wù)方面的不確定，同時，客戶協(xié)作對客戶責(zé)任感的培養(yǎng)也大大減少了來自于客戶不負(fù)責(zé)任的需求擺動。
這就是敏捷交互設(shè)計(jì)可以很好的管理用戶需求的根本原因。
從敏捷推行到現(xiàn)在，在交付領(lǐng)域已經(jīng)走向成熟，越來越多的團(tuán)隊(duì)開始采用敏捷方法進(jìn)入開發(fā)，但從軟件交付的全流程來看，早于交付的交互設(shè)計(jì)環(huán)節(jié)目前依然以傳統(tǒng)設(shè)計(jì)方式為主。
隨著消費(fèi)型軟件大行其道，用戶對軟件使用體驗(yàn)的要求越來越高，同時新產(chǎn)品的推陳出新對快速產(chǎn)品設(shè)計(jì)提出新的要求，這樣的背景使得傳統(tǒng)交互設(shè)計(jì)流程不得不做出一些新的調(diào)整以擁抱更加頻繁的變化，這也是為什么很多交互設(shè)計(jì)團(tuán)隊(duì)開始努力嘗試具有敏捷價值觀的敏捷交互設(shè)計(jì)進(jìn)行產(chǎn)品設(shè)計(jì)的主要原因。
最后，讓我們來比較一下傳統(tǒng)交互設(shè)計(jì)方法和敏捷交互設(shè)計(jì)方法的區(qū)別：
傳統(tǒng)交互設(shè)計(jì)
敏捷交互設(shè)計(jì)
沒有交付團(tuán)隊(duì)的參與；客戶參與度低；設(shè)計(jì)團(tuán)隊(duì)中各職能分工明確；
交互設(shè)計(jì)師、用戶研究者、視覺設(shè)計(jì)師、前端開發(fā)者、客戶代表、以及開發(fā)團(tuán)隊(duì)代表都完整參與整個交互設(shè)計(jì)的過程，并只有能力區(qū)分而弱化職責(zé)分工；
客戶需求文檔中的功能列表是貫穿設(shè)計(jì)過程的主線；
基于終端使用者期待體驗(yàn)的設(shè)計(jì)過程，往往客戶功能列表只作為參考；
各自有各自對產(chǎn)品的理解，無法達(dá)成共識；
對產(chǎn)品設(shè)計(jì)方向的形成共識是貫穿整個交互設(shè)計(jì)階段；
使用大型的交互設(shè)計(jì)軟件；
鼓勵使用白板、海報(bào)、貼紙、手繪等輕量級的工具；
客戶只在開始和結(jié)束參與項(xiàng)目；
客戶全程參與設(shè)計(jì)活動；
主要以文檔制作為主；
主要以Workshop工作坊活動為主，高互動過程；
設(shè)計(jì)師單獨(dú)和封閉工作；
設(shè)計(jì)師合作式的工作，隨時把工作的產(chǎn)出物展示，接受反饋；
設(shè)計(jì)師能力專一；
鼓勵T型人才；
缺少用戶測試；
在不同精細(xì)度的原型上快速進(jìn)行用戶測試，迭代式演進(jìn)設(shè)計(jì)；
大而全的設(shè)計(jì)；
只設(shè)計(jì)足夠的交互；
遠(yuǎn)離客戶以避免變化；
和客戶在一起鼓勵變化；
不對交付負(fù)責(zé)，肆意發(fā)揮；
對交付負(fù)責(zé)，在成本接受的范圍內(nèi)創(chuàng)新；