寫給產品經理和設計師的用戶體驗知識4（大結局）

02-12

從2015年起，我陸續寫了《寫給產品經理和設計師的用戶體驗知識》系列文章，當時的寫作提綱如下：

第一部分：先糾結兩個概念「用戶體驗」和「設計」

第二部分：設計原則概覽

原則1：符合用戶使用需求
原則2：基於用戶的心理模型設計
原則3：一致性
原則4：及時有效的反饋和解釋
原則5：形式追隨功能
原則6：單一任務、漸次呈現
原則7：Less is More

第三部分：設計工具和方法

用戶場景
產品經理的溝通技巧

第四部分：用戶體驗之外

用戶體驗的局限性
用戶體驗與其他因素的權衡

然而，由於一些原因，這個系列寫了3篇文章，寫完了第二部分之後就中斷了。一轉眼，2年過去了，互聯網行業發生了翻天覆地的變化。「用戶體驗」這個概念已經不及當年那般火爆，儼然已經過了那個不論是誰，張口閉口就是「體驗」的年代了。當下，越來越多的互聯網行業的從業者開始能夠更加理性去看待用戶價值、用戶體驗與其他因素的關係。我認為，這是行業的進步。如下圖所示，是「百度指數」上搜索「用戶體驗」這個關鍵詞，給出的趨勢圖，我們發現，2015年是一個高點。

但是，雖然熱度降下來了，坑還是要填完的。於是就有了這個系列的第4篇，也是最後一篇文章。我會用一篇文章的篇幅，把提綱中的第三部分與第四部分中，除「溝通」外的內容寫完，算是給這個系列畫上句號。

用戶場景

用戶場景這東西，或許每一個產品經理和設計師每天都在用，但我查了很多資料，還真的很難找到一個準確的定義。所以，我試圖結合我自己的理解，自己去定義它。我認為用戶場景有兩層屬性，分別是：「工具屬性」和「思維屬性」。

用戶場景首先是一種對過程邏輯的闡述方法，簡單講，它幫助產品經理理清用戶使用產品的核心邏輯。具體來說，涉及以下幾個關鍵因素：

用戶是誰，
在什麼樣的條件下，
有了怎樣的需求，
會去用什麼方式實現（或者表述為：能夠做一個什麼樣的功能來幫他實現）。

從其工具屬性來看，簡單說，有兩點用途：

以用戶視角發現需求，並思考解決方案，以及評估方案合理性
輔助溝通

發現需求並思考解決方案

舉例來說，計程車司機日常主要的工作場景可以表述如下：計程車司機在沒有載客的時候，需要尋找乘客以便於載客賺錢，所以他們一邊駕車在路上行駛，一邊用眼神留意路邊是否有乘客向其招手，如果有，就停車載客。

在上述場景中，「計程車司機」是用戶，「沒有載客的時候」是條件，「尋找乘客」是需求，「一邊開車一邊留意」是實現方式。那麼，作為一個產品經理，當發現了這個場景的時候，就可以針對「實現方式」來思考，有沒有更好的方式呢？於是，產品經理想到，現在不論是司機還是乘客都有手機，可以做一款手機應用，幫助司機和乘客雙方更高效的找到對方。基於此，產品經理可以這樣表述用戶場景：計程車司機在沒有載客的時候，需要尋找乘客以便於載客賺錢，於是他打開手機應用，應用會自動向他推送附近乘客發出的乘車需求，他可以選擇合適的需求搶單，然後去接該乘客，以便於達到載客賺錢的目的。

事實上，不論是把觀察到的現象抽象為一類共性的特徵，以便于思考解決方案；還是用來驗證腦中「靈光一現」的所謂idea，用戶場景作為工具，都是相對客觀和實用的。

輔助溝通

另外，確定需求有價值，方案合理之後，使用用戶場景的方式將需求表述給其他環節的同事，往往更加高效。產品經理日常會遇到的一個重要的挑戰，往往是所謂「需求的合理性」，但是不同的人出發點不同，同一個需求，往往有人認為重要，有人認為不重要，這時因為大家的立場不同，所以很多爭論往往是雞同鴨講，沒有結果。

但是如果使用用戶場景的方式來討論問題，就可以引導各角色從用戶的角度出發去思考問題，有利於各方對於需求的理解以及相關進度的推進。

場景思維

用戶場景除了可以作為一種有用的工具使用之外，更重要的，「場景思維」是一種相比於「業務思維」和「功能思維」來說，更加適合產品經理的思維方式。

案例：應用安裝流程與許可權設置

在這個案例中，我們來體會一下工程思維與場景思維做出來的產品的差別。如果我們在Android系統中下載某個應用並安裝，在安裝前，會顯示如下圖所示的，該應用將會用到的所有許可權列表。

我們可以看到，該應用會使用到系統的很多許可權，從圖中滾動條的位置來看，足有2-3頁。Android操作系統的邏輯是，在應用安裝前，列出所有其可能用到的系統許可權，供用戶權衡，如果用戶認為可以接受，就繼續安裝；如果認為不能接受，就不安裝。理論上邏輯很清晰，但這是一種按照程序運行邏輯來展現的流程，如果從用戶場景的角度來看，有兩個問題：第一，普通用戶懂這些許可權究竟意味著什麼嗎？第二，在用戶尚未使用任何功能的時候，列出所有許可權，用戶很難將其與具體功能和目的聯繫在一起，即便能看懂，也難以評估其是否合理。

緊接著，在安裝過這個應用之後，打開時，又會連續彈出多個對話框向用戶索要許可權。其中一個地理位置信息的許可權我點了「拒絕」，因為我並不覺得一個運營商手機營業廳需要知道用戶的地理位置，結果，不給這個許可權，應用拒絕運行，出現了如下圖所示的提示：

而當我按下「去設置」按鈕之後，則直接跳轉到了如下圖所示的許可權設置界面：

這個應用的產品經理，同樣延續了如Android操作系統一般的工程思維。程序運行的邏輯是：如果擁有ABC三個許可權，就正常運行；如果缺少任何一個或多個，就拒絕運行，直到獲得它們為止，如何獲得呢？讓用戶自行去設置。沿著這個邏輯，所以用戶就看到了這個提示框。但是這種做法同樣有兩個問題：第一，還是當用戶尚不知曉應用需要相應許可權要做什麼的時候，難以評估其合理性，理論上難以做出選擇。第二，即便有一些應用必須要獲取到某種許可權後才能運行，是否至少應該在提示中告訴用戶，去往許可權設置界面後，應該要開啟哪幾個許可權呢？否則用戶依然難以正確操作。

同樣的場景，在iOS系統中是另外的一套體驗。如果在App Store中安裝一個應用，只需要按下「獲取」按鈕，驗證Apple ID和密碼（雖然Apple ID這裡是長久以來被詬病的環節），即可開始下載安裝該應用。安裝好之後，該應用的圖標就會出現在手機屏幕上，全程沒有任何需要做決策的步驟。如下圖所示：

同樣，以滴滴出行這個應用為例，在啟動的時候，依然會向用戶索要相應的許可權，這是系統必要的安全機制。但是其方式與上述運營商的應用不太一樣，區別僅僅是，多了一行文字提示：「滴滴出行需要獲取您的位置信息，以便司機師傅能夠準確接您上車」，如下圖所示：

以上App Store的案例和滴滴出行的案例結合在一起，對比Android操作系統上的流程，我們會發現iOS體系是更加貼近用戶場景的實現方式。

首先，在安裝應用的過程中，流程一直圍繞著「安裝」這個核心目標進行。瀏覽應用截圖、瀏覽應用簡介內容、驗證ID、查看安裝進度，這些都是安裝所對應的用戶場景中可能的元素。顯然，一個工程師有可能在安裝應用的時候想到「它會需要哪些許可權」，但一個普通用戶應該是想不到這一點的——只有在使用具體功能的時候，才可能注意到。

其次，滴滴出行在向用戶索要許可權的時候，明確告知了用戶「為什麼」。雖然看上去只是多了一句文字提示而已，但非常契合用戶場景。這樣，用戶知道，必須授權後，司機才能準確找到用戶，來接他，這樣用戶更有依據去做決策——這個許可權給還是不給。

用戶體驗的局限性

看起來，用戶體驗是一種可以讓「世界變得更美好」的東西。很多時候，的確如此，但是，如果沒有「用戶價值（幫用戶解決什麼問題）」、「商業價值（如何盈利）」等作為根基，用戶體驗就將像是無根的浮萍，最終是無法很好的落地的。

案例：臉萌的起落

「臉萌」是一個曾經風靡一時的虛擬形象製作應用，用戶通過滑動手機屏幕的方式組合不同的髮型、發色、臉型、膚色、五官等元素來製作屬於自己的虛擬形象。曾經在微信朋友圈、微博等各大社交網站上刷屏，並且獲得了包括IDG在內的風險投資。

其實，虛擬形象的成功案例早就有，國內最經典的案例應該就是QQ秀了。在QQ秀中，用戶也是通過自由組合各種元素的方式來設計自己的虛擬形象，並且可以組合的元素不僅包括頭髮、五官和臉型，還包括著裝和飾品。從騰訊的財報上來看，QQ秀在歷史上也曾為騰訊貢獻了不少的收入，用戶願意為此付錢，側面證明其用戶價值還是值得肯定的。臉萌主打的是「萌」這個概念，其成功切中了一部分年輕人的需求，但是如果我們深入的去對比一下臉萌和QQ秀這兩個產品就會發現問題。虛擬形象類的產品，其用戶價值究竟是什麼？是可以設計出一個漂亮的虛擬形象；還是設計了漂亮的虛擬形象之後，可以把它用在社交場景中呢？顯然是後者。臉萌在產品層面並沒有什麼特別的壁壘，雖然玩法有趣，易於傳播，但是因為無法創造社交場景，所以絕大多數用戶只能把它當做一個簡單的工具來使用，其用戶價值大打折扣。

毫無疑問，臉萌的用戶體驗真心不錯，但是，因為其缺少更核心的用戶價值作為根基，最終隱居在了茫茫的應用海洋之中。

用戶體驗與其他因素的權衡

在日常工作中，產品經理和設計師經常會就某一些方案進行深度的撕逼，這種撕逼很多時候並不會有特別明確的結果——因為很多時候，雙方立場不同。我見過很多設計師，他們以為自己能夠代表用戶，以為自己是在為用戶爭取「權益」，而實際上，他們中很多人看不到「體驗」之外的因素，甚至是看不到「UI」之外的因素；同樣，我也見過很多產品經理，他們急於拿到好看的數據，有時候會或者有意或者無意的提出損壞用戶體驗，繼而是透支產品未來的需求方案。

但是，這種撕逼的過程並不是完全沒有意義的，正因立場不同，雙方可以形成一種制衡，讓最終的產品不至於過於偏向任何一方的立場。

然而，作為一個優秀的產品經理，還是應該對自己要求高一些，應該做到理解對方的立場，並且綜合各因素去思考問題——在整個團隊中，產品經理是唯一一個不能「任性」的角色。

一個優秀的產品經理，並不應該是一個「唯商業論」、「唯數據論」或者「唯體驗論」者，而是應該有能力在包括「用戶體驗」在內的諸多因素中，找到最佳的平衡點——這在我過去一年多做「互聯網+」產品的過程中，深有體會。

就像是，幾年前，我從交互設計師轉崗到產品經理職位，去面試的時候，說（chui）過（guo）的一句「台（niu）詞（bi）」：「國內不缺優秀的設計師，缺的是，能夠用好設計師的產品經理。」

或許，當我們生活在一個狹窄的空間中，當我們眼界有限，只能看到「體驗」的時候，善良的我們就只會以「做好體驗」為己任；而當我們站得更高，可以看到更大的世界時，我們才能夠有機會學會「平衡」。

我正在向這個方向努力。

註：本文部分內容摘自我的新書《解構產品經理》，這是一本互聯網產品策劃入門書，適合3年及以下工作經驗的同學閱讀。

《解構產品經理：互聯網產品策劃入門寶典》(劉涵宇)【摘要書評試讀】- 京東圖書item.jd.com

//-----前序文章

寫給產品經理和設計師的用戶體驗知識1

寫給產品經理和設計師的用戶體驗知識2

寫給產品經理和設計師的用戶體驗知識3

//-----

劉涵宇 xidea

騰訊高級產品經理

騰訊學院講師

關注互聯網與傳統行業融合的歷史進程，關注互聯網產品與用戶體驗。

微信公眾號ID：uxcafe

專欄原名：xidea的咖啡館