使用者體驗是一種態度

 

近些年來，使用者體驗（User Experience，UX/UE）被提及得越來越頻繁，無論是軟體、IT 還是任何其他行業都開始日益重視使用者體驗，例如：

• 成立專門的使用者體驗部門/小組
• 新增與使用者體驗相關的專職設計師、工程師甚至高層管理員
• 引入與使用者體驗相關的新開發設計流程
• 使用者體驗以需求或主要評價指標的形式單獨出現

這場使用者體驗革命的浪潮讓幾乎所有人都意識到了重視使用者體驗的意義以及帶來的價值，但在實踐過程中，人們也發現它對傳統的軟體開發產生著巨大的衝擊。很容易可以找出在企業或者產品團隊中使用者體驗設計人員與開發人員之間的矛盾與對抗：

 

設計人員認為	開發人員認為
開發人員不理解使用者的需求 開發人員總是從程式的結構角度來考慮問題 開發人員總是用效能或者其他各式理由來拒絕一些設計上的要求 開發人員不願意把時間花在進一步提升使用者體驗上	設計人員對技術一竅不通 設計人員的想法經常是天馬行空、不切實際 設計人員總是喜歡標新立異，使用者根本不習慣這些怪異的設計 設計人員的設計複雜度遠遠超出了項目初期的預算，我們根本不可能按時交付

在這些“抱怨”中我們可以注意到，最主要的矛盾在於設計人員和開發人員往往不能理解對方的工作內容，能夠在對方知識背景方面有深厚積累的更是鳳毛麟角。也正是因為這一點，很多產品經理（PM）並不能很好地對設計和開發進行權衡，使得很多決策必須通過設計人員與開發人員的反覆“對抗”來進行。無疑，不管是團隊內部的個人關係還是配合效率都有嚴重的負面影響。

 

是主導還是妥協？

 

一山不容二虎。如果設計人員和開發人員都各行其主張，產品永遠無法不可能被開發出來。為了提升使用者體驗的地位，或者說是為了引入更加“使用者體驗”的開發設計流程，一些原本是“開發驅動”的流程開始轉向“使用者體驗驅動（UX-driven）”。使用者體驗驅動的本意可能是強調“使用者體驗的重要性”，避免使用者體驗處於被動地位。對於強調“以使用者為中心（User-Centered Design，UCD）”的開發流程中，更是起到了保障的作用。

 

勿容置疑，使用者體驗驅動開發確實提升了使用者體驗設計的主動性，但是遺憾的是：使用者體驗仍然是最終做出讓步的一方。通俗地說，雖然現如今設計人員有了軟體設計的主動權（而不是被動根據開發的要求進行設計支援），但是開發人員仍然可以（而且應當）拒絕一切在技術和資源上不合理或者不切實際的設計。如果設計妥協，產品只是不太好用而已；如果技術妥協，產品根本無法開發。一旦到了需要權衡的時候，犧牲的只能是使用者體驗。任何所謂“設計高於技術”的信條，只是觸達的一套說辭和吸引公眾的口號罷了：沒有哪一個企業能夠容忍自己的產品開發永遠處於未知狀態。

 

所以，作為企業來說，只有商業驅動，沒有技術驅動，更沒有使用者體驗驅動。

 

是研發還是開發？

很多企業在這一點上界定並不明確，這裡列出“研發”和“開發”的一些主要區別：

 

研發	開發
創新、探索式的 以得到某項資料或者實現某項新技術為目標 沒有嚴格的時間限制，往往是長期的 研究失敗是正常的、可以接受的	項目工程式的 以生產製造某項產品為目標 有明確的時間限制和詳細的開發計劃 非市場因素造成的失敗會被視為嚴重事故

一般來說，產品開發人員不會把“研發一項新技術”寫進產品開發的需求列表，因為他們很清楚無法進行這樣的規劃和預算，他們也不會承諾在產品中實現某項目前還不存在或者沒有掌握的技術——這是新技術實驗室的研究人員做的事情。產品團隊在制訂開發計劃時，只會選用現有的技術，因為只有這樣，才能最大限制地保證在給定的時間範圍內，用給定的資源完成項目開發。誰知道新技術猴年馬月才能被研發出來呢？

 

不過，這一切在引入了使用者體驗設計之後就被打破了。“更好的使用者體驗”進入了產品開發的需求範圍，使用者體驗設計人員並不是利用現成的技術在生產產品，而被要求進行“創新”。設計人員在幾乎沒有約束的狀態下進行使用者體驗研發（而非開發），專案範圍（scope）和工作量都處於嚴重模糊甚至失控的狀態。開發人員不知道設計人員設計出來的軟體需要多少工作量來“生產”，甚至往往連設計人員都無法預計自己的工作量。

 

是技術還是態度？

現在一提到“以使用者為中心”，大家都會聯想到使用者體驗的一套研究設計方法流程。但是如果提到“使用者導向”這個概念，可能大家已經習以為常。對於以商業為目的的企業活動來說，我（至少目前）並不覺得這兩個概念有什麼區別，只不過前者聽起來更加親切，後者的學術感更強而已。“客戶至上”“顧客就是上帝”“顧客永遠是對的”這些口號無一不在反映著“以使用者為中心”的根本思想。很多年前，市場營銷學家們就提出了變“生產導向”為“市場導向”，後又將“市場導向”重新表述為“使用者導向”。但是無論是哪種導向，市場營銷還是市場營銷，客服還是客服，並沒有讓使用者體驗團隊來取代他們的職責。對於各種職能部門來說，無論是“使用者導向”還是“以使用者為中心”都是一種理念，一種新的思維方式，而不是新的技術。

 

回到軟體開發行業。最早的軟體開發就是編碼，能把程式寫出來就萬事大吉——那個時候可以算是“功能導向”的。當軟體規模越來越大時，這種隨意的開發不再適合，於是開始有人研究軟體開發的工程化，出現了面向軟體開發的流程管理和品質控制，形成了軟體工程體系。這一階段，軟體內部的品質有了明顯的提高，開發過程的品質也得到了控制。當“生產導向”變成“市場導向”時，軟體開發商不得不開始重視使用者對軟體的感受，於是開始試圖提升“軟體面向終端使用者的品質”，也就是我們常說的“使用者體驗”。

 

在使用者眼中，一切都是使用者體驗。無論是軟體的介面美觀性、可用性、說明書的裝訂、封裝盒的印刷、雜誌廣告的內容、還是銷售和客服人員的服務態度等等，都是使用者體驗的範疇。使用者體驗部門如果對於介面設計事事具細，理應對生產印刷、物流、廣告、售前售後等都應進行詳盡的設計和規範。但事實上又沒有哪個組織的使用者體驗部門能夠如此“全能”。因此，在我看來，無論是說“使用者體驗”還是說“以使用者為中心”，都不是在指具體的技術或職能，更多的是一種工作態度，就和認真仔細、耐心、熱情、有責任心等等方面一樣，是一種橫跨所有技能職位的行事態度。換句話說：要做 UX 的人，而不是 UX 的事。

 

如何發揮使用者體驗的價值？

經過之前三個方面的討論，現在應該來說說使用者體驗以及使用者體驗團隊應該如何更好地在 IT 企業中發揮價值。

 

首先，“以使用者為中心”是一種理念，“關注使用者體驗”是企業每個部門每個崗位的責任，而不只是專職人員的工作。也正因為如此，使用者體驗部門的主要職能不再是細節的介面設計，而是對整個公司各項活動進行宏觀指導和規範，以整體提高每個環節的使用者體驗。此時的使用者體驗部門不再是一個垂直部門，而是變為橫向部門。

 

其次，原來的那些事情還是需要人來做的，比如資訊架構設計、互動設計、視覺設計、使用者研究、可用性測試等等。這些職能仍然需要相關的專職人員，但不再屬於使用者體驗部門，而是根據其具體的業務對象，迴歸各個部門的職能。就好像開發需要前端、後台、測試工程師等等一樣，需求工程師、互動設計師、視覺設計師、可用性測試工程師也是Team Dev中的職能，沒有必要非要用“使用者體驗部門”將其獨立和分離，更不可與Team Dev並行。至於使用者研究人員則可以迴歸市場營銷部門。在一個完整的產品小組中，各職能人員是在 PM 的帶領下協同工作，而不是某部分去“驅動”另外的部分。真正的使用者體驗部門則應當制訂更好的跨部門工作流程並給予各部門專業指導，以保證大家確實是在“以使用者為中心”的方式工作。

 

最後，也是最重要的：研發與開發的分離。使用者的反饋收集與研究、使用者體驗的提升、互動方式改進等等應當是研發的範疇，由研發部門進行。產品部門要做的僅僅是從研發部門中選取適合自己的研究成果，並把一些問題和想法提給研發部門——而絕不是在產品開發過程中給研發部門下達計劃任務。使用者體驗設計從根本上來說是一種創新活動，而在產品開發過程中是很難做到充分創新的，因此使用者體驗設計應當放入科研軌道。更徹底的做法是：即使是在研發團隊中，使用者體驗設計也應當只是研發團隊的一部分，研發團隊向其他部門輸出的不能只是空洞的“創意”和“想法”，而必須是經過技術研發的、可行的“解決方案”，保證產品Team Dev只需要“拿來主義”。只有這樣，才能讓科研人員沒有束縛地不斷追求更好的使用者體驗並將其付諸於實現，而產品團隊也不至於對產品需求、範圍和工期難以掌控導致項目延期甚至失敗。

 

當然，要建立這樣的體系需要強大的資金支援。追求好的使用者體驗與實現好的傳統軟體工程一樣，都需要組織自身的積累和支撐。對於實力並不雄厚的小企業來說，除了發揮英雄主義之外，還有很長的路要走。

 

 

（原文發表於：http://www.richardbao.com/diary/entry.aspx?id=72E3F2F501A68A9!1412）