|
|
用戶體驗專家Anthony Colfelt使用一個案例告訴我們：僅有敏捷是不夠的；他還深入指出：“以用戶為中心的設計”（以下簡稱UCD）能夠，而且應該與敏捷合并使用。
為了表明自己的觀點，Colfelt首先提出：對于發掘業務的真正需求這個難題，敏捷是合適的解決之道嗎？他以此引出自己的觀點。
就其自身而言，敏捷在調整自己、適應變化方面做得很不錯。但是我們必須知道：它能否用來治療某些癥狀，這些癥狀的更深層次原因在于：業務不知道自己的真正需求。雖然敏捷能讓開發團隊更好地應對這個問題，但是并沒有從根本上解決問題，很多時候還創建出了新的問題。
他從用戶體驗的角度出發，描述了自己所見過的、敏捷出現問題的6種“雷區”：
- 雷區之一：設計角色不清晰
敏捷原則說：“在整個項目過程中，業務人員和開發人員必須每天坐在一起。”這幾乎沒有為用戶體驗設計人員留出任何空間，常常讓開發人員從事此類工作，而他們又很可能不具備相關技能。 - 雷區之二：沒有定義需求收集過程。
敏捷團隊的頭腦中認為：“需求會像魔法一樣從天而降”，從而不愿意花時間和精力制訂產品的長遠戰略規劃，認為這“不敏捷”；類似的情形并不少見。 - 雷區之三：走捷徑的壓力。
強迫用戶體驗設計過程使用與其對應開發工作所采取的迭代方式，這會導致沖動式設計（impulsive design），喪失與用戶測試設計想法的機會。當然，敏捷允許測試真實的產出的可用性，但是要應對由此產生的反饋，所花的時間要超出人們的期望或是他們所能接受的范圍。 - 雷區之四：稱之為“足夠好”的誘惑。
即使（也許應該說尤其）當敏捷表現出色的時候，團隊總要面對排定優先級的需要，是“繼續改進現有特性，讓它們更好”，還是“向產品中繼續添加新特性”？正如Cofelt觀察到的：經常發生的是：繼續改進的工作被放在一邊，人們更喜歡令人興奮的新東西。如此這般，我們構建出來的產品中，所有的特性都不能令人滿意。
- 雷區之五：無風險的概念探索時間不足。
很多敏捷團隊在項目的第一天（或是很接近的時間之內）就會開始著手實際工作。有些團隊會使用“第零個迭代（iteration zero）”來做一些前期的規劃和設計。Cofelt質疑時間是否充足：相對于在編碼之前以粗略的方式驗證某些想法，以可工作的范例來驗證想法這種敏捷的方式是否總能勝出？ - 雷區之六：傷害品牌。
將未經（以用戶體驗設計的方式）實地測試的功能特性放到市場之中，即使是有意要這么做以收集反饋，也會讓客戶很快地喪失信心，不再相信你們公司能夠不斷達到目標；這會傷害你們的品牌，而品牌是很難建立起來的，一旦倒下，再想重樹品牌就更難。
Colfelt做了一個有趣的總結，指出：敏捷本身“善于改進，但是不善于定義”。他強調指出：只用敏捷，也許足以“把現有產品提升至新的水平”；但是，特別是在要開始新東西的時候，“某些層面的規劃是必要的，這樣可以避免勉強拼湊各人對于最好的設計方案的看法，那樣只能產生類似于弗蘭肯斯坦式的怪物。”
他接下來描述了一種傳統的、也是“典型的”UCD過程，要讀者注意該過程中對于產品“戰略”的前期研究（他在后面稱之為“概念設計”，并舉出完美的iPod設計作為典型例子），他強調指出：即使采取敏捷的方法論開發產品，前期研究同樣重要。Colfelt的講述方式很小心，沒有說敏捷排斥這樣的前期思考過程，而是提出：敏捷能夠直接鼓勵此類研究，以彰顯敏捷之長處。
UCD的重點是“戰略”和“概念”挖掘，它可以而且應該與敏捷的“改進”能力相結合；說到底，Colfelt就是希望提升人們對于這一點的認識。
總的來說，要想把二者結合在一起使用，就要避免對它們各自的武斷態度。要記住：敏捷沒有強制如何定義概念或是整體的設計方向，但是很善于執行具體的設計研究和良好的規劃。UCD必須要很靈活，以應對如下現實狀況：實現團隊遇到問題，不得不強制采取另一種設計方案。文檔只記錄必要的信息，以便于傳播。設計與開發團隊應該盡量坐在一起，因為跨職能的協作和面對面的溝通至關重要。設計團隊在開發團隊之前先使用一個sprint也很有幫助，他們就能有足夠的時間測試和迭代。如果遵循這些規則，兩種方式就能和諧共存，發揮作用。
在做出任何強硬判斷之前，不妨先花些時間讀讀Colfelt的全文。你不妨看看Johnny Holland這篇相關文章，其中提到用戶體驗設計人員在敏捷（Scrum）環境中如何調整自己的工作方式，他還討論了與“戰略”相關的類似主題，不過更關注與開發團隊的交互，以及迭代層面的活動和團隊動力相關內容。
查看英文原文： Harmonizing Agile with "User-Centered Design"
it知識庫：讓敏捷與“以用戶為中心的設計”和諧共生，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
