之前我們探討了敏捷方法在開發過程、產品管理中的種種運用。相信大家在理解了敏捷所傳達的價值觀和原則后，或多或少對你和現有所在團隊的工作模式和方法有些思考和嘗試。

而今天我想從另外一個我一直沒有提及的角色單獨出發，來分析怎么把 UX (用戶體驗設計) 這個角色很好的融入到敏捷環境中。讓我們整個團隊不僅只有“敏捷的味道”，而是打造出真正高效自組織團隊，構建出色的產品。

傳統 Cascade 設計模式

我們知道，敏捷是通過改變開發周期以適應市場需求的變化，避免瀑布開發導致的低質量產品和漫長的開發周期。

這需要打破我們傳統部門墻之間形成的”豎井文化”，開發人員更多的參與產品愿景、用戶故事的構建，可是 UX 團隊除了對于?“?我們應該將用戶需求作為設計過程的中心 “ 這一敏捷中心思想之外，并沒有更多的實踐參與到敏捷開發過程中。

我看到很多團隊在敏捷的實踐中，開發可以和產品快速的構建出一支敏捷團隊，但是設計團隊經常會因為人員配置的問題，同時需要支持多個敏捷團隊，內部其實還是單獨作為一個部門進行小瀑布式工作模式。

甚至敏捷的實踐對于很多設計團隊來說是更大的災難，他們沒有充足的時間輸出更多的規則說明文檔，甚至沒有時間詳細的進行用戶調研工作。

傳統的瀑布設計大家最為熟悉的是雙鉆模式?，該設計流程模式將設計分為4個階段：Discover、Define、Develop 和 Deliver。這一設計方法也被稱作是Cascade Model?，Cascade 意為 Waterfall。而現如今高強度高要求的設計環境中逐漸不能達到更好的效果。

敏捷 UX 模式

針對以上的問題，其實已經有Lean UX?這個概念的興起，雖然還處于萌芽階段，但是它的核心 “ 測試你所擁有的 “ 還是很值得借鑒。今天我想從敏捷 UX模式的角度出發，通過《敏捷宣言》來帶 UX 團隊理解敏捷的第一步，簡述 UX敏捷變革的幾個方面。

人和交互，重于過程和工具

UX 人員常常因為其專業性和團隊其余成員有一定的距離，他們更多關心的是自己的工作，設計工作對于其他成員來說也是一個黑盒。

敏捷 UX 要求設計人員第一步是保持開放的心態，讓其他團隊成員為用戶體驗工作做出貢獻，能夠改進總體設計，制造出更多的產品。同時還能大大增強團隊對于設計的主人翁的態度，承認他們對用戶體驗做出了貢獻。

開發人員也要抽取特定的時間與設計一起解決問題，還可以使用敏捷方法中發展起來的結對編程。讓設計人員和一位開發人員搭配工作。這種實時協作能夠明顯加速設計和實現過程，就像兩位編碼人員結對能夠增加生成代碼質量、減少編碼時間一樣。

并且在每個迭代中增加一到兩次設計審核，不斷得到反饋進行調整，只畫草圖與開發并行工作，UX 人員在代碼開發的時候實時的與開發團隊一起解決設計問題，這樣也能減少 UX 團隊的負擔。

這里需要注意一個問題，在同一個沖刺工作中，UX 人員并不意味著要投入一個或幾個完整的沖刺周期進行規劃、概要設計或者設計構思或用戶調查，也不意味著在迭代周期里不能抽出時間做其他工作，而是要求每個 UX 人員必須估算自己的工作量和跟蹤現有開發的速度，可以相互結合，平衡兩種方法。

可以工作的軟件，重于求全而完善的文檔

傳統的 UX 團隊需要預先完成大型的設計。規格說明往往被認為是設計團隊創建的可交付成果。它的范圍從描述某個特征的簡短說明到描述產品中的交互細節，像一個小說一樣長的說明書。

但是在敏捷的環境下，這種笨重的文檔需要被拋棄，但是不同于拋棄產品需求文檔，設計的規格說明一直以來是設計人員最直接具體的貢獻輸出，摒棄它可能導致 UX 人員覺得技能的失敗。

這需要 UX 人員轉變思想。用真正的溝通代替紙面工作絕對需要適應，可以開始試著用輕量級規格說明替換?；蛘咴趫F隊開發之前，先用故事卡片和線框圖代替功能規格，不再進行繪制重量級文檔交流設計意圖，花費更少的精力完整掌握敏捷方法節奏的能力。記住不管你的規格文檔是什么形式，它不代表全部，這是一次協作的過程。

輕量級的規格說明也可以是簡單的原型，只要說明屏幕交互，這樣消除靜態圖片的解讀，同時可以用于可用性測試。

客戶協作，重于合同談判

敏捷 UX 要求設計師改變自己和客戶之間的關系，將客戶納入設計團隊，在設計的過程中采用靈活的方式將客戶的想法及反饋貫穿到設計過程的每一個階段，使設計團隊可以即時進行修改。

相對于傳統的設計模式，敏捷 UX 能夠發現真正的痛點問題，同時更快地得到客戶反饋，也幫助 UX 人員和客戶建立更好的溝通。

數據表明，在投放市場后，使用敏捷 UX 模式的項目其成功率要遠遠高于傳統設計模式下的產物。比如：Google 的設計項目就是遵循敏捷 UX 的方法。在國外的設計領域，特別是初創公司，能夠運用敏捷 UX 是對設計師的基本要求。

可以利用調查活動，主動采用?RITE、卡片分類、頭腦風暴、認知走查?與客戶一起解決設計問題，加上可用性測試，就能為用戶提供直接影響設計過程、表達需要的機會。參與式設計鼓勵用戶完全投入當前環境，想象理想的未來，并創建理想的表現形式。

這樣的有趣實踐能讓客戶更關注自身體驗和需求，且不受對軟件的了解或者期望限制。

隨時應對變化，重于遵循計劃

可以看出，《敏捷宣言》要求敏捷 UX 強調的是高效并且持續不斷地進行設計以達到客戶滿意的標準。這個價值觀要求激發個體的設計激情和團隊中每個成員的合作與互動，共同達成目標。

而傳統的設計模式，團隊中每個人的分工不同，前期人員在進行用戶調研和市場調研后，分析調研結果并進行總結，然后再進行設計、制作模型、模型測試，分析測試中存在的問題再進行完善，最終制作最終的產品。設計團隊首先需要了解客戶需求，從而完成一個設計師認為完美的作品。這個設計過程通常長達幾個月，并且最終的設計結果可能不是客戶想要的。

傳統的設計流程是一種 one time active，敏捷 UX 模式則是一種可持續化的設計流程。測試是 UX 設計的另一個開始，只有如此不斷地突破、不斷地測試、不斷地完善，才能夠是敏捷ux設計發揮更大的作用，為后期的設計和開發提供更多的支持。敏捷設計強調 “make a real change” 而不是“make a report”，頻繁的測試與修改是敏捷 UX 模式的首要原則。

小結

設計師在敏捷的環境下需要重新思考自己的技術和專注點。

從本質上講，敏捷 UX 描述的是敏捷開發方法論在UX 設計中的上下文情景，是在統一開發和設計師在產品開發中的敏捷過程。通過合作，跨職能的方式來減少對于完整文檔的強調，更加關注于對所設計產品的真實體驗的共同理解。

希望你能因為我的文章有所收獲，把握敏捷的核心，成就你的完美轉型。

本文由 @Yanel 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議