為什么項(xiàng)目開始先做用戶觀察是錯誤的
2011-08-26 文章來源: 深達(dá)設(shè)計(jì)
曾經(jīng)多少次你在項(xiàng)目開始時為了可以進(jìn)行實(shí)地研究和觀察而努力抗?fàn)?？曾?jīng)多少次你耐心地解釋現(xiàn)在花費(fèi)一些時間將在未來獲得更快占領(lǐng)市場的回報(bào)？又有多少次你成功了？HCI業(yè)內(nèi)很久以來一直抱怨產(chǎn)品的開發(fā)過程中不允許有時間在開始的時候先進(jìn)行良好的觀察。
我越審視這個話題，就越來來越覺得，我們HCI團(tuán)體是錯誤的。這其中包括我，因?yàn)槲议L期以來一直非常擁護(hù)“先研究，再設(shè)計(jì)”的方法，而現(xiàn)在我建議對大多數(shù)項(xiàng)目來說，順序應(yīng)該是先設(shè)計(jì)，然后研究。
讓我們來直面這一問題：當(dāng)一個項(xiàng)目宣告開始的時候，開始去研究它應(yīng)該是什么樣已經(jīng)太晚了—— 這正是項(xiàng)目宣告已經(jīng)發(fā)布的內(nèi)容。如果你想要進(jìn)行創(chuàng)新性研究，你需要在項(xiàng)目開始前進(jìn)行。你需要成為能決定什么是項(xiàng)目第一步要做的團(tuán)隊(duì)中的一員 —— 這意味著你需要是管理團(tuán)隊(duì)中的一員。（HCI的bug之一：管理層中沒有足夠多的HCI人員）
大多數(shù)的項(xiàng)目都是已有項(xiàng)目的提高改進(jìn)。為什么我們需要再完全從頭開始研究用戶？我們不是已經(jīng)了解了很多關(guān)于用戶的情況了嗎？我們不是應(yīng)該在整個采用周期內(nèi)一直研究客戶嗎？當(dāng)一個項(xiàng)目開始時，已經(jīng)太遲了。想想吧。
但是也需要注意這一矛盾：我們所有的可用性理論專家長期以來一直贊成迭代設(shè)計(jì)的方法，嘗試擺脫漫長的，生硬的線性項(xiàng)目時間表，這樣的時間表會妨礙靈活性和改變，使項(xiàng)目變得緩慢。取而代之，我們擁護(hù)迭代的設(shè)計(jì)方法，在其中頻繁迅速的建立原型并且頻繁迅速地進(jìn)行測試。
但是等等。我們不斷要求預(yù)先進(jìn)行用戶研究，實(shí)地觀察，和發(fā)現(xiàn)真實(shí)用戶需求其實(shí)是在倒退一步：這是在設(shè)計(jì)和編碼階段之前插入的一個線性的，僵硬的過程。我們在為自己倡導(dǎo)瀑布式的開發(fā)方法，甚至在我們拒絕其他人使用這個方法的時候也是如此。是的，伙計(jì)們。但是當(dāng)我們說需要時間作實(shí)地研究，觀察，迅速的紙?jiān)偷鹊鹊臅r候，我們正在和自己宣稱要推廣的方法相沖突。
程序開發(fā)團(tuán)體長期以來也在為類似的問題而斗爭。他們也嘗試消除漫長的，僵硬的，線性的時間進(jìn)度表等會拖慢了項(xiàng)目的方法。他們正在試驗(yàn)使用多種新的方法，例如敏捷編程（Agile Programming），極限編程（XP – eXtreme Programming），以及其他迅速的，迭代的編程方法。他們做的很棒。
線性的項(xiàng)目過程（也被稱為瀑布式方法）正在死亡 ，它具有漫長的目標(biāo)設(shè)置過程，然后是設(shè)計(jì)，編碼，再然后是測試。感謝上帝。新的開發(fā)風(fēng)格運(yùn)用迭代的設(shè)計(jì)，建立多學(xué)科的團(tuán)隊(duì)：這些都是我們應(yīng)該努力爭取做到的?，F(xiàn)在是UI團(tuán)體去追隨領(lǐng)導(dǎo)者的時候到了 – 去實(shí)踐我們自己長期以來所布道的。
實(shí)地研究，用戶觀察，情景分析，和所有為了決定真實(shí)人類需求的方法仍和以前一樣重要 ——但是他們都應(yīng)該在產(chǎn)品進(jìn)程之外完成。這是決定構(gòu)建什么樣的產(chǎn)品所需要的信息，項(xiàng)目將建立在這個基礎(chǔ)上。不要堅(jiān)持在項(xiàng)目已經(jīng)開始后收集這些信息。這樣太晚了；你在拖所有人的后腿。
項(xiàng)目一旦開始，就嚴(yán)格受限于時間和資源。那是現(xiàn)實(shí)：所有產(chǎn)品團(tuán)隊(duì)都能夠感受到這些限制。我們的目標(biāo)是工作在多學(xué)科成員組成的團(tuán)隊(duì)中，迅速有效地推出高效，令人愉快的設(shè)計(jì)。如果可以，在第一天先設(shè)計(jì)，然后回顧評論，測試，再重新設(shè)計(jì)。在項(xiàng)目剛開始的時候就讓開發(fā)與市場團(tuán)隊(duì)了解產(chǎn)品將會是什么樣子，怎樣運(yùn)行。相信我們有快速設(shè)計(jì)精良的易于理解的界面和流程的能力，不需要(漫長的)研究。我們應(yīng)成為團(tuán)隊(duì)中重要的一員，和其他成員一起同時投入其中。幸運(yùn)的是，這已成為新的開發(fā)方法的組成部分。
在CHI郵件列表中關(guān)于這個話題的討論中，有一位參與者寫道：“我從來沒有看到和讀到任何信息顯示說敏捷開發(fā)者（agile programmers）對放慢他們的scrums（一種項(xiàng)目管理方法的名稱）會議，等待進(jìn)行可用性測試沒有興趣。然而，在所謂的敏捷可用性實(shí)踐方法（agile usability practices）中根本就沒有利用用戶研究——它僅僅是個猜測用戶需要什么的游戲。”
這個回復(fù)者糊涂了。可用性測試就像軟件的Beta版測試。它永遠(yuǎn)也不應(yīng)該被用來決定用戶需要什么。它是為了找出bug，所以這種可用性測試仍適合新的，迭代的開發(fā)模式，正如測試bug的Beta版測試仍適合新模式一樣。我長期以來堅(jiān)持認(rèn)為任何以可用性測試為榮的公司其實(shí)都是有很大麻煩的，正如一個以Beta版測試為榮的公司是有問題的一樣。界面和Beta測試僅僅是為了找出bug，而不是重新設(shè)計(jì)。
因此讓我們分開實(shí)地和觀測性研究，概念性設(shè)計(jì)工作，和來自真實(shí)產(chǎn)品項(xiàng)目的需求分析。我們需要在項(xiàng)目開始前就找出什么是用戶需要的；項(xiàng)目一旦開始，方向就已經(jīng)決定。我們需要強(qiáng)調(diào)快速，迭代方法。我們需要適應(yīng)開發(fā)團(tuán)隊(duì)的新的過程方法，我們同時也需要成為團(tuán)隊(duì)的參與者。這些新方法最好的地方在于為我們提供了空間：他們明確指出了HCI設(shè)計(jì)的重要性。只要我們不會拖延工作進(jìn)度，每個人都希望我們加入到團(tuán)隊(duì)中。我們的工作為他們增加了新的力量。
備注：Scrums是一種項(xiàng)目管理方法。請參見 Wikipedia 或其它您喜愛的在線信息網(wǎng)站。
Don Norman博士的背景是工程學(xué)和社會科學(xué)，在學(xué)術(shù)界和工業(yè)界都具有極高的榮譽(yù)。他是美國西北大學(xué)計(jì)算機(jī)科學(xué)系的教授， 以及加州大學(xué)名譽(yù)教授。
Norman 博士是Nielsen Norman Group ，幫助企業(yè)設(shè)計(jì)制造以人為中心的產(chǎn)品和服務(wù)的商務(wù)咨詢公司的發(fā)起人之一。1999年，Upside 雜志并提名他為世界100精英之一。Norman 博士出版了大量的書籍和研究報(bào)告。他是13本書的作者或作者之一，作品被翻譯成12種語言。
© ui花園
閱讀本文英文原文 （翻譯：陳可，校對：李魚）
