用戶現場調研，許多B端產品經理都經歷過，然而不同的人通過不同的方法，拿到的調研結果也往往不同。一次成功的調研能夠使產品需求浮出水面，一次失敗的調研則只是浪費時間。若把用戶調研當作一場戰爭，我們該如何制定戰術，確保挖掘出用戶最真切的需求？歡迎閱讀。

大部分行業的B端產品經理，本身無法真正成為自己所設計產品的用戶，只能通過去現場進行實際的用戶調研了解真實用戶的痛點、發現產品需求，從而把握產品的發展方向。所以，用戶現場調研幾乎是所有B端產品經理在設計產品時都會經歷的一個重要環節。

但是不同的人通過用戶現場調研所拿到的結果是大相庭徑的，有的在調研后收獲頗豐，信心滿滿的擼起袖子開始干了。有的卻悻悻而歸，抱怨用戶不配合抱怨調研就是浪費時間，隨便編造一個用戶調研報告了草草了事。

不同的人通過不同的方式方法產生了不同的調研效果，用戶調研其實是能夠為產品的發展起到重要作用的。但我們不能高估自己也高估用戶，覺得睿智的我們雙方在一起隨便聊聊天，產品需求就浮出水面，產品問題就迎刃而解了。

而是要把每次的用戶調研都當成戰爭，認真制定戰術，通過一次次的戰爭挖掘用戶最真切的需求，讓我們的產品在上線后真正征服用戶，這樣才能收獲產品的勝利果實。

戰術一：知彼知己

在進行用戶現場調研前，要先知彼。搞清楚用戶所處組織的組織架構，明確實際用戶與關鍵相關方。因為B端產品的特性，我們做用戶調研時不能單純只調研實際用戶而忽略了關鍵相關方。

比如我負責的產品是由住院病區護士使用的，那么實際用戶就是一線的病區護士。關鍵相關方則還包括醫院護士的管理部門-護理部、醫院信息系統的管理科室-信息科。

明確了實際用戶與關鍵相關方之后，要根據情況判斷進行用戶現場調研時的人員范圍與順序。

仍然以我舉例，通常我去醫院初次調研或是比較重要的調研時，一定是實際用戶與關鍵相關方都要進行調研，并且順序為先整體再局部，也就是先醫院信息科，再護理部，再到臨床護士也就是實際用戶。

原因在于醫院信息科作為醫院所有信息系統的總體管理部門，是醫院信息系統對外溝通的窗口和中間橋梁，他們對臨床護士和系統各方面的情況非常了解。

首先，找到他們一方面能從他們作為信息工程師的角度，整體全面了解目前護士的業務場景和護理部及護士當前系統的使用情況；另一方面他們作為信息系統管理部門，也方便協調安排我們后續與護理部和護士的調研工作。

護理部作為醫院護士群體的管理層，相比信息科更加熟悉護士所有的臨床業務場景，并且他們對模糊的業務場景也具備決策權。同時也會對系統提出一系列的要求和規范，我們的系統基本要在管理層的這些要求和規范下進行設計。

搞定了關鍵相關方的信息科和護理部之后，我們的用戶調研基本就已經有了骨架。之后再找到實際用戶臨床護士溝通，針對一線護士實際的業務流程進行更加細致和深入的了解，確定實際業務中的所有細節，將骨架填充好豐富的血肉。

這就是為什么要了解用戶的組織架構和關鍵相關方。不過了解了這些之后也別著急出發，我們只是知彼了，還沒知己呢。

• 用戶現場調研的目標確定了沒？
• 針對各方調研的問題準備好了沒？
• 問題結構及可能的答復推演了沒？
• 該領域相關的專業術語專業知識了解充分了沒？

帶著這些問題再好好準備準備彈藥吧！

戰術二：盤根問底

一百多年前，當世界上主要的交通工具還是馬車時，福特汽車創始人亨利福特在做用戶調研時，收集到很多用戶需求是跑的更快的馬。但是亨利福特沒有研究如何能夠讓馬跑的更快，而是繼續追問了為什么，最后得到了用戶是需要更好的交通工具實現更快到達目的地的需求，從而推動了汽車工業更加快速的發展。

這是關于用戶調研一個很經典的故事，但是很多人僅僅把它當成了故事并沒有付出實踐。

在實際工作中，我們的大腦習慣于優先接收和處理可以少思考的確定性問題。當我們和用戶溝通時用戶說出了問題的答案時，我們總會下意識的松一口氣，心想搞定了，用戶已經把答案直接告訴我了真好，我不用費腦子多想了。

于是道理大家都懂，但實際做的時候就是沒多問幾個為什么。希望大家時刻提醒自己在面對用戶的需求或者任何人的需求時記得多問幾個問什么。

別人可以不問，但是作為產品經理的我們不能不問，我們是一個產品、一個功能、一個需求的底線。

在問為什么的時候我們也要注意不要帶有主觀情緒，也不要使用帶有刻意引導的話語去影響用戶說出你想要的結果。

有些產品同事在辦公室已經想好了“創意”，于是在用戶調研時引導用戶認可自己的“創意”。但是用戶的嘴是會騙人的。

畢竟在調研時大部分是用嘴說而不是實際操作，且用戶可能懶得搭理我們隨便敷衍表示了認可。于是造成了產品在錯誤的道路上邁著自信的步伐越走越遠，最后在上線前被用戶給否定方案的情況發生。

這是因為我們在和用戶溝通時，潛意識里將自己和用戶作為了對立面，希望對面的人認可自己先入為主的想法，不希望聽到不一樣的聲音。

要避免這種情況的發生可以試試在和用戶溝通的時候不要告訴用戶你是這個產品的設計人，從而下意識的站到了用戶的對立面，而是說你是負責把用戶的聲音傳遞給產品設計人的中間人。

作為這個角色我們在用戶表達時可以和用戶站在同一戰線，甚至可以和用戶一起吐槽產品，吐槽產品設計人員，讓用戶感到我們是感同身受的真實理解他們，從而提升對我們信任感。這樣能更好的引導用戶說出最真實的想法和需求。

戰術三：眼觀六路

不過即使用戶是真誠的表達了真實的想法，我們也仍不能只是簡單的完全信任用戶的話。因為人的記憶和表達會因為各種情況而出現不同程度的差異，這是無可避免的情況。所以除了耳聽八方聽用戶說什么，還要眼觀六路去實際觀察用戶是怎么做的。

比如我們和護士溝通時，不是僅僅在辦公室聊一聊就結束了，還會爭取跟著護士看一看她們的工作流程。甚至在病區一待就是幾天，觀察不同護士的不同操作情況，通過自己對實際業務場景的觀察去佐證和判斷與用戶口頭表述的內容是否有差異。

并且在用戶調研過程中，我們也不要過于嚴肅化，覺得一定要是跟用戶說我現在開始問問題了，我現在開始觀察了，我們的用戶調研才開始。

其實用戶調研可以是一個一直打開的狀態，你在觀察的時候看到有疑惑的地方可以隨口就問了，和用戶閑聊的時候想到了一些模糊的場景可以順便提出來就確定了，甚至在路上碰到了用戶都可以嘮兩句你需要了解的問題。

不必拘泥于形式，調研不是刻板的坐直問問題、站直盯著用戶的一種固定行為，而是可以做到潤物細無聲，讓所有和用戶在一起的時間都能夠自然的感受和理解。

戰術四：查有實據

前面我們提到有時候調研的時候用戶明明認可了，可上線前又否掉了方案的情況。這時候別管這方案合不合理、她當時聽沒聽進去了。

當時你的確是得到用戶口頭認可了，但是用戶現在就是說“我不知道這個事啊”，你是不是欲哭無淚，這找誰說理去??！這就是查無實據帶來的后果。

在用戶調研時，針對重要需求和特殊情況可以在對方允許的情況下進行錄音錄像，保留原始溝通記錄。在用戶調研完成后，有條件的情況下最好把調研內容進行匯總整理，形成本次的用戶調研報告。

并和各方一起就用戶調研報告內容進行評審，評審時爭取我方領導、對方相關各部門和對方領導在場。針對調研報告有異議的部分可以記錄下來，趁大家都在就有異議的地方進行澄清和確認。針對調研報告多方確定無誤的話可以簽字留檔。

當然簽字后并不代表后面用戶需求要是發生變化了我們就不再進行修改了，而是當這種情況發生時，需要讓各方知曉需求發生改變的實際情況。

避免各方將其盲目簡單定義為是我方當時的調研工作理解有誤、質量有問題等原因，導致給我方工作造成負面影響。

同時多方評審調研報告也是我們產品經理為后續的產品設計質量做的一道保障。實際工作中存在部分同事為了應付快速完成用戶現場調研工作，編造調研報告的情況。

這會導致后續在產品設計時，用戶調研報告完全沒有參考價值，產品經理不得不重新進行調研，造成了額外的人力成本、時間成本、尤其是用戶信任成本。

作為產品經理，這種行為對產品質量的傷害是極深的。希望各位做一個負責任的產品經理，不要讓這種情況發生在我們身上。

戰術五：殺回馬槍

用戶現場調研完成后，我們要將用戶調研的內容提煉為一個個的需求，并且確認需求的優先級和排期，安排后續的設計和開發工作。

在這個過程中，有些用戶調研的內容可能會因為有了更好的思路而產生更好的替代方案，有些內容也可能因為技術問題、資源問題等無法實現或者不考慮實現，以及在落地時會發現更多細節性的問題模糊不清。

這些情況是常有的，千萬不要覺得用戶調研已經結束了，就不管不問用戶自己做決定了。事事有回應是一個合格的打工人的基本素質，面對用戶也一樣。

我們的用戶花了這么大精力陪我們完成了用戶調研，并且也對我們的結果寄予厚望，希望能幫助我們一起打造一個適合他們使用的優秀產品。

在我們針對用戶調研的內容安排了后續的工作時，有條件的可以及時通過合適的方式如線上會議、微信或者再次線下見面將處理情況和用戶進行反饋，模糊的地方再溝通確認。

讓用戶切實感受到我們做產品的誠意和對用戶付出的在意，也能提升用戶的參與感，提高用戶對我們的團隊和產品的好感。

甚至在產品上線后，我們仍然可以進行現場回訪，在實踐中和用戶保持溝通，繼續向著更加優秀的產品方向優化迭代。

用戶現場調研不是一朝一夕的事情，不是一次兩次見面就完成的任務。尤其我們作為B端產品經理，要向用戶請教的專業的地方有很多，用戶現場調研能夠貫穿在產品的整個生命周期中發揮重要作用的。

希望大家能夠更加地重視用戶現場調研這一行為，并且能將其在我們設計產品的工作中發揮更多的價值！