顛覆流程

先研究，再設計的方式將被一個新方式取代：先設計，再研究，它可靠嗎?

有多少次你為了能在項目最開始就進行實地研究與觀察而奮戰(zhàn)?有多少次你耐心地解釋初期研發(fā)花費的時間會使產品更快地進入市場?又有多少次你是成功的?在人機交互行業(yè)(HCI community)，長期以來總在抱怨沒有從仔細的觀察開始來進行產品開發(fā)。

我越想越認為是我們這些人機交互專家錯了。犯錯的也包括我，因為我長期以來都擁護“先研究，再設計”。現(xiàn)在，我對許多項目建議的順序是“先設計，再研究”。

讓我們面對現(xiàn)實：一旦一個項目被確定下來，再來研究它應該是什么就太晚了。如果你想做創(chuàng)新性研究，必須在項目上馬之前進行。首先，你得在作項目決策的團隊中謀得一席之地——這意味著你必須是管理層中的一員。(人機交互界的毛病之一：很少有人是管理者。)

而且，既然大多數項目都是由既有項目推進，那為什么我們要重新研究用戶?我們不是應該在整個決策過程中一直研究他們嗎?一旦項目開始就為時已晚了。好好想想這一點。

然而，也請大家注意到這個矛盾：我們所有的可用性理論家長期以來都贊成迭代設計(iterative design)，試圖擺脫冗長、僵化的線性項目時間表，因為那妨礙了彈性與變化，使得項目進程減緩。我們擁護的迭代設計則具有頻繁而迅捷的原型(prototyping)與測試。

其實，我們不斷強調的先期用戶研究、實地觀察及對用戶真實需求的發(fā)現(xiàn)是不進反退之舉：它們是插到設計與編碼階段之前的一個線性、僵化步驟。我們?yōu)樽约汗拇档氖且环N瀑布開發(fā)方法(waterfall method：試圖在一開始就找出所有需求，然后順序地完成整個項目)。是的，當我們說需要時間來進行所謂的實地研究、仔細觀察之際，我們正在與自己所聲稱要提倡的方法相抵觸。

編程人員長期以來困擾于類似的問題。他們也試圖消滅冗長、僵化、拖慢進程的線性項目時間表。他們正在嘗試敏捷方法(Agile)與極限編程(Extreme Programming， Xp)等許多新的快速的迭代編程方法。

始于冗長的目標設置，然后設計，編程，再測試的線性項目流程(即“瀑布方法”)已經完蛋了。謝天謝地。新的編程方法涉及迭代設計與多學科團隊合作等每一件我們想要爭取的東西。現(xiàn)在是時候讓用戶界面設計圈跟隨他們的步伐了——來做我們自己一直在宣傳的事。

實地研究、用戶觀察、情境分析(contextual analyses)及其他所有致力于找出真實人類需求的程序和以往任何時候一樣重要——但它們應該在產品流程之外完成。這是決定建造什么樣的產品所必需的信息，而整個項目正是基于此上。不要在項目啟動以后堅持做這些事，那時已經太晚了，你只會拖累每個人。

一旦項目開始，它就將嚴格受制于時間與資源，這是無法改變的事實：所有的產品團隊都能感受到這種約束，我們的目標是在多學科團隊中工作，來快速高效地制造出有效而討人喜歡的設計。如果可以，先設計，然后回顧，測試，再設計。讓開發(fā)與營銷團隊知道產品看上去將是什么樣的，并且在項目一開始就這樣行動。相信我們具有迅速設計出精致、易懂界面而無需(冗長)研究的能力。成為團隊的重要部分，這樣我們的成果才能與所有其他人的同時準出。幸運的是，這是新開發(fā)方法的—部分

所以讓我們將實地調查、觀察研究與概念設計工作同來自真正產品項目的需求分析區(qū)分開來，我們必須在項目開始之前就發(fā)現(xiàn)用戶需要什么，因為一旦開始，方向就已經被決定了。使用快速、迭代的方法迫在眉睫，這些新方法最好的地方在于為我們提供了空間：它們明確地知道人機交互設計的重要性。