模板
教程
環境
性能
功能
管理
從敏捷宣言理解敏捷交互設計
敏捷交互設計是敏捷方法論向交互設計領域的延伸，它提倡讓所有相關人參與到設計過程中，迭代演進式地進行交互設計。從2010年開始，已經有越來越的團隊在不同程度上使用敏捷交互設計的方法，而放棄了流程化的傳統產品設計過程。
事實上，敏捷交互設計方法在很多方面都充分體現了敏捷價值觀，因此，理解敏捷交互設計實踐的最好方法是從記錄在敏捷宣言中的價值觀開始。
個體和交互勝過流程和工具
一個傳統交互設計的流程一般分成以下幾個步驟進行：
任務分析：任務分析基于功能列表(一般來自于客戶的功能說明書)──在功能性需求的基礎上拆分出人物流程和場景;
頁面流程：根據任務分析的結果，為每一個大任務下的子任務中覆蓋的功能制作頁面流程;
信息建模：根據頁面流程的設計出一套完整的信息框架，滿足用戶所有功能性需求;
原型設計：基于信息建模，設計出低保真原型，交給美工進行頁面美化;
視覺設計：基于原型設計，對頁面進行美化，最終產出高保真原型，同時編寫設計說明;
在傳統流程中，我們可以看到非常細致的分工──產品經理負責功能的拆解和分類，以及頁面流轉;交互設計師設計信息架構和具體交互行為;視覺設計師負責美化頁面;前端開發人員負責高保真原型。
你是否體看見了傳統瀑布式開發的影子?弊端顯而易見：
分工造成的局限性──每個人都用自己的視角進行工作，無法形成統一的產品視角(Vision);
分工造成的“不可評價性”──你沒權利對產品經理的功能拆解有異義，因為你不是這方面的專家;
需求在傳遞中產生了失真的風險──需要靠大量文檔進行記錄;
客戶沒法說不──當客戶需要到整個流程的最后看到一個或者兩個大而全的設計方案時，他無法提出任何有價值的反饋，這本身就是用一個貴重的半成品綁架客戶;
跟軟件交付中的敏捷實踐一樣，敏捷交互設計倡導全功能團隊，避免過于明顯的分工，和基于分工特有的流程。僅有的流程是基于產品逐步清晰化的過程，而非基于人員的技能，所有人都應該參與到這個過程中來。敏捷交互設計主要分以下幾個步驟：
尋找產品方向(Inspire)：拋開需求列表，從目標人群的期待體驗出發，尋找可能存在的產品方向;
定位產品需求(Identify)：定位本產品需要提供什么樣的消費者體驗;
設計產品體驗(Ideate)：對決定的目標體驗進行設計;
驗證產品設計(Implement)：快速制作原型，并頻繁進行用戶測試，迭代式改進。
圖1. 從體驗中尋找交付范圍，把功能列表放在一邊
除了流程簡化和分工融合，在工具的選擇上，敏捷交互設計也與傳統方式有所不同──對于交互的推崇高于對特定工具的選擇。
所有在敏捷交互設計中使用的工具，都應該遵循一條原則：它必須推動設計團隊成員間的交互，而不是簡單提升單個成員的工作效率。
基于此，敏捷交互設計中推崇各種輕量級工具，而不是大型的第三方軟件，例如紙質原型Paper Protityping而非Visio或Axure此類原型工具。過于精細的結果往往會增加協作和反饋的門檻，雖然可能提升單個成員工作效率，卻達不到鼓勵交互的目的。
圖2. 使用輕量級的工具進行交互設計
可工作的軟件勝過完備的文檔
敏捷軟件交付過程中，每個迭代的核心產出是不足夠完美，但卻滿足一個完整業務場景的軟件──端到端流程的可完成，而不需要面面俱到的完美。
而傳統開發方式中在長時間內只是各個功能模塊中功能的堆砌，無法在短時間內實現端到端場景，那么文檔便成為串聯各個功能保證有序開發的必需品。
傳統交互設計也存在這個問題。往往一個標準交互設計階段的文檔分三個方面，它們是：
內容方面(Content)：內容的層次和整體信息架構設計;
視覺方面(Visual)：整站風格的視覺設計文檔;
交互方面(Interaction)：整站高保真交互設計原型;
仔細分析這些文檔的生產過程，我們不難發現以下特點：
它們都是以整站為目標，試圖覆蓋所有使用場景;
它們的生產過程是線性的，直到三者全部完成才能夠指導開發;
正因為每個環節的過程是孤立的，無法形成統一的認識，文檔傳遞經常發生失真;
一個完美的東西很難得到產品方向性的關鍵反饋;
敏捷交互設計試圖在解決以上問題。
敏捷交付的核心在于盡早地交付出可進行端到端測試的代碼，而非完備文檔，而敏捷交互設計的核心則在于盡早地交付出可以進行端到端可測試的原型，同樣亦非完備文檔。
而這里說的“端到端可測試的原型”包含以下含義：
端到端：必須設計出符合合理使用場景的端到端流程，這個流程會覆蓋一個典型用戶最核心的使用場景，所有的交互設計應該第一時間收斂在這個端到端場景周圍，而非“整站”功能的分割展示;
可測試原型：不需要完美的原型，只需要所設計端到端場景中涉及到的原型，同時，原型的完備性上必須達到內容、視覺、交互三者細致力度一致，在測試中，三者力度的不一致往往會隱藏問題，例如，如果測試的原型視覺上過于完美，就會減弱用戶在交互上的關注;
假設我們把交互設計的四周拆分成每周一個迭代，每周交付一個覆蓋端到端場景，且在內容、視覺和交互方面都相對完備的原型收集反饋或進行測試，和傳統項目相比，我們是否可以更早地得到客戶反饋，是否可以讓設計過程更透明，是否毋須完備的過程文檔?答案自然是肯定的。
原文轉自：http://www.kuqin.com/software-engineer/20111014/312841.html
