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