5個戰術,帶你做好B端產品使用者現場調研

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

5個戰術,帶你做好B端產品使用者現場調研

大部分行業的B端產品經理,本身無法真正成為自己所設計產品的使用者,只能透過去現場進行實際的使用者調研瞭解真實使用者的痛點、發現產品需求,從而把握產品的發展方向。所以,

使用者現場調研

幾乎是所有B端產品經理在設計產品時都會經歷的一個重要環節。

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

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

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

戰術一:知彼知己

在進行使用者現場調研前,要先知彼。搞清楚使用者所處組織的組織架構,明確實際使用者與關鍵相關方。

因為B端產品的特性,我們做使用者調研時不能單純只調研實際使用者而忽略了關鍵相關方。

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

明確了實際使用者與關鍵相關方之後,要根據情況判斷進行使用者現場調研時的人員範圍與順序。

仍然以我舉例,通常我去醫院初次調研或是比較重要的調研時,一定是實際使用者與關鍵相關方都要進行調研,並且順序為先整體再區域性,也就是先醫院資訊科,再護理部,再到臨床護士也就是實際使用者。

原因在於醫院資訊科作為醫院所有資訊系統的總體管理部門,是醫院資訊系統對外溝通的視窗和中間橋樑,他們對臨床護士和系統各方面的情況非常瞭解。

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

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

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

這就是為什麼要了解使用者的組織架構和關鍵相關方。不過了解了這些之後也彆著急出發,我們只是知彼了,還沒知己呢。

使用者現場調研的目標

確定了沒?

針對各方調研的問題

準備好了沒?

問題結構及可能的答覆推演

了沒?

該領域相關的專業術語專業知識

瞭解充分了沒?

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

戰術二:盤根問底

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

這是關於使用者調研一個很經典的故事,但是很多人僅僅把它當成了故事並沒有付出實踐。

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

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

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

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

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

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

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

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

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

戰術三:眼觀六路

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

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

並且在使用者調研過程中,我們也不要過於嚴肅化,覺得一定要是跟使用者說我現在開始問問題了,我現在開始觀察了,我們的使用者調研才開始。

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

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

戰術四:查有實據

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

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

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

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

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

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

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

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

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

戰術五:殺回馬槍

使用者現場調研完成後,我們要將使用者調研的內容提煉為一個個的需求,並且確認需求的優先順序和排期,安排後續的設計和開發工作。

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

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

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

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

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

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

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

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

專欄作家

小遊,人人都是產品經理專欄作家。工作在醫療領域的產品經理,持續關注醫療資訊化、數字醫療、網際網路醫療行業。打怪升級中,期望能夠透過自己的力量為世界創造美好。

本文原創釋出於人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基於CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部