UX最佳實踐提高用戶體驗影響力的藝術目錄\h第1章協作的、創新的設計大綱：使用戶體驗設計成為公司認可、信賴的商業核心戰略性競爭力的重要工具\h1.1到底什么是設計大綱\h1.2設計大綱模板\h1.3設計大綱該寫多長\h1.4什么時候需要設計大綱\h1.5設計大綱由誰來寫\h1.5.1是客戶？還是合作伙伴\h1.5.2共同負責\h1.5.3共同負責人應來自哪個級別\h1.6設計是一門解決問題的學科\h1.7大綱的協作撰寫流程\h1.8設計大綱的主要內容：通向成功的任務清單\h1.9協作設計大綱的商業影響\h1.9.1成為戰略合作伙伴\h1.9.2認可和信賴\h1.10總結\h第2章用戶體驗制度化，成就企業\h2.1SAP是誰\h2.2什么是SAPBusinessByDesign\h2.2.1項目歷程\h2.2.2為什么SAPBusinessByDesign與眾不同\h2.3用戶體驗團隊的角色\h2.4項目階段\h2.4.1第一階段：設計解決方案（目標設計）\h2.4.2第二階段：更接近目標設計\h2.4.3第三階段：開始精益軟件開發\h2.5主要經驗與建議\h2.5.1關于擴大對技術影響力的建議\h2.5.2關于擴大對組織和人員影響力的建議\h2.5.3關于影響開發流程的建議\h2.6結論\h2.7總結\h第3章建立和持續發展用戶體驗的影響：基于不同階段的策略選擇\h3.1誰是中國平安\h3.2中國平安網站在平安集團中的角色\h3.2.1中國平安網站的用戶類型\h3.2.2中國平安網站對用戶體驗的要求\h3.2.3為什么用戶體驗對中國平安網站很重要\h3.2.4在中國平安開展用戶體驗工作的優勢與局限\h3.2.5用戶體驗在平安的地位及發展過程\h3.3工作流程中各個角色的密切配合使用戶體驗達到更好效果\h3.3.1部門間以及同事間是如何合作的\h3.3.2用戶體驗團隊成員的職責\h3.3.3領導者對推動用戶體驗工作有極其重要的作用，通過分享業內案例和研究結論讓領導者了解用戶體驗帶來的價值\h3.3.4通過用戶研究的結論數據讓銷售經理理解用戶體驗帶來的價值\h3.3.5通過用戶體驗方法，幫助項目經理解決他們的難題以增加其參與度\h3.3.6讓產品經理到測試現場傾聽用戶的反饋，使產品經理能更多從用戶角度考慮產品銷售流程\h3.3.7通過同業站點的競爭分析和銷售數據使IT技術人員了解自己的工作給網絡銷售帶來了效益\h3.4用戶體驗的應用\h3.4.1使用人物角色和焦點小組了解目標用戶群需求\h3.4.2在產品開發的執行過程中，要分清輕重緩急\h3.4.3產品發布后，使用其他方法與UXOffice軟件發現問題\h3.4.4與用戶保持長期溝通，不斷完善銷售流程并挖掘用戶群需求\h3.5建議\h3.6總結\h第4章從以功能為中心到以人為中心\h4.1文檔流程管理\h4.2CORSA的建立\h4.3微軟Windows的到來\h4.4轉折點\h4.5專家的觀點\h4.6更進一步\h4.7試運行\h4.8標準化，標準化，標準化\h4.9顏色和按鈕之外：制度化\h4.10用戶成了推銷員\h4.11總結\h參考資源\h第5章高效的“以用戶為中心的端到端”產品開發流程\h5.1認識：用戶體驗對當前電信產品開發的戰略意義\h5.2困惑：用戶體驗的研究范疇\h5.2.1關注多終端、多業務用戶體驗\h5.2.2在產品開發過程中的系統和部門之間的合作\h5.3執行：如何進行“端到端”全流程基于用戶體驗的電信產品開發\h5.3.1以用戶為中心的產品開發流程再造\h5.3.2優化資源配置，建立用戶體驗專業團隊和用戶體驗實驗室\h5.3.3以全流程穿越測試為抓手，建立橫向協同聯動的端到端的用戶體驗測試模式\h5.3.4建立以用戶為中心的產品開發實踐的考核與保障機制\h5.3.5組織文化的宣傳貫徹，推動員工的以用戶為中心的觀念的轉變\h5.4效果：用戶體驗的好處\h5.5結論\h5.6總結\h第6章用戶體驗和敏捷開發\h6.1商業背景\h6.2開發環境\h6.2.1團隊組成\h6.2.2Scrum\h6.3在Scrum中實踐敏捷用戶體驗\h6.3.1用戶體驗實踐所需的支持\h6.3.2預先思考：敏捷軟件開發和用戶體驗的結合\h6.3.3敏捷用戶體驗方法\h6.4產品影響\h6.5總結\h參考資源\h第7章以用戶價值為依歸——把用戶綜合評價作為產品部門的考評指標\h7.1關于騰訊公司\h7.1.1騰訊公司和相關產品介紹\h7.1.2騰訊公司的經營理念\h7.2為什么要建立用戶體驗考評體系\h7.2.1為商業決策提供用戶的聲音\h7.2.2幫助產品持續健康發展\h7.2.3用戶體驗的考評需要成為一個體系\h7.3如何建立用戶體驗考評體系\h7.3.1基本流程\h7.3.2資料搜集方法\h7.3.3資料統計方法\h7.4如何運營用戶體驗考評體系\h7.4.1自上而下地推動\h7.4.2敏捷高效地實施\h7.4.3更有價值地反饋考評結果\h7.4.4持續地驗證并優化考評體系\h7.5用戶體驗考評體系價值重大、影響深遠\h7.6最后的思考\h7.7總結\h第8章重新設計MyYahoo！頁面：使用原型來促進溝通\h8.1重新設計產品\h8.2最初的設計過程和頭腦風暴\h8.3使用原型進行產品設計\h8.3.1概念證明型原型\h8.3.2特定功能原型\h8.3.3綜合原型\h8.4用原型來溝通\h8.5最后的想法\h8.6總結\h參考資源\h第9章界面設計模式：用戶的可持續定向\h9.1商業背景\h9.1.1產品\h9.1.2客戶\h9.1.3市場\h9.1.4組織\h9.2商業問題\h9.3制約和先決條件\h9.4開發背景\h9.4.1構建界面設計模式庫\h9.4.2確保利益相關者的參與\h9.4.3定義庫結構\h9.4.4識別界面設計模式\h9.4.5描述界面設計模式\h9.4.6審查界面設計模式\h9.4.7發布界面設計模式\h9.5使用界面設計模式\h9.5.1需求定義\h9.5.2需求分析\h9.5.3實現\h9.6具有說服力的事件\h9.7對產品產生的影響\h9.8建議\h9.9總結\h參考資源\h第10章快速測試體系\h10.1海爾為什么重視用戶體驗\h10.2海爾的用戶體驗設計流程\h10.3為什么快速研發對海爾很重要\h10.4如何進行快速測試\h10.4.1標準化的材料\h10.4.2利用外部資源\h10.5快速測試平臺應用的主要階段\h10.5.1概念測試\h10.5.2效果圖評估\h10.5.3模型接受度測試\h10.6帶來的影響\h10.7總結\h第11章設計思維：讓設計師以外的成員采用用戶體驗方法\h11.1設計思維\h11.1.1識別要解決的問題\h11.1.2尋找靈感\h11.1.3醞釀多種想法\h11.1.4生成原型\h11.1.5征求用戶反饋\h11.2設計思維的好處\h11.3商業背景\h11.4設計思維的推進\h11.4.1高層支持\h11.4.2激勵講座\h11.4.3工作坊\h11.4.4編程馬拉松\h11.4.5快速實驗\h11.5研發流程是如何改善的\h11.5.1加速研發流程\h11.5.2提高研發過程效率\h11.5.3讓工程師發揮更大的作用\h11.6設計思維對于用戶體驗的意義\h11.6.1設計的戰略意義\h11.6.2繼續設計職能\h11.6.3讓設計變得透明\h11.7設計思維對商業的意義\h11.7.1促進想法的形成\h11.7.2開辟新的市場\h11.7.3創建知識產權\h11.7.4縮短進入市場的時間\h11.7.5降低成本\h11.7.6提高商業利潤\h11.8如何在你的組織內開始設計思維\h11.8.1識別并重用組織內的設計人才\h11.8.2從小事開始\h11.8.3別光說不做\h11.9總結第1章協作的、創新的設計大綱：使用戶體驗設計成為公司認可、信賴的商業核心戰略性競爭力的重要工具彼得·L·菲利普斯（PeterL.Phillips）不同的人對設計有不同的理解。設計各式各樣，設計師也分很多種。例如，產品設計師、平面設計師、包裝設計師、用戶體驗（下文簡稱UX）設計師、用戶界面（下文簡稱UI）設計師、景觀設計師、花藝設計師、室內設計師、建筑師、甚至“設計”芯片電路的工程師，等等。因此，當我們說自己是設計師時，別人常常沒法確定我們究竟是哪種類型的設計師！什么是設計？在我看來，著名設計師保羅·蘭德（PaulRand）的回答堪稱極致。蘭德說：“設計是一門解決問題的學科?！睙o論哪個領域的設計，設計師們都是在用特定的知識和技術解決問題。通常，這些問題或多或少都會牽扯到某個具體的商業領域。依我30多年的專業平面設計師和設計經理的經驗，我發現新產品的失敗率高達30%~40%。這些產品為何失敗？原因可能很多。然而，據我所知，至少從某種角度上講，很多設計項目的失敗都是因為設計師或設計團隊不能充分理解他們需要用設計技巧去解決的問題而造成的。而其中最常見的情況就是，因為團隊根本沒有撰寫任何形式的設計大綱（designbrief），抑或大綱寫得太差而不能夠反映實際問題。那么為什么大家不用設計大綱呢？我最常聽到的借口就是撰寫大綱太費時和費錢。其實許多業務經理完全不懂怎樣寫設計大綱，或沒有類似的經驗，我猜這是設計大綱沒有普及的另一大原因。依我的經驗，設計方案被市場淘汰的另一個原因是：項目負責人和設計師之間缺乏戰略協作。通常人們只把設計當做發布新產品過程中必須附帶的一項支持性工序。既然設計是門解決問題的學科，那么如果設計師連要解決的問題是什么都不能清楚表述出來，那么設計方案失敗的可能性將大大增加。為了在設計過程開始之前就明確問題，項目負責人和設計師必須在戰略層面緊密合作，并肩作戰。本章不在于介紹某個具體的UX設計項目或問題，而是介紹一些技巧，幫助團隊去識別并清楚表述出要解決的商業問題。這需要UX設計部門與項目管理團隊建立戰略伙伴關系，彼此認可、彼此信任。迎合商業需求、建立戰略伙伴關系的最佳工具就是一份協作創新的設計大綱。1.1到底什么是設計大綱什么是設計大綱，在我的職業生涯中，我聽到過許多不同的叫法。許多人稱之為創意大綱（creativebrief），其他人更習慣像營銷大綱（marketingbrief）、項目大綱（projectbrief）、任務標簽（jobticket）的叫法，還有我最喜歡的叫法——創新大綱（innovationbrief）。但無論哪種叫法，都是指設計項目的書面描述。我最不喜歡的叫法是任務標簽。任務標簽不過是列出了項目名稱、截止日期、預算、需求方（個人或團隊）和其他一些戰術層面的數據，一般不超過一頁。我認為在實際的設計階段，這些任務標簽可以說是作用甚微。正如我前面所說的，我十分認可創新大綱的叫法，這種叫法在歐洲很常見。我喜歡它所蘊含的深意。但很遺憾，大多數公司并不認為設計是一個創新的過程，更算不上商業層面的戰略過程，他們認為設計不過是一項支持性的服務工作罷了。1.2設計大綱模板設計大綱模板有很多，沒有唯一的標準，也無優劣之別。我看過通篇是一段接一段的描述的優秀設計大綱；也看過以列表形式一項項列出的設計大綱，有些也做得十分出彩。最近越來越多的人使用一種電腦程序，需求方只需回答一些關鍵問題，將答案填入空白欄，電腦即可自動生成一份設計大綱。另外，還有一些很優秀的設計大綱是由PPT寫成的。你最終采用的模板很大程度上取決于你具體從事的設計類型，以及你的公司最適合的風格。當然，無論應用哪種模板，清晰易讀和便于跟蹤查詢才是關鍵。其次，大綱必須涵蓋流程中每位利益方所需的所有信息和數據。最后，設計大綱必須既有紙質版又有在線版。過去幾年里，我碰到的設計師似乎都認電腦程序自動生成的模板最具挑戰性。但諷刺的是，過半的設計師都用了這種電腦生成的模板！其實并不是這些模板設計得太差，而是人們沒有用合適的方法去使用這些模板。設計師們常抱怨需求方要不就是留了太多空白欄沒有填寫，要不就是填寫的信息不全。舉個典型的例子，問題欄是“目標用戶”，而需求方只填了“客戶”。這和沒填簡直沒什么兩樣！找到最適合組織的模板的重要性不容忽視。多花點時間，多嘗試幾次，建立一套滿足公司上下實際需求的模板。總之，最后你要形成一套滿足自身具體需求的模板。對我來說，最適合我的模板首先是陳述性模板，其次是列表模板。1.3設計大綱該寫多長簡答說來，設計大綱的長度應按需而定。許多參與我的設計大綱工作坊的人都跟我說，總是有人不斷地要求他們把設計大綱寫得越短越好。但是我們不應該以短為目標，而是需要讓設計大綱盡可能完整、實用。大綱最終長度是依具體項目的需要和復雜程度而定的。1.4什么時候需要設計大綱每個設計項目都需要設計大綱嗎？當然不是！那些例行項目或是已經開始的設計項目并不需要一份正式的設計大綱。但各個設計類別中，包括UX設計，大部分項目必須有一份書面的設計大綱。請注意，這里所說的設計大綱不是口頭的，而是書面的！我最常聽到的沒寫正式的項目設計大綱的借口就是項目時間太緊，來不及寫。第二大理由是書面的設計大綱不利于發揮創造力。我不這么認為，我相信我所推崇的這種設計大綱并不會扼殺創造性，反而會增強創造性。說得更明白點，一些重大項目如果只有口頭的設計大綱，項目時間將會大大延長。口頭的大綱常常會帶給團隊誤解、不良的情緒、意見的分歧和嚴重的挫敗感，最后的設計方案也總是不能體現真正的水平。我總聽到一些設計師和設計部門經理抱怨：“他們不理解我?！薄八麄兘o的時間不夠長?！薄八麄兘o的錢不夠多?！薄八麄儾蛔屛野l揮創造力?！薄八麄儾焕斫釻X設計流程！”我知道這是常有的事，但即使真實情況確實如此，我的回答也是錯不在他們，而是我們自己。如果設計師們得不到定位商業問題和解決問題所需的戰略信息，那么應該感到慚愧的是我們自己。如果“他們”不理解，是因為我們做得不夠好。我們沒能有效地溝通、表達我們的需求，僅此而已。設計行業的人要學會變得積極主動，從決策人的角度出發，讓別人發現設計的價值，并肯定其具有核心商業競爭力的戰略地位。在開始學習編寫完美的設計大綱之前，我們需要理解怎樣將設計理解為一種商務戰略方面的資源，而非一項支持服務。1.5設計大綱由誰來寫一旦確立了設計部門要解決的具體商業需求，確定了將要執行這個項目的設計團隊，就該馬上展開設計大綱的編寫工作。第一步就是要確定誰將是項目負責人。負責人也是項目的最終責問人。即項目成功了功歸于誰，失敗了由誰來承擔責任。我堅定地認為每個項目都應該由兩個人共同負責。一位代表有設計需求的業務團隊，另一位代表要解決這一需求的設計團隊。做項目的時候，雙方都是平等的合作伙伴。他們之間是戰略意義上的商業合作伙伴關系，而不是客戶和服務商之間的關系。設計師和設計部門經理必須改變思維定勢，將角色定位從服務商轉向戰略意義上平等的商業伙伴。如果項目出了差錯，設計師也要大膽站出來承擔責任。1.5.1是客戶？還是合作伙伴我認識的大多數設計師和設計部門經理總是過度使用客戶這個詞?！拔业目蛻粝胍@樣。”“我的客戶很難合作?！薄拔业目蛻舨蛔屛以琰c參與?！薄拔业目蛻舨欢O計?！鳖l繁地使用客戶這個詞在一定程度上反映出了我們處理項目的方式。其實稱對方為“客戶”的同時，我們也等于在說，設計不是我們做主，而是他們。為什么不以合作伙伴相稱呢？為什么不分攤責任呢？我自己在做咨詢項目時，總是盡量避免用客戶這個詞，我一般都說我和別人正合作一個項目。嚴格來講，這些人確實是我的客戶，但我不想只把他們當做客戶；我也不希望他們只當我是服務方；我想成為他們的合作伙伴。設計行業的人應該和我們所謂的客戶成為平等的合作伙伴，承擔相同的責任。他們需要我們的專業技術，向我們求助，僅此而已。如果我們接受了這一思維的轉變，事情或許會變得更順利，合作將擦出新的火花，好的設計也會接踵而至。這種工作關系還會帶給設計師更多的自主性。1.5.2共同負責我認為如果只是讓有商業需求的一方撰寫好設計大綱，然后交給設計方執行，這么做沒有意義。同樣，如果單由設計方撰寫設計大綱，而沒有將合作伙伴掌握的具有商業價值的重要信息納入考慮，這么做也沒有意義。因此，許多年前我定了一個規矩，設計大綱的撰寫至少得有兩人參與：一方代表商業需求方；另一方代表設計方。當然，有時也有超過兩個人負責撰寫設計大綱的情況。中間可能有第三方，這種情況通常在有商業聯盟參與的項目中比較常見。但是大多數情況下，撰寫設計大綱兩個人就足夠了。盡管我強烈主張設計大綱的撰寫應由多人共同負責，但我并不提倡成立一個委員會團隊來撰寫。一旦太多人認為自己負責設計大綱的實際開發和撰寫，而且都去扮演設計師的角色，一切都將亂了套。一個設計大綱團隊可以有多個成員，但“負責人”只應有兩位，或者三位。設計大綱團隊成員的職責是提供信息，并審核通過設計大綱，并不一定需要實際參與大綱的撰寫。1.5.3共同負責人應來自哪個級別設計大綱需要什么級別的負責人，這取決于項目的大小以及項目對公司的重要性。新推出的、突破性的產品和服務通常是由資深設計執行官、設計部門經理或設計總監負責。此外，現有產品的一些改進工作一般由中層市場專員和資深設計師來共同承擔。其實，負責人所屬的管理層高低并不太影響設計大綱的開發，開發流程還是一樣的。最后，我要說說客戶經理、項目經理。許多公司都會雇客戶經理，也就是我們常說的“西裝革履的人”。這些人可否成為共同負責人呢？我認為客戶經理也可以共同負責設計大綱的撰寫，但是有個前提，客戶經理必須十分了解設計、設計流程以及設計師需要的是什么信息。過去我接觸到許多客戶經理，他們銷售做得很棒，也是很出色的項目經理。但遺憾的是，他們對設計知之甚少。在我看來，如果在設計師和客戶/合作伙伴之間安排這樣一個角色，反而是一個阻礙，設計師和客戶之間有了阻隔，不利于設計出一套好的方案。設計師必須和設計方案的需求方直接接觸。1.6設計是一門解決問題的學科那些到達一定境界的設計大師都知道，設計是一個解決問題的學科。設計與藝術的區別在于：藝術家專注于對事物的個人解讀，而設計所關注的是為一個已知問題設計一套解決方案。因此，設計師必須明確確切的商業問題，并提出相應的設計方案。這也是為什么設計師和商業伙伴必須一起合作開發出一套解決實際問題的設計大綱。一個真正有效的設計方案必須能夠解決問題。這就要求：首先，問題需要被清晰地定義；另外，問題的解決方案所需要達成的商業目標也需要被清楚表述。只有當大家對實際的商業問題和其目標都有了清晰的認識之時，相應的設計方案才可能被提出。1.7大綱的協作撰寫流程大綱撰寫流程的第一步是：共同負責人一起確定設計項目要完成的所有商業目標，并描述具體細節。這一步要回答的關鍵問題是：我們究竟要解決什么樣的商業問題？我們到底想做出什么？下一步是討論設計項目的商業動機，即目標背后的實際需求。最后，共同負責人要用文字清楚地將設計活動完成后需實現的所有效果記錄下來。1.8設計大綱的主要內容：通向成功的任務清單共同負責人確定并清楚記錄了商業內容、市場需求和項目預期后，就可以接著撰寫大綱了。大綱的內容包括：·項目背景和項目描述·類別/行業綜述·目標用戶綜述·公司作品集·商業目標和UX設計策略·項目階段：規模、時間表、預算·研究數據·附錄（按需而定）下面我簡單總結了每個部分的內容。項目背景和項目描述第一部分包涵了項目背景介紹和項目市場環境描述。類別/行業綜述第二部分是關于項目當前所屬的行業劃分，通常包含了市場競爭，行業趨勢，品牌和旗下品牌的定位、定價，產品和服務的推廣策略、營銷策略等信息。目標用戶綜述第三部分通常是對產品和服務的目標用戶進行全面綜合的討論。特別是要說明你希望哪些用戶會對設計解決方案感興趣，會如何使用。公司作品集這一部分需要理清公司所有的產品或它所提供的所有服務。這個項目和公司其他產品或服務有什么關聯？該設計項目如何體現了公司的品牌定位？商業目標和UX設計策略這一塊或許是整個設計大綱中最關鍵的部分。它需要設計師根據具體的商業目標制定出相應的設計方案開發策略。就UX設計案例而言，有一個撰寫設計大綱的技巧很有效：共同負責人創建一個如表1-1所示的三欄表格，許多團隊試過后都覺得十分奏效。第一欄的標題是“商業問題”。在這一標題下面列出具體的商業目標。第二欄的標題是“UX相關問題”，列出具體的UX問題。最后，第三欄的標題是“UX設計策略”。這一欄應該由UX設計團隊來寫，所列出的策略需要共同負責人達成共識。表1-1移動電話公司商業視角下的UX案例這個方法優點很多。最重要的是，它的確有助于加速整個撰寫流程。此外，它幾乎完全避免了在整個流程中可能出現的許多誤解。有了這種列表模板，所有的利益方都能了解要解決的問題是什么以及UX團隊所做出的應對策略。這樣，每個人都能對項目有一定的了解。項目階段：范圍、時間表、預算每個大綱都得涉及一些具體策略，通常我們稱之為“項目階段”，或項目時間表。列出設計流程的每個階段。每個階段都要標明這一階段的持續時間以及所需開支。還要注明可能需要目標用戶參與的概念測試?？紤]范圍要涵蓋到所有可能會對最終產品產生影響的輔助項，例如，包裝、使用說明書、疑難排解指南等。這一部分需要包含設計流程中非常重要的三個階段，但卻常常被忽略。第一個階段是最后的審批階段。你要列出掌握設計項目最終決定權人的具體信息。第二個階段常被忽略，是執行階段。一旦設計通過，就需要投入大量的時間和金錢在市場上推動設計方案執行。最后一個階段是評估階段。如何判定產品是否成功？判定成功與失敗的標準又是什么？誰來評估？評估該持續多長？研究數據你可能還需要總結一些關鍵的研究數據，用來說明為什么UX設計團隊最好從一開始就介入項目。附錄附錄通常包含了競爭對手的產品照片或草圖、研究數據報告和配色方案推薦等項。1.9協作設計大綱的商業影響目前的研究表明，在過去的六年里，最成功的產品都是從撰寫一份全面綜合的設計大綱開始的。前面提到的“沒有時間撰寫設計大綱”的障礙并不存在。如果合作撰寫一份大綱需要6到8個小時，那么設計執行階段省下的時間至少是它的10倍。當你對一個個擺在面前的有待解決的商業問題都進行過全面透徹的分析時，你設計出的產品通常能在市場上獲得更大的成功。1.9.1成為戰略合作伙伴設計行業的人如何成為撰寫設計大綱的共同負責人，并享有平等的地位呢？首先，我們作為核心商業競爭力的戰略地位必須得到肯定。我設計了一個模型，用來解釋成為這種戰略伙伴需要走哪幾步？模型圖1-1很好地展示了如何一步步成為戰略伙伴，這對于那些想要加深公司對設計的認識，加強設計在公司中的影響力的設計師和設計部門經理而言，十分奏效。要按這個模型一步步順利進行，設計大綱是關鍵的工具。圖1-1模型你的價值這是模型中的第一步，也是最重要的一步。如果連你自己都不知道自己的價值所在和設計的價值所在，其他人就更不知道了。我們大都自認為很清楚自己的價值，但是清楚與有效溝通完全是兩碼事。而且，我們自認為體現自身價值的東西，在別人看來或許意義并不大。對別人來說，我們在短時間內按時完成我們的工作是理所當然的。另外，預算最好也不要超。要有創意？那當然了，不然他們為什么雇你！一個人應付多個項目？他們不也天天如此。這樣的問題還有很多。在說明自己的價值的時候，設計師們通常會列出他們每天做了哪些“策略層面”的事。但我看到的沒幾個能真正達到“戰略層面”。要想讓自己的價值得到肯定，在項目中享有平等的合作伙伴地位，核心商業競爭力的戰略地位得到認可，設計師必須學會用商業的行話解釋自己在做的東西會帶來的商業收益。舉個例子，假如你希望成為撰寫設計大綱的共同負責人和平等的合作伙伴，你就必須有效地溝通，讓別人知道你在從戰略層面考慮如何通過設計解決具體的商業問題。但如果你只關注視覺效果和技術層面的東西，沒有人會把你當成真正的合作伙伴。你只會是一個“裝修工”，或一項“設計服務提供者”。我并不是說視覺效果和技術層面不重要，只是你不能只關注這些?！澳愕膬r值”中的“你”具體指誰？這個模型中牽扯到兩個“你”。一個是個人的你，那個想成為平等的合作伙伴的你；另一個是集體的你，代表整個UX設計部門，你希望設計部門的價值得到認可，成為組織的重要部分，你也希望獲得設計過程負責人所應得的重視和信任。從一個測試開始如果你想要凸顯自己在公司的價值，我推薦一個十分奏效的測試。你可以自己進行測試，看看自己能給公司帶來多少附加值；你也可以和設計團隊一起進行測試，弄清楚設計是如何給公司帶來附加值的。無論哪種形式，測試的技巧都是一樣的。首先，列出所有你認為你或者設計能給公司帶來價值的原因。寫下所有你能想到的點。這個時候不要考慮用詞，甚至不用考慮這是否和答案相關。只要想到了，就寫下來。一般來說，你很快就能寫出一長串列表。這時你一般會很有成就感。我看到好多人寫完之后盯著那一長串列表，自豪地說：“哇，原來我擅長這么多東西！”這時要把列表放到一邊。過一段時間，也就是一兩天后，再拿出來看看，并一項項地過一遍?？吹矫恳豁?，都問問自己：“不搞設計的商業人士真的會在乎這個嗎？”如果答案是“否”，那么就把這項劃掉。我和各種團隊做過上百次這樣的測試。這里我舉出一些被我們劃掉的例子，為了說明問題，這些例子可能有點極端?！凹词苟鄠€項目纏身，我也能記清楚許多細節?！薄拔覍θ撕苡押?，容易相處?！薄拔姨貏e擅長使用研究數據。”這些都是優點，但對于商業價值來講毫無意義。我希望第一遍你能寫下所有你能想到的點，因為當你劃掉那些不相關的點時，你會有一個直觀的印象，你就能記住哪些類型的事雖然你們每天都在討論，卻不容易引起設計之外的人的興趣。當初看到這一長串列表的成就感這時候大概也就沒有了。你的列表要比你預期的短得多。下一步要重新列個表。但這次不要草草記下所有想到的點，把重心放在那些不搞設計的人會認為是附加值的點上，同時也要注意你描述它們時的用詞。這個步驟花的時間要比第一輪多得多。但它的結果也同樣令人期待。這次的列表相對較短，但它所包含的信息卻更多了，因為這部分要說明設計到底如何增加商業的附加值。切記，這時不能從美學角度考慮，而是得從商業角度出發。思考設計能為商業做什么？我在第二次列出的列表上看過一些很有說服力的點，措辭可能不盡相同，但意思大體是：“我們可以縮短銷售周期。”“我們可以讓公司的唱片或服務在視覺上從混亂的市場中脫穎而出?！薄拔覀儎撛炝艘粋€強勁的競爭優勢。”“我們通過視覺效果和體驗方式凸顯了公司的商業戰略?！边@些才會令那些非設計出身的資深業務經理們打起精神，才能引起他們的注意?！拔覀兊娜蝿帐峭ㄟ^視覺效果和用戶體驗凸顯董事會和股東們通過的全盤商業戰略決策。”這是我們看到的另一個十分有說服力而且又新穎的表述。這句話聽起來一點也不像是出自技術服務人員之口，更像是戰略商業團隊中的一員說出的話。你應該成為這種人。一旦發現了自身的價值所在，你就應該把自己的想法融入到你所做的每件事中。一些團隊做了這個測試后，制定了一套“設計哲學”。將這些說服力強、從商業角度出發的戰略性觀點應用到備忘錄、演講、會議、日常對話和設計大綱中去。你可能常會碰到這種情況：開會時，公司里的其他與會人員并不了解你的工作。這在所難免，他們會問你是做什么的。我在課上做了個實驗，我讓學生告訴我“設計師是干什么的”。從他們嘴里蹦出的第一個詞幾乎都是“嗯？”，接下來就是像“我做設計是為了獲得更好的用戶體驗（或其他什么）”之類的回答。然后他們就停了下來，不知道該從哪方面回答這個問題。做完這個測試后，你就該能給出一長串答案，這些答案在你頭腦里已經根深蒂固了，也能引起發問人的注意。內心深處，你希望他們能夠意識到設計對于商業的重要性，你希望他們說“真沒想到，我原來還以為你們只是干技術活，我們應該多聊聊！”許多做人力資源的人都認為，面試時的頭兩分鐘對于整個面試的結果至關重要，他們把這一訣竅叫做“兩分鐘效應”。和人交流時，你必須學會言簡意賅，并且得讓人信服，讓別人看到你提出的東西的獨到之處。弄清作為一名設計專業人士真正的附加值是什么之后，你應該也有能力學會怎樣在兩分鐘或更短的時間內向別人說清你的價值。這需要一些練習，但若想改變商業圈對設計的認識，有效溝通是很重要的一步。要想在商業圈里得到真正的重視，首先，你必須知道自己的價值是什么（我們都是有價值的！），另外，你也必須會用商業的行話簡潔、清晰、迅速地說明你的價值。如果連你自己都不清楚你的價值在哪，你的優勢在哪，其他人就更不知道了。在進行模型中描述的其他步驟之前，先做一做這個測試。這個測試也很適合作為UX設計團隊會議上的一項活動而提上日程。團隊里的每位成員對自身價值的理解要保持一致。這比那種只讓設計師一個接一個地進行情況匯報的枯燥會議要好多了。認清UX設計的商業角色“認清UX設計的商業角色”也可以表述為“UX設計在商業中的角色”。無論哪種說法，每位設計師或設計部門經理做商業設計項目時都必須了解怎樣通過好的設計增加產品在市場上的商業價值。要牢記，設計是一門解決問題的學科。如果你接的設計項目涉及某個商業領域，那么你想通過設計解決的問題就是一個業務問題。那么UX設計能在多大程度上解決商業問題，怎么解決？我的回答是：“通過設計解決商業問題的途徑比大多數人預期的要多！”我有一個密友，同時也是我的同事，很直白地跟我：說設計在最終處理實際商業問題方面真的起不了太大作用。他是一名出色的商業戰略分析家，特別擅長金融領域。他堅持認為之所以需要設計是因為它是一個載體，提供一種環境，用來承載公司產品或服務的相關信息。在商業圈里，持有相同觀點的人很多，確切地說應該是比比皆是。當然也有一些公司的成功是完全取決于設計，例如蘋果、沃達豐（Vodafone）和伊萊克斯（Electrolux）。從事設計行業的人去有義務去改變人們的這種看法。坦白講，我認為過去幾年我們在這方面做得很差。要想清晰地向別人說明設計的角色和價值，首先，我們自己必須先了解設計在商業中扮演的角色。你所處的公司或合作客戶的公司面臨著什么樣的商業問題？設想一下：“是什么讓首席執行官輾轉反側？他最棘手的商業問題是什么？”然后再反問自己：“有效的UX設計在解決問題的過程中如何發揮作用？”建立互利關系在公司內部建立互利關系是設計部門和設計部門經理成為戰略伙伴的關鍵環節，但設計部門卻最常忽視它。我常常遇到這種情況，設計師和設計部門經理們不是很樂意和其他部門打交道，在商業問題上也不是很積極。其實，設計部門經理應該多與商業部門的負責人聯系，建立同盟關系，成為他們的合作伙伴，給予UX設計方面的幫助；成為他們的盟友，先耐心傾聽，進而給出創造性意見，幫助部門負責人完成商業目標。這才是真正的互利關系。原來我在公司就職的時候，常常打電話給某個部門的經理，介紹自己并表達自己愿意出席他們以后的部門會議，說明設計如何在他們從事的具體商業領域發揮作用。很多人根本意識不到他們的工作常常需要設計。他們對設計的看法有了很大的轉變。在員工會議上，我會花10到15分鐘去闡述設計如何在他們的工作中發揮作用，這時如果他們有需要的話，我會就他們遇到的和設計有關的難題給一些建議。我并不親自設計去解決他們的問題，而是幫助他們利用其他資源更好地解決問題。這么做有幾個優點。1）讓很多人明白了日常生活中處處有設計。2）提升了設計部門的專業技能在公司中的知名度。3）讓設計部門的專業技能獲得廣泛認可。4）我能夠獲得一手信息，了解各部門最關心的商業問題是什么。最后，我和公司各部門都建立了同盟關系，可以進一步發展為互利關系，這對設計部門以后的項目絕對大有裨益。例如，建立了這種互利關系后，撰寫設計大綱時再列出所有的利益方就簡單多了。我認為這是在公司內部建立互利關系的最好溝通方式。當你在某團隊的員工會議上做這件事時，可以先觀察一下哪些人可能會成為設計的真正擁護者，然后重點和這樣的一兩個人發展關系。我在公司建立的最強的聯盟關系之一，是與法務部門達成的。當今，似乎我們的所有設計工作都會涉及法務需要考慮的方面。與法務部門建立互利關系，比每次都面臨枯燥的“法務審核”要好多了吧。建立牢靠、良好的關系并非易事。這需要時間，還需要你處事圓滑，懂得傾聽，要表現出你真的很關心他們團隊的需求，而不是只顧著自己的需求。總之，設計部門經理若想成為戰略上的商業伙伴，成為公司重要的財富，獲得尊重和信任，就要花心思、花時間去經營這種關系，而不要老給人一種“格格不入”的感覺。沒有這種部門間的互利關系，你永遠也不可能成為真正意義上的核心戰略合作伙伴。你只能繼續扮演“服務提供者”的角色。執行“和……工作”的高效流程注意標題的用詞是“和……工作”。它和“為……工作”恰恰相反。我們說的是戰略伙伴，而不是只提供支持服務者。你不只是個的士司機，把你的“客戶”帶到任何他們想去的地方就可以了。你應該成為他們的交通顧問，根據乘客的需求、時間和預算為他們推薦最佳路線。和他人工作，與為他人工作是截然不同的。連很多設計師和設計部門經理都認為自己只是服務提供者，算不上是商業戰略伙伴。相信我，如果連你自己都這么想，那么其他人也會這么想。另外，如果你的行為也只停留在服務提供者的水平上，那么你和設計部門在公司中的地位也只能如此了。上文提到的幾個要素都是這一角色轉變的基礎。此刻，你應該已經明白設計對公司的真正價值所在，并學會用商業語言表達出來。你也做過了測試，充分理解了設計在商業中的角色定位，即核心商業戰略的視覺表達。你還主動出擊，找到了公司中主要利益方，并和他們建立了互助互利的關系?，F在是時候擺脫服務者的枷鎖，成為真正意義上的合作伙伴了。一些人很懂得怎樣和人打交道，怎樣與人合作，怎樣和同事相處，但對有些人而言，這可能確實是一個很大的障礙。這需要你對你的專業技術、所學的知識及其商業附加值抱有與生俱來的堅定信念。就算我們是專業的UX設計師，但我們的商業眼光是被認可的嗎？看看我們周圍在這方面做得不錯的人。律師、醫生、CEO、市場營銷人員、工程師，幾乎所有的職業人員都認識到自己的專業技術是各自的立身之本。嚴格來講，從字典的定義看來，這些人也有自己的客戶，但他們并沒有表現出低人一等，把客戶捧為自己的“主人”。他們清楚自己提供的“服務”會影響事情的成敗。從事UX設計的專業人士也同樣，如果你只是一個服務提供者，那么在市場環境下，你的價值就不可能得到真正的認可。人們會看重那些有突出作為的人。當然，這與設計大綱有直接關系。“目標用戶綜述”這一部分要將世界各地所有用戶的需求清楚地表述出來。商業目標和UX設計策略這一部分要分別列出所有的區域性商業目標，并根據各個區域性目標制定出相應的具體設計策略。為了防止設計走偏，你必須找到不同國家的用戶代表，把他們列入主要利益方這一部分，另外在設計大綱的整個撰寫過程中也一定要向他們咨詢意見。設計部門經理必須盡全力調查各種類型的用戶，學會如何開發出滿足各類用戶需求的有效設計解決方案，處理全球性的商業項目時更是如此。我強烈建議設計師和設計部門經理多參加全國性、國際性的銷售會議，以及展銷會這樣的活動。盡管這些活動的主題本身看起來和設計并沒有直接聯系，但他們卻是設計專業人士直接獲取商業需求的絕佳機會。兩耳不聞窗外事、一心只做設計的時代早就過去。做設計的人要走出設計工作室，看看世界的變化。設計專業人士不僅要主動傾聽公司內部主要利益相關者的需求，也要傾聽各類目標用戶的需求，給他們提供有效的設計解決方案。光靠坐在小隔間里埋頭苦干是不可能設計出優秀的設計方案的。因為要和那些從未謀面、從沒交談過的人合作，給他們做設計，這談何容易。1.9.2認可和信賴若想作為業務戰略伙伴的地位被逐漸認可，你需要做到以下幾點：充分意識到你個人和設計部門給公司帶來的附加價值；理解并能夠清晰地表達設計在業務中扮演的角色；能夠建立互利關系，注意是“相互”的；學會與他人共事（不是為他人工作）的技巧。有了知識，才會理解。有了理解，才有欣賞和認可。有了認可，才有信賴。首先，人們得知道一些相關知識，了解設計的附加價值。只有了解了這些之后，他們才懂得欣賞出色的設計。當你的設計方案真正解決了項目的商業需求，認可也就隨之而來。一旦你得到了認可，獲得信賴也只是時間問題了。我們已經反復說過，之所以這么多設計師抱怨時間不夠，預算不足，參與項目的時間點太晚，不被欣賞，不被理解，是因為他們的商業能力從一開始就不被信任。別忘了，無論營利性組織還是非營利性組織都是為了賺錢。非營利性組織也必須賺錢來抵扣支出，否則它也堅持不了多久。營利性組織就更是如此了。在商業人士眼里，設計的首要任務就是達成商業目標。做設計的人要讓業務人士知道這也是我們的目標。我們得讓我們的商業合作伙伴知道，設計的作用遠不止“美觀精致”而已。設計方案的最終決定權幾乎都是掌握在非設計行業的人手里。這個現象很值得思考。為什么那些對設計不甚理解的人卻掌握著設計的最終決定權？他們既沒有受過相關的設計訓練，也沒有設計的專業技能！因為設計師的商業評估能力不被信任。大多數非設計行業的人都會承認在設計技巧和元素方面專業設計師確實比他們懂得多。他們只是不放心讓設計師做最終的評估，去判斷設計解決方案是否能夠解決實際商業需求。只有獲得了非設計行業的合作伙伴的認可與信賴，設計師才能夠成為享有平等地位的共同負責人，設計團隊在撰寫設計大綱時才能享受戰略合作伙伴的平等待遇。我設計的這套模型已經成功地幫助了許多設計團隊贏得認可與信賴。當然，我自己也很受用。協作的設計大綱是實現這套模型的精髓的最佳途徑、最佳工具。嘗試一下吧！1.10總結·設計大綱如何幫助測量設計項目的投資回報率？一份好的設計大綱會對設計要解決的問題、要實現的核心商業目標、設計方案的預期執行結果進行透徹分析。這些因素決定了評估設計項目的資金投放標準?！と绾闻袛嘈马椖渴欠裾娴男枰O計大綱？如果設計項目規模較小，只是已有產品的一兩個小修正，那么并不一定需要設計大綱。但如果項目需要開發出一套全新的設計方案，那么設計大綱將發揮重要作用?！槭裁匆屧O計項目負責人和設計師共同撰寫設計大綱？因為通過這種合作方式，雙方能夠各取所長，一起做好項目。而且雙方在合作撰寫設計大綱時，就已經幾乎將所有可能出現的問題擺在臺面上了，并且提前妥善處理了，這樣在執行階段就可以節省大量的時間?！ぴO計大綱太長，我們一直都沒時間寫，有沒有什么其他捷徑？說句實話，并沒有捷徑。對那些從一開始就備受重視的項目而言，是否撰寫設計大綱對項目的最終成敗至關重要。設計項目執行階段省下的時間要比項目開始時撰寫大綱所花的時間多得多。·為什么要讓目標用戶測試設計概念？公司里參與設計的人對項目太熟悉，不能夠真正客觀地判斷哪個設計概念的效果更好。你是在為目標用戶做設計，只有他們才能真正讓你知道——你的設計方案是否適合他們?！绦许椖繒r，設計大綱要用到什么時候？什么時候可以不再需要它？項目的整個流程都需要設計大綱。最后三個階段包括：1）決定設計解決方案能否通過的展示階段；2）最終設計解決方案的執行規劃階段；3）設計解決方案面世后的評估階段。項目完成后，最后的評估階段可能還要持續一些時間。第2章用戶體驗制度化，成就企業AndreasHauser，SAP公司過去十年里，客戶期望和軟件開發流程都發生了改變。許多公司已經意識到有必要為客戶提供更好的服務，特別是為最終用戶，因為購買企業管理軟件的決策者已經不再是首席信息官（chiefinformationofficer，CIO），而是該軟件的直接使用部門。能否成功賣出產品，用戶體驗在其中的作用變得越發重要。但與此同時，許多公司的軟件開發流程仍是一成不變。公司的技術部門依然脫離最終用戶，憑自己的意愿對所開發產品的特性與功能進行取舍。幾年前，SAP決定要開發一套開創性的商業解決方案，并希望能因此大幅度提高方案在中小型企業市場的滲透率。為了開發出這么一套推陳出新的解決方案，SAP從技術、流程和組織方面徹底地改變了此前開發應用程序的常規路數（見圖2-1）。SAP從一開始就把用戶體驗作為優先考慮的重點，并希望將體驗作為產品的特色和競爭優勢。圖2-1挑戰為了開發這個方案，我們必須搭建一個全新的技術平臺，以在此之上開發一些開放靈活的企業管理應用。我們還搭建了一套純服務導向型架構（service-orientedarchitecture，SOA），并將UI模式順利地融入到開發工具中。我們也徹底改變了先前的開發流程。我們的主要目標是提供卓越的用戶體驗（UserExperience，UX），為此我們采用了一套外部驅動（outside-indriven）的迭代開發流程。在組織上下強制推行以用戶為中心的設計（User-CenteredDesign，UCD）。為了評估我們定下的用戶體驗目標的完成情況，我們開發了一套UX關鍵績效指標（keyperformanceindicator，KPI），并將產品每個版本的KPI匯報給管理層。除了新技術、新開發流程，我們還建立了全新的組織，它迅速成長壯大，如今已是一個大型的全球性組織。建立全新組織的原因是，我們的技術和企業管理應用程序都必須從零開始搭建。我們讓人才在組織中平衡地分布，來自不同地區，有著不同文化背景的員工作為一個團隊共同工作。這個新組織的組織結構不同于其他的SAP部門。它分為解決方案管理（SolutionManagement）部門和開發部門。解決方案管理部門（其他公司也叫產品管理部門）負責確定市場需求及詳盡的產品定義。UX設計師負責交互設計和協助執行用戶研究，如現場觀察（sitevisit）和用戶界面（UserInterface，UI）驗證。開發部門則負責執行解決方案。要在這樣一個大型的全球性組織中，大規模地執行UCD設計流程是一個很大的挑戰。即使一個小團隊也需要大量的跨地域協作，有些團隊分散在三個以上不同的地方，成員必須應對不同步的溝通、各種時差和文化差異等問題。我們必須學會聽懂各種“蹩腳的英語”，學會如何組織網絡設計會議。當時我們面臨的最大挑戰是在我們開始設計解決方案的時候并沒有現成可用的技術。我們需要在技術架構還只停留在理論階段的時候，就開始挖掘市場的需求和用戶需求。因為我們不可能空等上一兩年，等技術可用了之后才開始。如果那樣做，產品開發的持續時間就太長了。隨著組織不斷壯大，我們需要不斷地向不同背景的人（開發人員和解決方案經理）說明用戶體驗的價值，這也是一個不小的挑戰。開發人員往往只關注產品特性與功能的執行。解決方案經理一般都有市場研究的背景，但對用戶研究仍不甚了解。可用性專業人員雖然深知用戶體驗的價值，但在外人看來他們卻更接近藝術家。我們必須想辦法改變這種觀點，讓組織明確了解到用戶體驗的價值，并欣然接受。這一章我會舉些例子，說明我們是如何一步步地讓用戶體驗在組織內制度化的。對我個人而言，這也是一段非凡的旅程。我們經歷了許多起起落落，但卻也樂在其中，我們特別享受和用戶體驗團隊一起工作的時間，他們充滿了朝氣活力，創意十足。這一章，我想和大家分享過去幾年里我的這段旅程，講述我是如何擴大用戶體驗對開發部門和產品的影響力的。那時我們確實面臨著很大的挑戰，因為據我所知，之前沒有任何一家軟件公司做過如此規模的事。我們沒有可借鑒的經驗，只能靠自己摸索，有時候我們只能通過嘗試才能分辨什么是有用的，什么是沒用的。當然，這段經歷讓我積累了許多經驗。它們包括：·如何在全球性的組織中建立并執行以用戶體驗為中心的設計流程?！と绾握f服組織與同事搭上UCD設計的浪潮?！と绾螖U大對UI技術部門的影響力，讓他們更關注用戶體驗需求。我在這個項目中推薦的大部分UX實踐對你和你的公司應該會有所幫助。但有些實踐更適合在流程更復雜的大型公司和全球性組織中執行。你可以聽取一些我們的建議，試著在你的公司中執行。你會知道哪些是有用的，哪些需要根據自己的實際情況做調整。2.1SAP是誰SAP是歐洲最大的軟件公司，擁有53000名員工。在全球120多個國家，有超過10.9萬個公司都在使用SAP軟件。每天都有逾3500萬人在使用SAP軟件。SAP在行業內觸及之深，覆蓋面之廣，已讓它成為行業中的佼佼者。過去35年中，SAP一直致力于幫助其他公司成為各自行業的領軍人。在與世界各地的合作伙伴和客戶打交道的過程中積累的大量行業經驗，讓SAP能夠準確洞察企業需求，幫助他們解決問題，更好地運營企業。在這些方面很少有其他公司可以與SAP媲美。2.2什么是SAPBusinessByDesignSAPBusinessByDesign是SAP新推出的按需配置的企業管理解決方案，主要面向中小型企業。這一解決方案因其存在很多創新之處，可以使其區別于市場上的其他產品。SAPBusinessByDesign是全球最完備、最靈活、按需配置的企業管理解決方案。與其他按需配置的企業管理軟件不同，SAPBusinessByDesign（見圖2-2）讓企業端到端的每個流程都更透明且易于掌控，這其中包含了客戶關系管理（CRM）、供應商關系管理（SRM）、供應鏈管理（SCM）、財務管理（FIN）和人力資源（HR）。此方案讓企業能立即對自己的情況進行360度掌握，并且它簡單易用，能快速配合商業需求的變動。圖2-2SAPBusinessByDesign（版權歸SAPAG.所有，2010）SAPBusinessByDesign設計時考慮了以下幾個關鍵原則：·堅持以市場為導向的設計思路與開發路線?！ぴ陧椖砍跗谡献罱K用戶的反饋并融入迭代開發流程。·提供突破性的用戶體驗?！U大模式驅動（model-driven）、服務導向（service-oriented）的架構的影響力。2.2.1項目歷程幾年前，SAP決定開始一個新的研發項目，利用面向服務的架構優勢，建立一個企業級應用的新原型。項目的主要目標是提供卓越的用戶體驗，降低軟件復雜度，降低總所有成本（TotalCostofOwnership，TCO）。我參與了解決方案的規劃，而后我們團隊設計出了最初的軟件構架圖。隨后，我們成功地向董事會展示了規劃圖并通過了審批。公司問我是否愿意去領導用戶界面相關的工作。之后的幾個月里，我們與開發團隊一起搭建UI架構，建立最初的原型，并為不同用戶角色設計了一系列不同的應用程序。我們有很大的自主權，可以自己定義新的軟件架構、采取新的開發流程和設計新的應用程序。此研發項目的結果很成功，SAP董事會決定在這一研究項目得出的軟件架構基礎上，搭建一個新的面向中小型企業的企業管理解決方案。2007年9月這一全新的企業管理解決方案正式發布。此后這一產品就叫做“SAPBusinessByDesign”。2.2.2為什么SAPBusinessByDesign與眾不同SAPBusinessByDesign將用戶需求作為設計的中心，解決企業管理軟件中與“人”有關的問題。這一定位至關重要，因為購買企業管理軟件的決策者已不再是首席信息官（CIO），而是使用該軟件的部門。我們的目標是設計出一套滿足用戶期望的解決方案，并確保每位用戶都能高效地使用該系統。為達到這一目標，我們制定了一套以用戶為中心的設計流程（見圖2-3），并在組織上下強制執行。圖2-3以用戶為中心的設計流程（版權歸SAPAG.所有，2010）對客戶而言，糟糕的UI帶來的使用成本（例如，使用戶培訓時間延長、造成低下的使用效率，更有甚者用戶可能會拒絕使用這個軟件）可能高達購買應用程序本身費用的數倍。因此，對他們而言，卓越的用戶體驗至關重要。SAPBusinessByDesign的主要目標是：簡單易用軟件必須易學、易用。用戶希望軟件可以輕松上手，不希望在培訓上花大把的時間。特別是在中型企業市場，員工往往一人承擔多種角色。因此，軟件的易用性和一致性十分重要。我們使用了基于模式的設計方法，有助于保持整個軟件系列的一致性，使得用戶可以用同樣的方法有效地執行相似的任務。以人為本的設計要提供直觀的用戶體驗，設計者必須理解最終用戶的需要。首先，在軟件開發周期之初，我們就要確定用戶需求，深入用戶的工作環境，并了解用戶所需的信息、工作流程、工作目標、工作動機、溝通方式等。然后將這些發散的用戶需要（userneed）轉化為具體的用戶需求（userrequirement），進而轉化為系統需求。最后編寫出用例（usecase）并設計出線框圖（wireframe）。隨后我們通過最終用戶測試用例和線框圖，并在移交開發部門之前將用戶的反饋融入線框圖。我們也會對開發完成后的產品進行可用性測試，但相比之下，我們在開發初期基于線框圖進行的測試要更多。此類更早期的測試效果更好，因為改變早期設計比改變一個已開發的應用程序花費要更少。在整個開發流程中與最終用戶保持持續的迭代反饋循環至關重要。靈活的UI技術所采用的UI技術必須靈活，能夠快速適應和滿足市場需求、客戶需求和用戶需求。我們的整個解決方案都是在模式驅動和服務導向的框架上開發的。這能確保我們的客戶和合作伙伴有足夠的彈性空間去對解決方案進行調整和擴展，同時，這也讓最終用戶個人能根據自己的需求去自定義系統。在開發過程中使用UI模式有利于保持一致性，并極大地提高了開發團隊的生產力。2.3用戶體驗團隊的角色在成立的頭兩年里，ByDesign用戶體驗團隊就迅速發展成為一個跨越多個國家的大團隊。由于不可能在很短的時間內就招到足夠多的人，我們與幾家外包供應商也有合作。我們聘用了許多具有優秀交互設計和用戶研究背景的人，他們都很年輕且充滿創意。同時，我們也很看重所招聘的人是不是有團隊精神。為什么這點很重要？用戶體驗團隊在整個產品開發流程中扮演著重要角色，因為他們是對接方案管理部門和開發部門的橋梁以及最終用戶需求的傳達者。用戶體驗團隊必須站在用戶的立場去溝通，但同時他們對產品的理解很可能不如解決方案經理。因此他們需要與開發者和解決方案經理不斷協調溝通，以最終更好提升產品用戶體驗。在這個過程中，團隊精神這樣的軟技能非常重要。SAPBusinessByDesign只有一個用戶體驗團隊，底下分為三個小團隊：UI概念與準則團隊為產品定義UI風格指南，為新的UI模式編寫詳細描述，并協助UI架構技術團隊（屬于技術團隊，負責搭建產品的技術平臺\h[1]）將UI模式應用到產品開發中。為了保證軟件一致性，我們將UI模式開發出來并整合到開發工具中。UI概念與準則團隊要協助設計師與開發人員使用UI設計風格指南，并收集面向未來的新的UI需求。另外，他們還負責提出并定義UI的創新概念。1最終用戶相關基礎設施最終用戶相關基礎設施團隊負責組織和協調客戶活動、合作方活動、用戶活動（例如，現場觀察、焦點小組、用例驗證、UI驗證、可用性測試以及基準測試等）。他們負責在全球建立并管理一些基礎設施，以支持設計師和用戶研究人員在多個國家與用戶進行互動。此外，團隊也負責定義UCD方法論，并對解決方案經理、開發人員和用戶體驗從業者進行UCD培訓。團隊還要參與產品開發流程的定義與執行，并確保UCD活動能夠順利地融入到開發流程中去。應用程序設計此團隊中包括交互設計師和用戶研究人員。他們與開發人員、解決方案經理同屬于應用程序團隊。他們的任務是設計企業管理應用程序，例如財務管理應用程序、人力資源管理應用程序、客戶關系管理應用程序。他們是用戶需求的代言人，也是整個應用程序團隊中以用戶為中心的設計的推動者。每個應用程序都由一名用戶研究人員負責，專門籌劃并開展相關的用戶研究活動。用戶研究中得到的結論都能立即與開發人員和解決方案經理進行討論。結論中提出的需求可能當前版本就能滿足，也可能需要暫存起來，下次更新時再解決。交互設計師參照設計風格指南，負責設計所有的交互界面并協助開發過程。用戶研究為何如此重要？因為只有了解了用戶的需求才能設計出好的解決方案。怎樣挖掘用戶需求，直接問用戶你想要什么就可以了嗎？當然不是。用戶很難表達清楚未來的軟件解決方案該是怎樣的。如果在汽車剛發明出來之前問他們有什么需求，你得到的答案很可能是“跑得更快的馬”。用戶研究之美在于觀察用戶并挖掘他們的真實需求，這也是神奇所在之處。用戶的陳述和行為都是表面現象，研究者存在的意義是：他們能夠透過現象看到本質，并挖掘出用戶的真實需求。我們應該在項目初期多花時間進行用戶研究，并與最終用戶一起改善設計。這么做能夠縮短開發周期，并最終帶來更高的用戶滿意度和使用效率。另外，這對你自身而言也是益處良多，因為你獲取了大量真實的研究數據，當有人問起為什么軟件包含了這個功能，而不是那個功能時，它能夠為你提供數據支持。以我個人的一段經歷為例，那是我第一次意識到用戶研究的重要性。當時我們去一位客戶的現場做用戶研究，地點在上海。我們觀察了一位用戶，他的任務是把幾百張發貨單的內容手動輸入電腦。他當時用的并不是SAP軟件。他把發貨單文檔放在鍵盤的左側，然后輸入數據。輸入了10個發貨單的內容后，他點了保存按鈕，等了一會，然后又點了10次刷新按鈕，確認軟件是否正確處理了發貨單的內容。他說他必須這么做，如果發現錯誤，他就能馬上糾正。通過這次觀察，我們產生了一個想法，其實系統自己就能夠為用戶做這個事。用戶只需要輸入發貨單內容，如果出現錯誤系統應該自動提醒用戶。但是，這位用戶卻告訴我們，他對他當時使用的那個軟件很滿意。因此，只有當你親自到了用戶的辦公現場，仔細觀察用戶是如何操作的，才能夠真正意識到用戶研究的重要性。然而，要做出創新的設計，僅靠觀察用戶是遠遠不夠的。你必須訪問合作伙伴、受理投訴的服務部門、數據分析師和銷售人員。收集了所有研究數據之后，研究人員會和解決方案經理、用戶體驗設計師以及開發人員一道將這些發現轉化為創新的設計。在我的職業生涯里，許多人提出過絕佳的創意點子，但是大多數想法都沒能進入到產品階段，這樣的例子我看得太多了。創新需要執行力，把創意推向市場。光有想法是不夠的，你必須為之努力，將其變為可行的解決方案。沒有成功就沒有影響力，換句話說，你的想法不過是又一個美好的想法罷了……\h[1]這里需要注意“技術團隊”和“應用程序開發團隊”的區別，前者負責搭建技術平臺，后者負責在搭建好的技術平臺上，開發一些企業管理應用。本章中將多次提到這兩個團隊?！g者注2.4項目階段項目要經歷三個階段，如圖2-4所示。在第一個階段，我們有意將開發流程與UCD流程分開進行。解決方案管理團隊負責通過外部驅動研究方法定義目標解決方案，與此同時，開發團隊并行開發技術平臺。從一開始，ByDesign用戶體驗團隊就同時協助解決方案管理團隊和負責開發技術平臺的UI架構團隊。用戶體驗設計師與解決方案經理緊密合作，一起定義應用程序的目標設計。同時，我們也必須確保在UI架構中能完美地實現出UI模式，撰寫詳盡的UI規范文檔，并在開發階段協助框架開發人員。在第二階段，我們得讓已實現的解決方案更接近目標設計。等到了第三階段，我們就開始轉入精益開發（LEAN）與敏捷開發（agiledevelopment）模式。剛開始時，我們并沒有明確地區分每個階段。但隨著經驗的積累，情況逐漸清晰起來。每個階段我們都學到許多技術、流程和全球性組織管理的經驗，而且團隊在這些方面的表現也大大提升了。圖2-4項目階段2.4.1第一階段：設計解決方案（目標設計）盡管當時沒有現成的技術，我們也必須開始設計。我們的目標是打入新市場，吸引新客戶群。解決方案經理和用戶體驗設計師的首要目標是解讀市場需求和用戶需求。他們為新解決方案提供目標設計。他們設計了上千個界面，用HTML制作可點擊的原型，這些原型在外觀和使用感上與真正的應用程序相差無幾，但這一過程并不需要寫代碼。然后我們讓上千名分布在世界各地的用戶驗證這些界面，通過不斷迭代改進解決方案。我們還與管理團隊、執行董事們花了好幾天一起檢查HTML原型的界面。雖然這一過程比較耗費時間，但是相比等到商業目標確定以及框架編程也完成后才開始測試的代價要小得多。我們從中得出一個經驗：一個HTML原型勝過千言萬語。因為這是一種所有開發人員、解決方案經理、董事會成員、經理以及來自各種文化背景的人都能理解的語言。我們希望產品能吸引那些以前不用SAP產品的新客戶、新用戶，而不是僅僅利用現有的SAP客戶群。因此，我們必須建立自己的基礎設施，接觸那些還沒使用SAP產品的用戶。我們通過市場研究公司找到符合要求的用戶，并借助外部的可用性實驗室開展用戶活動。合理性測試（TheSanityCheck）\h[1]在這個階段設計UI原型是個難題。在設計用來描述目標設計的UI設計風格指南時，需要假設許多技術的可行性。然而，隨著項目的進展，我們有些技術并沒有足夠的時間去實現。我們必須一次次地更新UI設計風格指南，不斷提高它與技術框架的一致性。在這種情況下，讓參與項目的每個人都及時了解最新變化又成了另一大難題。為此我們建立了一個維基站點提供最新信息并定期開展信息交流會。解決方案經理和UX設計師在將UI原型移交應用程序開發人員之前必須根據這些變化做出相應調整。我們希望UI原型能呈現出最好的品質，它必須盡可能精準地呈現出我們最后想要的效果。為了確保UI原型能夠與設計風格指南保持一致，我們決定在開發流程中添加一道“合理性測試”門檻。在解決方案經理和UX設計師將UI原型移交給開發部門之前，原型要先經過我和SAP的用戶體驗部門高級副總裁丹·羅森伯格（DanRosenberg），也是用戶體驗方面的專家，召開正式審核會議來決定。我們對設計風格指南了然于心而且也熟悉大部分技術細節。在這一階段進行質量測試至關重要。合理性測試是必須通過的一道門檻。它強調了UI設計風格保持一致的重要性。在合理性測試階段，我們將不同的UI原型標記為“紅燈”“黃燈”“綠燈”三個狀態?！熬G燈”代表UI原型與設計風格指南一致，開發部門可以開始開發?！包S燈”表明UI原型在移交開發部門之前還需要做些細節上的改動。“紅燈”意味著未通過，即UI原型與設計風格完全不符合，需要重新修改后再次進行合理性測試。剛開始執行、記錄合理性測試的時候相當吃力。我們看了上千個界面。進行合理性測試的時候，我們不能深入到很細節的方面，而只是指出一些明顯的問題。但我們的努力是值得的。我們定位問題的速度越來越快，而且隨著時間的增長，UI原型合理性測試中出現的“綠燈”越來越多。我們定期將合理性測試的總體結果匯報給管理層，這讓用戶體驗有了更多的曝光機會。在當時的情況下，進行合理性測試是一個正確的選擇，它是一個很好的工具。如今我們已經不再需要進行合理性測試了，因為得益于穩定的UI風格指南，UI原型質量已經大大提升。基于模式的用戶界面從一開始我們就很清楚地認識到為了提高開發的一致性，我們必須將UI模式整合到開發環境中。這是正確的決定，因為大多數開發人員都不想花時間去讀UI設計風格指南。我們對企業軟件的常用模式做了大量研究，從中提取出UI模式。在開始SAPBusinessByDesign項目之前，我們在另一個SAP產品中就已經初次接觸過UI模式。第一個產品的客戶和用戶使用這些UI模式時給予的反饋對提高BusinessByDesignUI模式庫的質量起到了很大的幫助作用。UI模式是針對用戶完成的某些任務而設計的。舉一個UI模式的例子——目標工作列表，如圖2-5所示。這個模式支持用戶完成搜索商業目標、定位目標、預覽數據或者開始實現目標等任務。同一個UI模式里的所有UI元素和元素間的交互方式都是預先設定好的。這樣就開發人員不需要再操心這些問題。最后呈現給用戶的是一個具備基本搜索與高級搜索功能的搜索區域。用戶單擊“搜索”按鈕之后，所有的結果將出現在搜索區域下方的表格中。當用戶選擇了表格中的一項后，相關的商業目標細節就會出現在預覽區域。剛開始的時候，我們并不確定有多少UI應該采用基于模式的設計流程，有多少應該采用“自由風格”才能夠迎合用戶的需求。開始我們估計70%的UI可以套用模式，30%采用自由風格。然而當我們設計完所有的頁面后，我們終于有了答案：90%的UI都套用了模式，10%采用了自由風格。但這個比例并不是一定的，因為這一結果很大程度上取決于你的模式數量以及你要搭建的應用程序的類型。例如，圖2-5所示的“目標工作列表”UI模式在我們的解決方案中用到了350次。這也表明使用UI模式會帶來的高回報。另外，我們也不是很確定每個UI模式應該留給開發者多大的自由發揮的余地。如果嚴格限制模式，解決方案可達到高度一致，但你將無法通過優化UI讓用戶更好地完成任務。所以我們決定多給開發人員一些自由度。然而，在有些情況下靈活度稍微有點過頭了，以至于我們不得不在項目后期花大量的時間處理細節上的一致性問題。在第一階段，解決方案管理部門主導產品定義。他們負責具體的需求定義。UX設計師負責用戶體驗設計，但整體的解決方案仍是由解決方案管理部門負責。他們負責推動將設計移交給開發部門的這一環節，并與開發部門溝通。而UX設計師需要參與到任何需要他們的環節。UX初步制度化的一個標志是：開發人員只有從解決方案管理部門拿到UI原型后才可以開始開發。我們在第一階段面臨的挑戰是在不清楚技術局限的情況下開始設計解決方案。我們在UI架構的規范文檔的基礎上建立了UI設計風格指南。我們在設計時抱有的預期是：一年內，在UI架構的基礎上實現UI規范，并且能夠及時移交給應用程序開發人員。一年后，第一版的UI架構完成，開發人員開始實現應用程序的界面。從用戶體驗的角度看來，第一版的SAPBusinessByDesign并不完美。因為技術平臺團隊與應用程序開發人員無法在有限的時間內開發出與目標原型相同的界面。我們必須在下一版本中做出改進。圖2-5基于模式的用戶界面（版權歸SAPAG.所有，2010）引入關鍵績效指標（KPI）評估產品表現項目開始的時候，我們設定了每個版本應該達到用戶體驗KPI目標值并在版本末期評估產品表現。我們通過基準可用性測試評估用戶使用效率，有效性和滿意度。我們很清楚不可能在第一個版本就達到最終目標。我們為第一個版本設定了6分的可用性KPI目標值（總分是10分）。然而，我們選擇了一些關鍵用例對他們進行基準可用性測試，結果顯示：第一個版本的KPI只有4.8，甚至沒有達到我們為第一個版本設定的目標值！我們將這一結果上報給管理層，顯然我們需要增加項目投入。同時，我們也計劃了改進措施以期用戶體驗在下一版本上有重大提升。用戶體驗是下一版本需要最先考慮的問題，開發人員也需要集中精力提升用戶體驗。\h[1]合理性檢查是一種快速檢查某結果是否具有基本合理性的辦法。2.4.2第二階段：更接近目標設計在第一階段，我們有意將目標解決方案的設計與技術平臺的開發并行進行。一方面，解決方案經理、UX設計師在設計解決方案（不斷迭代），并且有最終用戶參與全過程。另一方面，技術和應用程序開發人員同時在搭建新的軟件架構，并開發第一版SAPBusinessByDesign。他們的表現都相當出色，但這也意味著第一個版本快發布的時候將必然存在對接問題。因此，第二階段的目標就是讓