產(chǎn)品經(jīng)理雖然致力于提升用戶體驗，但是由于先入為主的局限性，總是不能完全理解用戶的需求，針對這個問題，筆者以出行產(chǎn)品為例，闡釋可以從哪幾個層面去加深對用戶需求的挖掘和理解。

“用戶體驗”是指用戶在使用產(chǎn)品過程中建立起來的一種純主觀感受，主觀感受可以涵蓋為以下兩層含義：

1. 既然是主觀感受，那么肯定是基于使用者自身的行為習慣、使用場景等因素；
2. 另一方也說明，用戶往往對自身的真實需求并不明確，產(chǎn)品需要去挖掘。

作為用戶，對一個產(chǎn)品的評價可以只是簡單的總結為“好”與“壞”，但作為產(chǎn)品經(jīng)理，就必須知道用戶在體驗的過程中，究竟哪里好、哪里壞。

這就像讀一本書、看一部電影，你只要看過，就不可能只是簡單的“喜歡”或者“討厭”，一定會有一些自己的見解。

一、結合用戶真實體驗評測

想要了解產(chǎn)品的優(yōu)缺點，就要和用戶一起參與產(chǎn)品的使用，才能有依據(jù)的進行優(yōu)化，進而提升用戶體驗。

就像“百度貼吧之父”俞軍所說的：

用戶體驗不是一個靜態(tài)頁面，而是一個過程，要結合用戶的真實使用過程來評測。

任何產(chǎn)品都是為了更好的服務用戶生活，任何報告、數(shù)據(jù)都無法完整反映用戶在使用產(chǎn)品過程中的喜怒哀樂，這些情緒和波動無法直接反饋在功能點或信息點上，經(jīng)驗往往更加真實。

你只有深入了解每個階段可能出現(xiàn)的需求點，明白它們出現(xiàn)的各種因素，這樣才能知道產(chǎn)品是如何影響用戶生活的。

學會換位思考，與產(chǎn)品互動，借此與用戶產(chǎn)生共鳴，藉由同理心去設計并優(yōu)化產(chǎn)品，這是改善用戶體驗的好方法。

我們可以試著建立一條這樣的用戶體驗路徑，從頭開始完整的體驗產(chǎn)品全流程，了解用戶在使用產(chǎn)品過程中各個階段的出發(fā)點、觸動點、關注點和需求點，而非局限在其中某一個功能或服務項目上。

二、用戶體驗路徑拆解

我們可以將這樣的體驗路徑代入到用戶使用場景中，大膽假設，小心求證。

比如一個旅游出行APP，假設它擁有現(xiàn)在市場上主流旅行APP的基本功能，比如航班/酒店預定、景點購票、叫車等服務。

那么將上述用戶體驗路徑代入之后，我們就能得出以下的用戶使用流程：

這個路徑能幫我們模擬用戶使用產(chǎn)品時，各個階段的原始需求、心理活動和行為感受。

1. 計劃行程階段（認知）

此時用戶開始計劃行程，主要是評估目的地的旅行價值，以及平臺的服務能力。

產(chǎn)品經(jīng)理考慮的用戶需求：

• 明確出行目的：婚旅/度蜜月、商務出差、休閑度假、自駕游等；
• 提供出行方式：飛機、火車、汽車、打車/租車、高鐵、郵輪等；
• 安排出行住宿：酒店、民宿/客棧、別墅等；
• 參考出行資料：用戶評論、旅行攻略等；
• 預計出行價格：交通費、住宿費、餐飲費、門票費等。

用戶實際考慮的角度：

• 盡量提供套餐式服務，直接包含多項服務，一目了然；
• 最好有直觀的項目比價工具或套餐對比工具，直接進行橫向?qū)Ρ龋?/li>
• 在可以報銷的前提下，商務人士出差更愿意坐頭等艙；
• 在團體出行的前提下，企業(yè)或組織更愿意租別墅轟趴；
• 隨時要有取消行程的功能，比如取消航班、酒店預訂等；
• 第一次去目的地旅行，希望有更多的出行建議和替代方案推薦。

當然，我們還需要頭腦風暴一下，用戶在計劃行程的時候會顧慮哪些特殊情況，產(chǎn)品有沒有可能幫助他們應對這些情況？

• 出現(xiàn)突發(fā)事件、緊急情況下，有沒有可能提供當?shù)氐腟OS服務或客服熱線；
• 遇到氣候不利出行的情況下，APP要及時反饋，做出行提示，提醒帶傘、防曬/防寒或注意安全。

計劃出行階段，用戶實際上還處于一個需求模糊的狀態(tài)，只要尚未出行，一切取消或延期都是有可能的。

因此這個階段產(chǎn)品能做的，就是提供參考信息，幫助他們做決策，而不是簡簡單單的擺出一二三四的選項供他們選擇，可以有更多個性化定制或推薦。

2. 行程預訂階段（決策）

做完旅行規(guī)劃后可以開始確認訂單，此時價格、安全、服務成為核心關注點。

產(chǎn)品經(jīng)理考慮的用戶需求：

• 顯示到出行目的地的時間、距離、車次/航班等具體信息；
• 酒店住所的聯(lián)系方式、地理位置、剩余房源等具體信息；
• 給出安全、合規(guī)的付款流程，提供盡可能多的付款方式；
• 顯示優(yōu)惠券的核銷以及抵扣情況；
• 推薦會員/金融服務，促進多次消費，提高產(chǎn)品粘性。

用戶實際考慮的角度：

• 下單時提供或者建議一些其他增值服務；
• 下單后由酒店/商家/司機/工作人員直接進行短信確認或電話溝通，會比平臺單方面的訂單完成顯示更讓人放心；
• 自定義備忘錄或自定義行程模塊，防止遺漏一些事宜；
• 商務人士更在意訂單能否開發(fā)票及報銷單；
• 境外旅游更在意電話卡、簽證、換幣、導游等事宜。

可能遇到的特殊情況：

• 由于各種原因?qū)е碌男谐掏七t、買錯票、填錯信息，客服及系統(tǒng)要有完善的應對措施；
• 系統(tǒng)BUG導致交易出錯，需要提供客服或引導。

互聯(lián)網(wǎng)產(chǎn)品，交易是用戶最敏感的部分，行程預訂的顧慮在于：付款前價格是否有誘惑力，付款中是否讓人感覺安全，付款后的服務是否到位。

平臺方可以作為交易的窗口，但要盡可能提供商家與用戶直接的對話，永遠比用戶先想到一步，讓用戶在預訂過程中始終保持對產(chǎn)品的信賴。

3. 正式出行階段（行動）

正式出行要把握多個細節(jié)，同時要預防多種意外。

產(chǎn)品經(jīng)理考慮的用戶需求：

• 時刻反饋航班/車次的詳情，確保準時出行；
• 提供商家信息，方便用戶抵達目的地后聯(lián)系酒店；
• 隨時定位用戶地理位置，以便提醒注意事項；
• 產(chǎn)品內(nèi)對接并打通網(wǎng)約車APP、地圖類APP、生活服務類APP。

用戶實際考慮的角度：

• 最好有當?shù)氐某鲂兄改?，包括人文風情、歷史名筑、美食小吃、視頻介紹等；
• 當?shù)靥厣珚蕵讽椖客扑]，比如日本的溫泉、迪拜的沖沙等；
• 希望能提供當?shù)鼐包c的購票指南或購票通道；
• 境外旅游更在意翻譯、支付、Visa等服務；
• 情侶旅游更在意旅拍服務或攝影設備租借；
• 共同痛點：附近的wifi、公共廁所、公共交通工具等。

可能遇到的特殊情況：

• 出行事故的醫(yī)療呼叫，保險服務等；
• 航班/車次晚點、取消等，隨時更新并通知到位；
• 當?shù)赝话l(fā)事件、緊急通知、氣候變化等。

出行階段的復雜性更多，但主要的體驗旅程是由用戶來完成，產(chǎn)品需要扮演管家的角色，隨時通知必要的旅程，并提供一些必要的出行工具。

總之要考慮的點涉及方方面面，可以不主動介入旅程，但一定要備好這些服務，因為隨時可能經(jīng)受用戶的考驗。

4. 旅行紀念階段（反饋）

旅程結束，是用戶的收獲和總結階段，需要提供并引導用戶參與反饋。

產(chǎn)品經(jīng)理考慮的用戶需求：

• 打通社交媒體，讓用戶參與旅程分享（朋友圈、QQ空間、微博等）；
• 提供日記/攻略/評分/評論區(qū)，滿足旅程結束后的游記、心得記錄；
• 便捷的酒店退房、航班/車次返航服務，以及相關通知；
• 行程結束后提供出行清單/發(fā)票/旅程圖等。

用戶實際考慮的角度：

• 提醒攜帶各種行李物件；
• 境外旅游更在意剩余外匯的兌換；
• 當?shù)靥禺a(chǎn)推薦，比如韓國的化妝品、瑞士的手表；
• 行程延長或改變，希望可以延長酒店時間或臨時修改機票/車次。

可能遇到的特殊情況：行李丟失或遺漏，能否協(xié)助找回。

這一階段主要是收集反饋信息為主，可以鼓勵用戶在平臺上活躍起來，記錄旅程情況供其他用戶參考，豐富產(chǎn)品內(nèi)容以及用戶活躍度。

此時也正是用戶處于興奮點的時候，對收集用戶對產(chǎn)品的評價和需求，是個不可多得的好機會。

三、處理需求

這樣的用戶體驗路徑可以用在很多場景分析。當然，找到需求點之后，更重要的是給需求排列優(yōu)先級。

大多數(shù)情況下，基本型需求>期望型需求>興奮型需求。

在拆解的過程中，還要明確哪些是偽需求，知道用戶想要什么，而不是用戶想做成什么，用戶的原始需求>用戶自身理解的需求，用這樣的思路才能做成符合產(chǎn)品邏輯，又兼顧用戶體驗的APP。

舉個例子，許多社交類、游戲類產(chǎn)品都有這樣的原始痛點：下載后打開APP，要手動搜索好友名添加、手動搜索房間號進入，太麻煩了。

如果經(jīng)過用戶自身對需求的加工理解，他們可能會這樣表達：我希望APP能一打開，好友就已經(jīng)添加好了，或者一進入APP，就能與好友進行對戰(zhàn)。

作為產(chǎn)品的設計師，我們當然知道手動搜索好友名、房間號是很麻煩的一件事，但APP也不可能讀懂你內(nèi)心具體想找的是哪個ID名、進入哪個游戲房間啊，那這是不是個偽需求呢？

其實換個思路我們就能打通這個需求。

首先翻看他們的原始需求，可以思考一下，什么樣的使用環(huán)境下用戶會產(chǎn)生這樣的需求呢？

其實這種需求產(chǎn)生有一個共同的前提，即社交類、游戲類APP的老用戶大多由新用戶邀請而來。比如社交類APP需要好友積累才能進行互動、棋牌類游戲需要至少兩個玩家才能完成體驗；當我被朋友邀請一起玩耍時，自然就需要添加好友、搜索房間了。

那么從技術上看，集成openinstall這種渠道來源追蹤的第三方，即可在老用戶發(fā)送的邀請頁面上攜帶用戶名、房間號等ID參數(shù)，這樣新用戶點擊該邀請頁面進入APP，就能被自動寫入ID參數(shù)。

從而達到被邀請人通過【邀請聊天/邀請對戰(zhàn)】等鏈接進入APP時，APP將會自動添加該邀請人為好友、或者自動進入該對戰(zhàn)房間，該需求也就大致得到解決了。

可以看到，從用戶的角度提出需求時，他們的角度只會針對產(chǎn)品的內(nèi)容進行評價，并不會考慮到“邀請環(huán)節(jié)”這些產(chǎn)品內(nèi)容外的流程模式以及使用環(huán)境。

因此看到這種類偽需求時，我們的第一反應應該是回歸本質(zhì)，了解用戶的原始需求是什么，置身于產(chǎn)品的整個使用流程中，而非其中的某個體驗環(huán)節(jié)。

該案例同時屬于期望型需求，處理得好可以給產(chǎn)品加分，起到錦上添花的效果。

如何辨別基本型和期望型需求呢？

在這個案例中，APP最開始采用的手動搜索用戶名、房間號方案，事實上就能滿足用戶想要添加好友、查找對戰(zhàn)房間的需求，因此屬于基本型。

但經(jīng)過我們升級進化后的版本，系統(tǒng)可以自動添加好友、進入房間，用戶需求得到了進一步滿足，因此屬于期望型。

兩者的結果是一樣的，最終都能實現(xiàn)【互加好友、進入游戲房間】的結果，但過程完全不同。后者讓用戶在實現(xiàn)結果的過程中得到了更高級、更智能化的服務，產(chǎn)品的印象立刻從“可以用”變成了“很好用”，用戶體驗自然不言而喻。

四、總結

除了置身體驗路徑，與用戶產(chǎn)生共鳴外，通過數(shù)據(jù)和調(diào)研收集用戶需求同樣重要。

當然，實際操作中也要重視用戶的原始需求，把客觀數(shù)據(jù)和主觀經(jīng)驗結合起來看待用戶需求，讓產(chǎn)品與時俱進，從而提高用戶體驗。

本文由 @大城小事 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議