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