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