作者 David Cronin
引 子在 過去幾年里，在Cooper公司的工作中，我們學到了一個經驗：不管項目有多大，與客戶的密切協(xié)作是取得成功的關鍵因素。這是我們吃了不少苦頭后得出的經 驗教訓；協(xié)同工作可能相當雜亂、不可預測，有時候還會逼迫我們不得不妥協(xié)，放棄我們自己認為是極其優(yōu)秀、清晰、卓越的方案。盡管這些痛苦依然存在, 但我們已經開始接受那些不可預測的情況，學會讓步；并通過對客戶協(xié)作加以良好的管理，我們的設計變得越來越好，變得可以更好的服務于客戶的需求、更好的滿 足最終使用者的需要。 本文是一篇實踐研究的文章，向大家介紹并討論我們在項目中曾經采用過的方法，這些方法有利于盡可能的發(fā)揮和利用客戶的專業(yè)長處和反饋信息，同時也保留了創(chuàng)造的動力，最終幫助我們按時完成每個階段的任務。 在開始討論這些方法之前，為了更好的理解，我們先討論一下客戶的目標，并且簡單介紹一下我們在和客戶的工作中遇到的困難。 客戶希望達到的目標客戶和我們一起協(xié)同工作的首要目標是設計出最有效、最創(chuàng)新的方案，來滿足使用者的需求和商業(yè)需要。我們的有些客戶已經明確知道他們的客戶需要什么，渴望什么和什么最有用；而有些客戶則時常冒出新奇的想法，我們很樂意將這些都納入設計的方案中。 正 如David Kelly所說,“一個成功的設計是由團隊中的所有人共同努力完成的。一個人的創(chuàng)造力只能完成設計中的一個跨躍，只有來自團隊中所有人不同的智慧和努力才 能完成整體設計。所以團隊中要擁有跨學科的多種人才，需要有掌握不同技能的人來解決不同的問題。否則，設計的大方向就只能讓一個有能力,或說話最有分量的 人來左右了。”[1] 在此種精神的指引下，在我們的設計過程中，我們努力考慮不同的利益群體(stakeholder)。作為設計者，我們不但要展現(xiàn)出創(chuàng)造力，還要作為輔助者來推動團隊解決問題和創(chuàng)造活動 協(xié) 作要達到的另一個同等重要的目標，就是要全力支持所提出的方案，并且要培養(yǎng)一種主人翁的感覺，和客戶一道把工作堅持下來直至最終完成。軟件的構建過程是一 個困難并且花銷很大的過程。為了我們的工作能夠服務于最終使用者,我們必須先完成設計。支持設計方案并履行對設計方案的承諾，對保證最終產品符合先前制定 的規(guī)范是至關重要的。通過緊密參與設計活動，能夠更好的發(fā)展承諾精神和主人翁責任感，所以，如果一些必要的、合適的人員能夠早點參與進來，則可以避免后期 的一些不必要的修改和不確定因素。 最后要談的目標是按時完成任務，這關系到客戶的利益（和我們自己的利益），這是很重要的。正如我剛 剛提到的，軟件的構建過程的成本是很高的，如果計劃安排不明確，并且組織的不好，成本就更高的可怕了我們在項目過程中，要考慮到客戶的知識水平和理解能 力，這顯然是關鍵的。因此，在項目計劃中考慮客戶的知識水平和理解能力因素，這也是同等重要的。 問 題 和 困 難我 們中的很多人都感謝是客戶養(yǎng)活著我們。但我肯定很少有設計者沒有說過“我們的設計很出色，只是客戶不認可”這樣的話。我不想講設計者艱難創(chuàng)業(yè)的故事，有些 故事里還伴隨著和某些神經質客戶打交道的冒險經歷，我要講的是有一些常常發(fā)生的普遍情況，在這些情況中，有時客戶的反饋和協(xié)作可能讓工程嚴重脫軌。 越改越糟迭 代設計(iterative design)的目的是讓設計方案越來越清晰,項目中的每次開會的決定為下一個會議提高解決方案的寬度、深度或精度。設計行業(yè)中我最經常感受到的痛苦是 “越改越糟”，設計被反復地修改，但對解決問題卻沒有任何幫助。以下是幾種常見的情況: 在外觀設計評論會上，客戶表態(tài)說他們不喜歡所提的任何一個設計方案；在接下來的會上，客戶又突然決定考慮先前被放棄了的方案中一部分。如果每次會議都在懷 疑先前的決定，或者又要重新考慮已經放棄了的方案,那么項目根本無法繼續(xù)下去了。 含糊不清的反饋信息我在和 客戶協(xié)作中經常遇到的第二個問題是，用戶給出的意見和反饋含糊不清，讓人很難采取正確的行動?？蛻敉ǔ换ズ鸵曈X設計的了解相對較少，這樣他們就很難闡 述清楚他們的意見和反饋。還有，我曾經協(xié)作過的許多客戶，他們對問題細節(jié)的關注，不是過細就是過粗。比如，在項目剛開始時，設計組希望得到的是關于交互的 整體框架時的反饋，而客戶卻跟你討論一個細枝末節(jié)的問題。 偏見和成見有時，偏見和成見隱藏在“期望” 中,但由于它們的外表看似合理，但卻華而不實，因此還是能很容易地被辨認出來。舉例來說，有個客戶主觀認為,他們的商務分析應用軟件應該有一個“高層領導 控制面板”，未經調查研究就認為這個功能使用者肯定會感到滿意的，這可能就是一個有害的成見；它可能妨礙了滿足使用者需求的功能設計前進的步伐。 還 有一些偏見和成見出現(xiàn)在技術選擇上，或來源于其他的成功 (但是無關的) 產品。舉例來說，有一種偏見認為，如果某應用是通過web瀏覽器進行操作的，那么該應用就必須要像網站一樣。我以前碰到過一個客戶的三級主管，他認為企業(yè) 應用平臺軟件應該是如同視窗瀏覽器一樣，他根本就不想想有多少人會相信這樣的樹型結構瀏覽應用能夠真正解決問題。 妥協(xié)不一定是最好的解決方法在世界上的各個企業(yè)里都有政治關系，針對一些問題，大家通過協(xié)商并達成共識，然而這并不總能取得預期的結果。優(yōu)良的設計之所以優(yōu)良，其基礎在于該設計的完整性，但為了達成共識而進行的妥協(xié)則可能會破壞這種完整性，從而破壞設計的優(yōu)良品質。 當一個委員會討論并做決策的時候, 委員中的各群體利益的不同，常常使得設計的妥協(xié)成為必然。做決策的人越少，命令就越集中，對設計完整性的危害也就越少。 個人喜好最后要談的是在我們的實踐中也經常遇到的問題，客戶的反饋往往是基于個人喜好的,其對設計方案的評價并沒有考慮該設計是否滿足了使用者和商務目標。 我 們 在 實 踐 中 總 結 的 經 驗那么, 面對這些問題和困難，一個設計團隊如何能有效地和它的客戶協(xié)作，并最終作出符合用者需要和商業(yè)目標的解決方案？在過去的幾年里，為了達到這些目標，我們在某些方面已經形成了我們的方法和程序，提高了我們達成這些目標的能力。我們在實踐中總結出如下經驗。 溝通在Cooper 公司的早期，設計者們在開會討論時，積極地提出各種好的建議和想法，可是有的時候，他們最后討論地筋疲力盡或不可開交進行不下去了，而且他們最后一走了 事，把這些有價值的主意和想法都留在了白板上。后來我們想，雖然設計者們提出了很多很好的主意，但是主意都留在白板上了，沒有人將這些信息傳遞給客戶，那 么這些主意又有什么用呢？ 自那時起，我們便有了專門負責跟客戶溝通的職位。我們很多的設計團隊中至少要包含兩個重要角色：交互設計者和設計溝通者。交互設計者主要負責產生完整的概念設計并將設計方案視覺化；設計溝通者則主要負責把設計方案在設計團隊和客戶之間溝通清楚。 由于設計內容沒有向客戶表達清楚,而導致優(yōu)秀設計被拒絕，這樣的情況我們見過很多。僅僅在客戶面前展示一個作品，并且問“怎么樣，你喜歡么？”，這是不夠的。我們發(fā)現(xiàn)，在展示設計的時候，下面幾個方面的事情必須解釋清楚，這是極其重要的:
一 些讀者可能認為我在這個列表中忽略了很重要的一項，即“其他可能的設計方案”。我的忽略是故意的：當然有時客戶會讓我們展示針對一個問題的多種解決方案， 這時我們一般給只給客戶介紹其中一種我們認為是最有效的并且是最吸引眼球的方案。其他方案我們只在口頭上討論，在口頭上向客戶闡述為什么我們傾向于我們推 薦的那個方案，并告訴客戶，如果我們已經知道了正確的答案，我們將不會把客戶的錢浪費再去探究多種解決方案上。 最后，我要補充一點， 客戶有時好像不太關心上面列出的幾條事情，但我們發(fā)現(xiàn)無論如何也要告訴給客戶，這是至關重要的?？蛻魶Q定著設計組的工作方向，客戶的決定是否堅定如一則取 決于設計組和客戶的溝通。如果客戶在作決定之前沒有考慮上面這些關鍵信息，而當他們再次想到這些信息時，他們將有可能不得不重新考慮并修改他們的決定，而 最終導致設計者再多花幾天或者幾個星期來修改設計方案。 選擇適當的人這一點很明顯不用說么? 也許，但是客戶方參與總體設計和協(xié)作會議的人選對產品是否具有決策權是很重要的。當然，有些公司是由委員會做決定，這種情況下，則讓委員會中的一部分人參與到設計和協(xié)作會議中，這十分有幫助，或者考慮讓整個委員會都參加進來。 關 于在具體的工作中與客戶協(xié)作，我們嘗試在小的設計團隊和較大的功能齊全的團隊之間取一個平衡。開始的構思和結構設計對于一個大的團體是困難的，在此階段 中，概念統(tǒng)一十分重要。雖然有多種多樣的想法對創(chuàng)造力是很重要的,但是較大團體的多樣想法會導致分歧，很難控制，要統(tǒng)一方向幾乎是不可能的。而和客戶一起 進行最初的設計框架的制定，這種做法也要謹慎采用，因為我們遇到過一些情況。比如，客戶的高層代表一開始參與了頭腦風暴的過程，有了先入為主的想法，一旦 發(fā)現(xiàn)最后的方案和前面的不一致時，就可能給整個的設計管理工作帶來不必要的摩擦。 所以，我們剛開始只用一個由較少人組成的很靈活的小組，如有必要可以只請一個客戶代表參加。一旦我們的工作比較成形了，我們再戰(zhàn)略性的邀請一少部分的客戶代表來參與，優(yōu)化我們的設計和想法；直到他們滿意了之后，我們才將設計方案開放給更大的群體。 這個時候，你會發(fā)現(xiàn)，開始階段參與進來的少數客戶代表，可以很好的幫助我們一起同后來參與進來的更多的客戶代表進行溝通，他們起到了具有決定意義的橋梁作用。 我 們會盡量在設計工作的早期就在戰(zhàn)略層次上指定好所有的定義和全部交互框架, 然后再確定交互界面中一些具體的方面、更細節(jié)的內容(本文后面會詳細討論)。所以，我們發(fā)現(xiàn)，越多的戰(zhàn)略層次上的客戶代表能夠越早的參與我們的會議(當我 們決定產品能做什么的時候)，是很有幫助的，這些戰(zhàn)略層次上的客戶代表可以是產品經理、軟件設計師等。之后，當我們開始進行產品更詳細的、外觀和具體的內 容的設計時，再將更多的作具體工作的人員參與進來。。 最后, 我之前已經提到的, 讓客戶認同設計方案是設計者們的極其重要的工作。在Peter Block所著的《Flawless Consulting》一書中，他談到，得到客戶的認可是咨詢服務要達到的目標。“我們可能心存幻想，認為如果我們思路清晰并符合邏輯、講解很有說服力、 并且信念堅定, 就一定能說服我們的客戶。盡管條理清晰的雄辯很有用，但是還不夠?？蛻艨赡苋詴岩刹⑾萑腚y以抉擇的困境。” Peter Block在書中也描述了如何采取最有效的措施在工程的各個階段用消除客戶的懷疑。[2] 計劃和時間安排絕 大多數的大工程的費用和時間在合同中都固定下來，不可更改。作為銷售環(huán)節(jié)的一部份，我們運用一些方法將我們的工作內容和時間計劃安排到具體的每一天。這對 于管理客戶的信息反饋和同客戶協(xié)作具有重要意義，我們能夠預測到和客戶將在哪天討論哪些主題,并且能保證我們對的上客戶高層決策人的忙碌的時間表。然后， 我們能夠圍繞這個時間表來計劃我們的工作。(當然，意外可能還會出現(xiàn), 可能會迫使我們稍微做些改變。) 我們發(fā)現(xiàn)，按照事先制定好的 時間表工作，告訴客戶延遲的影響，可以幫助客戶履行承諾。如果客戶不能夠依照時間表行事,則他們或者必須按照我們推薦的行動路線來繼續(xù)下去，或者延長工期 并增加費用。換句話說，我們告訴他們我們的進程，然后，依照時間表繼續(xù), 除非明確指明更改方式。關于工程結構和協(xié)作關鍵點介紹，參見文章末尾的圖三。 盡早且經常接觸以 往，在正式將設計方案呈現(xiàn)給客戶之前，我們盡可能少的讓客戶參與進來，但這里存在一個問題，就是沒有人喜歡意外事件。如今，項目中一旦有重大情況發(fā)生，我 們便盡可能快的通知客戶并讓他們參與進來。這樣帶來雙重好處：我們有較多的時間考慮并處理客戶的反饋，而客戶則變得更忠于他們參與進展的方案，因此降低了 項目在重要環(huán)節(jié)處受挫的可能性。 我們也努力保持同客戶中的每一個決策人頻繁接觸。我們發(fā)現(xiàn)，他們的參與可讓他們更容易的了解關鍵問題，并且可以幫助他們更好的作出判斷和決定。 圍繞特定議題的框架會議在會議中，與其簡單的向客戶報告我們的工作進程，不如針對某個或某幾個的特定議題進行討論。這樣做的好處很多，我們先討論之前的工作，并從中探討可能的方案，然后拿出適當的數據和材料，來支持我們的建議。 此外，由于會議有了確定的目標，我們能控制會議的長度而且減少離題和散亂的討論。針對某一個決定進行的專題討論，可以幫助客戶做出更明確的反饋, 而且可以保證設計師在會議結束時都清楚下一步行動的方向。 盡早訪談關鍵的利益關系人(stakeholder)一些利益關系人只是簡單地希望他們的觀點被加入新產品。如果到了設計方案評估時才讓他們參與進來的話，他們有可能僅僅因為自己沒有被重視，而直接反對該設計方案。 為 了減少這種可能性，并且確保我們會考慮到每個利益關系人的有價值的觀點，在每個項目的開始，我們都要通過和利益關系逐個面談討論他們的想法、目的和關注的 地方。這不只幫助我們更進一步了解大體需要, 而且也幫助我們從客戶的目標出發(fā)，并用利益關系人的語言來表達我們設計的價值。 “優(yōu)秀的設計”其本身極少能夠打動客戶。與之相反，正如Cameron Foote在《Design Management Journal》（設計管理雜志）上發(fā)表的一篇文章中指出, 客戶普遍希望設計顧問“應該多考慮他們的企業(yè)和市場。不僅要知道如何才能完成設計工程，還要了解他們的業(yè)務、他們的行業(yè)、他們的運作模式、和他們所面臨的 困難。”[3]用角色和情景來構成使用環(huán)境對交互設計師來說，角色(persona)和情景(scenario)是最強大的工具之 一，我們周圍有大量各式各樣的使用角色和情景的例子。在Cooper公司, 當我們說“角色”時，我們指那些非常明確具體的東西。角色是原型化了的使用者模型，他們雖然是虛構的人物，但卻是經過人類學使用研究的觀察，建立在真實行 為的基礎上的，一個單獨的角色可以代表著一大批實際使用者的目標、需要、態(tài)度和傾向。 在處理客戶反饋以及和客戶協(xié)作時，角色有助于塑 造恰當的使用環(huán)境，以評估解決方案是否合適。我們評價一項設計不是依靠個人的品位或美學判斷，而是看它是否有助于使用者達到目標，是否有愉快的、吸引人的 使用體驗。我們描述某個角色經歷一個情景(scenario)，在情景中使用該產品來完成某項任務，通過這種方式來向客戶介紹設計方案。我們發(fā)現(xiàn)，和用屏 幕展示產品界面并讓客戶提反饋意見的方式相比，角色和情景更具有說服力。 真實世界的情景是對角色強有力的補充。當我們的設計產品已經 可以滿足角色們的時候（雖然他們可能會反映出一個或多個真實世界的情景），我們應該去了解產品是否可以讓真實使用者滿意。在和客戶的專題協(xié)作過程中，真實 世界的情景也是很有效的工具。如果客戶對設計的某一方面有疑慮，我們就會把它應用在人的真實需要之中，通過真實世界的情景進行驗證，這樣做可以確保我們知 道如何解決問題，也消除了客戶的疑慮。 正如Hugh Beyer 和Karen Holtzblatt（還有很多其他人）所描述的，以研究為基礎的模擬使用者的需求和工作的流程給了開發(fā)人員和市場人員所需的信息，使他們能定義并構建一種產品。[4] 當 然，角色并非萬能。應用不恰當，他們就會引起同樣多的麻煩和混亂。在使用角色時，我們曾發(fā)現(xiàn)的常見的錯誤有：不是以真正地使用者作為基礎進行研究(在這種 情況下，他們只是未經測試的帶有個人主觀偏見的各種猜想的載體)，或沒有選擇好合適的原型（比如，選擇電腦程序員作為客戶音樂共享服務的原始角色）。 下 面舉一個我們曾經遇到過的這樣的經典例子。有位客戶的高層管理者，認為該公司商業(yè)分析平臺的主要交互部分是讓使用者搜索并瀏覽其功能。為支持其觀點，他開 發(fā)了一個名為佩尼羅普(Penelope)的角色，此角色缺乏實際的工作責任心，她整日四處尋找使用公司軟件的新奇方法。佩尼羅普并不是建立在對使用者進 行研究的基礎上，也并不能代表我們?yōu)槠趦蓚€月四處調查所作研究中的使用者。滿足佩尼羅普的需要去設計軟件，對于我們滿足真實客戶的需要產生了極大的危害。 確定解決方案之前要先明確問題是什么就 一系列的角色進行定義并一致同意該定義后，下一步要做的工作，就是在呈交解決方案之前，系統(tǒng)地定義好產品需求。定義產品需求的目標，是在討論解決方案之 前，就產品功能和如何完成功能取得一致意見。這樣做，我們就能對產品設計中必須做出的各種決定進行歸類劃分，這樣就可以避免讓客戶被迫同時回答“是什么” 和“如何做”的問題。如果不定義好、不歸類劃分，客戶的反饋信息將變得模模糊糊、很不明確，我們也無從就客戶的反饋信息做出響應；而且，當設計組出現(xiàn)了 “是什么”的錯誤時，客戶就可能反對“如何做”，那么這樣一定會陷于“越改越糟”的境地。 有一篇文章討論了醫(yī)學的研究方法學能如何有 效地作為設計研究基礎, Andy Schecterman在該文章中指出，特別復雜的或者混亂的問題，很難被線性方法或者成熟方法解決。他主張“方法不能基于假設，這是極其重要的，太快做 出結論或太快做出的方案通常將被打回到草稿紙上。”[5] 我們還要將產品需求和產品功能區(qū)別開來，這會讓我們的設計工作變得清晰。我 們時常交替的使用“需要”(need)和“需求”(requirement)作為產品功能的抽象描述。我們不能混淆需求和解決方案，否則會妨礙真正有創(chuàng)造 力的、突破性的解決方案的產生。 舉例來說, 在一間食品雜貨商店, 其中的一項需求是“記住要買的東西”；解決方案可能是一張清單紙、一個掌上電腦、或者是可以和智能電冰箱說話的購物車。 我們用分析的方式(不是綜合的方式)定義需求, 以確定每個需求和下列來源之一有緊密相連:
再 次強調，我們必須要將使用者和真實世界的相關情況說明清楚，只有如此，我們才最終能夠把用戶界面的每個方面同角色和業(yè)務聯(lián)系起來。這樣，將設計工作中的個 人口味和偏好摒棄掉，從而幫助設計團隊先合情合理的定義好“是什么”，之后再過渡到“如何做”上面。這樣，有了大家都一致同意的、明確的“是什么”作為基 礎，我們才能在“如何做”上面發(fā)揮自由的創(chuàng)造力。
設計圖的細節(jié)要循序漸近當客戶本來只想看設計整體的粗略圖時，我們就不應該給他們展現(xiàn)具有豐富細節(jié)和精確圖標的精細效果圖。還有，我們設計過程也是始于大而粗略的框架，進而逐步過渡到精細的局部細節(jié)，所以，對待產品設計中的各種繪圖，我們也應該如此—要從粗略的大框架循序漸進到精細的小細節(jié)。 在 設計過程中初稿階段(我們叫做“結構定義”階段)，我們制作了視圖樣式和模板，這些樣式模板只是一些簡單的勾勒，沒有精細到像素層面，其實這些視圖樣式本 來就談不上什么樣式不樣式的。看到這樣的繪圖，我們的客戶便會明白，其實我們并不是在問他們關于產品的顏色是茶色還是棕色這樣具體的問題。客戶了解了這一 點，就會讓我們更容易的專注的處理我們現(xiàn)階段手頭上最重要的問題：繪圖中的框架結構所呈現(xiàn)的方案是否可以實現(xiàn)之前大家都認同的需求？ 簡 言之，設計中的各種繪圖必須找到細節(jié)的合適的平衡點，既要提供足夠多的細節(jié)讓人明白所描繪的方案如何解決了當前的問題，又不能有過多的細節(jié)讓人陷入其中。 這個概念有點像我們所說的“線框(wireframe)”，但卻有些不同。盡管這里明顯有很多不同的效果， 線框通常是沒有任何樣式風格的，僅僅用來在整體上描述界面元素及其功能。雖然我們發(fā)現(xiàn)有時這樣做確實有用，但我們需要的是沒有過多細節(jié)的粗略圖，而線框沒 有滿足這一點。
在 需求定義階段，繪圖中細節(jié)的循序漸進的原則，是在進入到下一階段之前，把本階段的決定徹底確定下來。誠然，在此階段將各項決定分門別類并確定好可能有些困 難，但無論如何，設計組應該以本階段確定下來的方案為基礎，對于需要更多細節(jié)才能確定下來的東西，我們必須要在下一個階段中來探討，而非在本階段。 敢于放棄從 多年和客戶打交道的經驗上看，如果設計師能夠高屋建瓴的將自己的熱情與精力同設計方案保持一定距離，那么整個項目過程就會容易的多。當然，設計師們對于自 己方案的熱情和精力也是極其重要的，因此也為自認為是最優(yōu)秀的方案而極力辯護，但是過于頑固毫不妥協(xié)對建立協(xié)作和達成一致沒有太大的幫助。我就曾經遇到過 幾次客戶根據個人喜好，非常抵制有爭議的方案，并完全棄之。 結 論每個客戶和每個項目都是不同的，本文所述 的實踐研究的目的，不是為各位開一劑保證成功的處方, 而只是一個藥劑列表，所以每個設計公司的每個項目，應該采取不同處方，讓設計項目可以更快更有效的前進，讓設計方案更完善。其次，項目計劃一定要能適應無 法預測的變化。還有，和客戶的協(xié)作過程是需要時間的，所以整個的設計項目也要給協(xié)作讓出必要的時間，不然協(xié)作就是零了。另外，在售前階段和工程范圍定義階 段，設計公司要具備向客戶清楚闡述項目情況的能力；向客戶清晰的說明項目結構的設想，讓客戶清楚的明白投入在協(xié)同工作上的時間是有價值和意義的，還要告知 客戶不按照一致同意的時間表開展協(xié)同工作的風險和危害；這樣，我們才有信心讓我們的客戶做出最符合他們的商務需求的決定。
參 考 文 獻[1]
Kelly, D., Hartfield, B. The Designer’s Stance. Bringing Design to
Software, Terry Winograd, ed. New York, NY: ACM Press, 1996. p. 159
|
|
|
