Article copyright by Cennydd Bowles
Cennydd Bowles版權所有
原作者：Cennydd Bowles；譯者：UCD翻譯小組，Sophie；  校審：Angela
原文鏈接：http://www.alistapart.com/articles/gettingrealaboutagiledesign

    敏捷開發(fā)方式是不會被淘汰的。金融危機在過去幾個月中終于爆發(fā)了；長期的要求和浮夸的前期文檔不被接受的情況比以往更為普遍。軟件必須從一開始就可見并且有價值。對很多設計師來說，他們對敏捷理論已非常熟悉（對此不太了解的，請參看文章最后的一些推薦閱讀）。我們正在面臨適應或是被淘汰的選擇。好的方面是，敏捷理論仍然允許我們做那些我們認為有價值的事——研究，發(fā)展一個觀點，測試并提高我們的設計——我們需要的只是新技巧。如果我們想在這越來越嚴峻的形式下與時俱進，現(xiàn)在是實踐的時候了，證明設計可以適應。

    淵 源
    時間，研究和構思有史以來都是設計師熟悉的領域，它們和我們與生俱來的想像和直覺相適應，并且使我們能夠?qū)⒛：橄蟮摹捌放啤焙汀坝脩粜袨椤弊屑毥Y合起來然后轉(zhuǎn)化成開發(fā)人員喜歡的：技術規(guī)范、站點地圖、規(guī)劃圖和圖表。

    而另一方面，敏捷理論意在快速的交付軟件和流暢地應對變化。這兩種模式依靠的是微妙對立觀念：見招拆招 vs 運籌帷幄，遷就變化 vs 先發(fā)制人。 盡管有這些不同，許多敏捷宣言從根本上還是和設計師的思想體系相關的，交互在過程之上，合作在談判之上，反饋，簡潔。都正合我們的意思。

    雖然設計師和開發(fā)者通過不同的視角觀察世界，敏捷哲學從本質(zhì)上是足夠靈活能夠支持這兩種不同的方式和思想的。在敏捷的世界仍然有方法可以適應高品質(zhì)的設計。

    研 究
    鑒于敏捷理論認為“運作著的軟件是評估進展的主要方式”，這使得詳細研究的空間很小。雖然基于敏捷理論的項目能夠在沒有任何用戶資源而（用直覺代替以用戶為中心的設計）的情況下執(zhí)行，但是輸出總是少得可憐。就像手術也許是成功了，而病人卻死了。

    當團隊成員和目標用戶相似時，代入用戶可以滿足需求。設計師可以利用他們的經(jīng)驗工作，發(fā)現(xiàn)潛在的偏見并調(diào)解它。然而這種情況并不多見，大多數(shù)項目從研究中得到有益的東西，避免從錯誤的方向得到動力。 “零次迭代”作為一個爭取時間的方式被接受，有些團隊將這個方式擴展，在沒有用戶反饋交付的情況下增加了中期零次迭代。開發(fā)人員可以整理代碼并規(guī)劃下一步，設計師可以重審品牌、美感、體驗這些貫穿整個站點的東西。

    既然研究必須被輕量級，就不可避免會不精確。幸運的是，即使在每次迭代時進行一次到兩次小型會議都可以滿足需求。一個較好的方式是利用人際網(wǎng)（朋友的朋友，Twitter）并舉行雙重目的的會議：為未來的構想做研究，為已經(jīng)完成的構想做可用性測試。如果不可能獲得真實的用戶，還是有挽救的機會。市場團隊常常是擁有大量的人口數(shù)據(jù)的，服務器日志可以暴露搜索范圍以及其他。這很魯莽，但是甚至是這樣的研究也可以幫助設計師彌補不足。

    這種方式顯然是不適合需要前期研究的縝密型研究團隊。有些團隊試圖雇用項目之外的研究顧問，以便在需要的時候給予研究結論。然而，這樣的結果有可能是混亂的，有用的細節(jié)也可能在溝通過程中丟失。因此，除了大型的項目，設計師最好能通過自己做研究獲得重要深入的見解。

    設計流程
    敏捷的迭代是計劃一個穩(wěn)定的開發(fā)速率，但是設計師并不總能從這種中規(guī)中矩的工作流程中得到益處，因此摒棄計劃對設計來說也是有價值的。準確性可以很靈活，一個大致的估計也可以幫助減少貿(mào)然的設計并且強化與開發(fā)同樣關鍵的設計的重要性。

    “最優(yōu)方法”建議設計師應該研究迭代n+2，設計迭代n+1，支持迭代n，審核迭代n-1。這是個忠告但是無需照字面意思去做：一些構想的設計需要比這些時間線更久的時間。設計師應該用他們的直覺和經(jīng)驗提前找出潛在的復雜構想，獲得更長的研究周期。這種做法和敏捷理論的規(guī)則有偏差，但是如果對項目有益就該鼓勵。

    愿 景
    缺少連貫是敏捷設計的一個普遍缺陷。這源于敏捷理論的模塊化本質(zhì)和某種程度上一個范圍內(nèi)的力量平衡。產(chǎn)品負責人，有時缺少覺察大局的策略。不加以制止的話，這會導致在戰(zhàn)略上的突發(fā)奇想，提出不穩(wěn)定需求，產(chǎn)品貼近的是公司幻想而不是客戶現(xiàn)實。“地平線效應”能說明這個弊端的癥狀：潛在的問題在不斷的迭代過程中被忽視，在項目完成之前，設計師不能確定解決方案是否完全產(chǎn)生了效果。

    幸運的是，我們可以從其他領域借鑒。電影制片人以相似的方式運作，拍攝的順序純粹由邏輯決定。為了保證版本和敘事的連貫性他們聘請專家：導演和監(jiān)制。在網(wǎng)絡領域，設計師可以扮演相似的角色，但必須是自發(fā)自愿的。這意味著參與制作用戶故事板，并試圖引導產(chǎn)品所有者擺脫過度倉促的決定。

    我們?nèi)匀粵]有很多時間探索明確的產(chǎn)品構想，但仍可以通過將用戶故事組織成完整的用戶流程并設計這一系列的用戶故事來達到目的。隨后我們可以將之作為一個整體進行審查和測試。這種做法可以表明很多用戶的總體體驗同時預警那些因“地平線效應”造成的陷阱。

    交付物
    敏捷設計的交付物是輕量的文件。很好——更多的時間用于思考和設計?；谶@種傾向，靜態(tài)的頁面文件和線框圖是行不通的。這些對于敏捷設計來說太僵化，尤其是在頁面已經(jīng)不是網(wǎng)絡的基本組成部分的今天。我們更喜歡“在過程之上的交互”方法，從對話而不是固定的模板開始，使用具有真實交互過程的原型而不是靜態(tài)的線框圖。

    用戶體驗設計師有許多交付物可以選擇，低保真草圖和紙質(zhì)原型是分享設計思路和討論觀點的理想方式，然而這些方式在實際運用中卻出乎意料的少見。通過快速而大量的手繪工作，用戶體驗設計師能夠通過構建一個紙上的信息架構（包括元件，按鈕，導航元素，下拉框等等）來復述他們的設計。

    使用HTML制作原型或借助Axure和iRise這樣的工具也是好的輔助。雖然需要一定的學習曲線，但它們都避免了草圖的含糊（還有裁紙）。它們的靈活性足以應對修改的需求，它們的穩(wěn)定性可以保證測試完整的用戶流程。

    視覺設計師仍然需要創(chuàng)造高質(zhì)量的設計稿，所以終端產(chǎn)品設計也離不開Photoshop或者Fireworks。然而視覺設計師也應該與用戶體驗設計師一起參與早期原型交互設計。

   應該盡早提出解決方案，盡管與某些觀念是格格不入的，但這是敏捷理論的中心。為了節(jié)約時間，每一個內(nèi)容類別只做一個實例——一個形式、一頁研究結果等等，是明智的。通過足夠的溝通，原型可以兼具說明的角色。

    角 色
    我們知道現(xiàn)代組織體系是超鏈接形式的，但是在很多公司里設計仍然是單一決策的。為了迅速的迭代設計必須放棄完美：“90%正確”是敏捷的標準。這可能是違反常規(guī)的，但是不管怎么說，敏捷將時間線的重要性擺在精湛的技藝之上，并不是多大的損失。

    然而，也有妥協(xié)過甚的時候。據(jù)Alan Cooper所言“不會有一大群人對你糟糕的產(chǎn)品翹首以盼?！弊詈玫耐鶗驍∽钕冗M入市場的，而設計師天然的在質(zhì)量管理、通過產(chǎn)品游說贊助商提供額外資源方面做的很好。

    快速有時會誘使設計拘泥于模式化，借鑒其他有創(chuàng)造性的技巧可以有所幫助。設計師應該適應一個協(xié)作者的身份而不是一個獨裁者。這不是指設計應該變得民主——專業(yè)的知識一如既往的必要——只是通過協(xié)同工作，設計師可以促進這種共同設計，并以此提高自身技能的信譽。這一方式還需要一種普遍認知：最好的敏捷設計師，產(chǎn)品經(jīng)理，開發(fā)者和產(chǎn)品所有者都對彼此的原則有很好的理解。

    未 來
    當許多設計師熱衷于適應敏捷理論，少部分人認為這是一種讓步。敏捷就理論來說是成功的：軟件開發(fā)的最優(yōu)方法。但是敏捷與Python、可用性測試或者microformats相比并不是最優(yōu)方法。它只是一種工具：有時適用而有時不是。為此我們看到了后敏捷主義的出現(xiàn)，試圖保留一部分敏捷思想而摒除那些不適應項目的部分。

    不管怎么樣，現(xiàn)在是將敏捷理論和設計團隊就我們共同的未來達成一致的時候了。我們彼此需要，也需要從高高在上的象牙塔上下來。畢竟，我們有著共同的目標：為我們的客戶和用戶提供最好的結果。