如何優化 B 端產品用戶體驗？
本文摘錄自《決勝 B 端》作者楊堃老師在「全球產品經理大會」的專題演講。文末領取 PPT 資料福利。
今天分享的主題是基於用戶調研去做一個 B 端產品的體驗優化，這是一個案例的分享，但是在這個案例的過程之中我會講一些用戶調研和體驗優化的小技巧，希望能幫到大家。我將按照一個調研該有的順序，一步一步帶着大家手把手去體驗一遍這個案例，以及掌握其中的技巧。
01
制定調研計劃
先說一下這個案例的背景，這是我之前某家公司做電銷的 CRM 系統自建自用的。這個電銷的 CRM 系統也用了好幾年了，大家知道電銷人員操作的工作臺，打電話、拜訪的記錄功能應該是操作最頻繁的，因爲電銷人員每天打完電話要填拜訪記錄，寫小結，所以它的操作頻率是這個軟件系統裏邊最高的一個功能模塊，這也是我們電銷 CRM 系統最核心的一個功能。
但這個功能其實在之前那家公司的一線業務人員那裏體驗和口碑是不太好的，因爲之前的這個功能已經被改得越來越複雜，交互變得越來越繁瑣，很多一線人員都說這個功能不好用，體驗非常差。不好用的抱怨非常多，所以其實一直想對工作臺做一個整體的優化。但這個工作其實非常棘手，爲什麼？大家知道，B 端的產品如果功能都有的話，業務員覺得難用也還得用，但是你要想去改裏邊的一些核心功能的話，其實風險是非常高的。像這個功能是一個高頻剛需功能，雖然抱怨很多，但我們是不敢輕易去改的，因爲如果改出問題的話，一線就會炸鍋。那你說體驗有問題的話，其實忍着也就過去了對吧。所以其實這塊的功能長時間是不敢動的。
而且還有一個很重要的原因，就是之前做過好幾次調研。大家有沒有發現在 B 端的軟件領域有一種情況，就是你問用戶很多功能好不好用，他說不好用，那你就說給你優化一下行不行，結果他就說千萬別優化。不知道大家有沒有遇到過這種情況，這個是因爲用戶都已經用習慣了，習慣了他就不太願意改了，其實就相當於老員工是不願意改的。新員工來了以後，他本來就蒙圈，但用一用其實也就會用了。所以就是這樣的情況讓我們不敢做優化。
但是我們整體還是想把它去做一個改造，其實這個收益可能不是特別明顯，當然在用戶體驗上是希望能夠產生價值的，但是風險卻非常大。所以這個事情當時決定去做的話，首先要給他明確一個目標，就是這次優化的目標。
第一個當然還是提升用戶體驗，在 B 端產品的用戶體驗這塊我們一般還是用 NPS 這種方式去衡量，去看用戶的滿意度指數。
第二個，就是結合這個優化，當然也有些業務上的訴求。除了本身口碑上的優化以外，另外是希望提高業務人員的操作效率。因爲我剛剛講了，錄入拜訪記錄是高頻且很花時間的，如果能對他的錄入效率有一定的提升，對於一線人員每天用系統的效率就很有幫助了。所以這是一個希望量化的指標，就是看他錄入拜訪記錄的時間能不能縮短。
第三個，這個功能在很多 CRM 系統其實非常重要，因爲它承載着能夠幫助業務人員在合適的時機把一些結構化的客戶的關鍵數據和資料準確地錄入系統，但是這塊功能如果交互設計有問題的話，錄入的結構化數據會非常亂，而且很多業務人員是不願意去錄的。所以我們第三個訴求就是能不能借着這個機會讓業務人員在錄數據的時候，把數據的質量和準確性都能提高。
所以這個項目立項的時候是首先定義了三個核心目標，這是我這個案例的背景。
接下來我們來看一下調研。我簡單總結一下，這是一般一個調研的過程，其實大家應該也都很熟悉了。從明確調研目標，確定調研的對象、採用的調研方式，到執行計劃和總結輸出，這個步驟肯定都是大同小異的，這裏我想說的一點是 B 端產品的調研跟 C 端的區別是非常大的，因爲 C 端是單一用戶，B 端是企業客戶。企業客戶裏就會涉及到多個利益方和利益角色，不同的企業客戶和關鍵的利益方，採用的調研方式和手段都是不一樣的。
在這個案例裏邊，我們首先明確了調研目的，明確了調研對象，調研方式會選一些面對面的訪談，以及焦點小組的訪談形式。
02
通過訪談了解基本情況
接下來一個比較重要的課題是 B 端的產品背後面臨的是業務多角色的問題，這是所有 B 端產品都面臨的一個嚴肅話題，大家一定要謹慎對待。不論是做什麼 B 端產品，不論是做 CRM、ERP，還是 WMS、TMS，不論是做什麼業務形態的，你的軟件產品背後服務的業務越過業務屬性來看的話，一定會有一些這樣的關鍵角色在裏面。
首先第一類，就是圖中左上角的業務提出人，這個業務提出人通常就是企業的最高層，一般他會提出一個戰略的規劃和要求，然後會安排人去執行，所以業務提出人是第一個需要大家關注的。
第二類是這個方向的業務管理者，就是 B 端產品背後都是服務一個業務的，這個業務肯定是有一個對口的業務管理者，這個業務管理者的工作目標實際上就是把前面那個業務提出人定的企業戰略在戰術層面進行拆解、落地，而且爲最終業務結果負責的這麼一類人，也是業務的負責人。
第三類是業務執行者，就是爲了具體配合業務開展執行的，有一些具體一線幹活的以及他們的 leader 算業務執行者。
除此以外，從業務內部來看，還有業務協作者。所以從 B 端服務的業務本身來看會有這麼一些關鍵角色。其中有個特別有趣的現象是，對於 B 端產品來講，大家覺得這個產品是賣給誰的？誰來決策買這個產品？其實一般就是業務管理者和業務提出人，但是買這個軟件的人就用它嗎，用它的人是什麼人？其實問題不在這。那問題在哪呢？
03
通過問卷設計進行定量分析
我們通過幾個問卷設計案例來看一下問題出在什麼地方。
問卷 1，首先選想要包含所有可能。
問卷 2，它問的到底是包裝，還是味道？那這個問卷就模棱兩可了。
問卷 3，你平常經常在朋友圈分享文章嗎？經常、偶爾、從不分享。這個問卷問題在哪？我看底下選項不多，難道應該是特別特別經常分享、特別經常分享、經常分享、偶爾分享、特別特別從不分享、特別從不分享、從不分享，是這樣嗎？
這個這個問題其實很常見，就是我們在問問題的時候，儘量避免這種主觀的回答，應該用數字，具體客觀地去描述。就像圖中下面的提問那樣換一種方式去問，可能收到的數據樣本的真實性、準確性就會更高，否則像剛纔那種問法，很多人對 “經常” 這種概念是不一樣的，所以要避免那樣問，而用數字代替。“一般”、“非常” 這種字詞就要慎用。
問卷 4，你覺得采用原生 APP 後加載速度是否更快呢？這個大家一下就感覺出來這問題是不是太專業了。誰知道原生 APP 什麼意思呢。我們可能一看就懂了，但是你要知道很多人其實不具備很多基本的電腦常識的，圖上問的這種問題就更不懂了。
之前有一個段子，就是老師在臺上說請同學們把鼠標指向屏幕的右上角，將屏幕關閉。年輕人可能都能理解，但年長的學員就使勁拿鼠標拍屏幕的右上角，問老師怎麼關不掉。所以這個一定要說得儘量簡單，讓大家都容易理解。
像上圖這種就可以換一個問法，雖然這句好像也不是特別好，但是總比上個問題稍微好一點，因爲這句的問題在於誰知道 1.3 是什麼呢。
再看問卷 5 的設計方式，是不是太開放了？下面的問題就比較清楚了。一般我們還是希望儘量慎用全開放問題，至少給幾個選項引導一下。當然這幾個選項怎麼給也是很有講究的，因爲這幾個選項可能會引導大家習慣性地在這幾個裏去選，所以選項設計的時候需要非常慎重，但肯定不能開放式地去問，因爲開放式問題會讓用戶有一個思考過程，其實用戶是很不喜歡自己動腦子去想的，給他一些提示會好一些。
問卷 6，對某某某沐浴露的味道你是否喜歡？非常喜歡、 無所謂、不喜歡。大家覺得這是什麼問題？這個問題非常常見，在問卷設計裏面，這類問題儘量把它數字化，打分雖然也是個主觀問題，但是它會讓這個結果儘量客觀化、數據化，這是一定要注意的。就是在遇到這種問卷的設計時都要用數字。大家平常去填一些表格的時候會發現大多數都是填這種數字的，這個區間還是會更準確一些。
問卷 7，我們打算做一個新功能，請問你是否願意使用？願意、不願意、不關心。這個問卷問題就在於，一般情況下，這種問卷發出去所有人都會填 “是”，是嗎？平常我們做需求調研的時候問用戶：“我做了個產品你會用嗎？”90% 的人都會說會用，然後產品做出來以後他就不用，這是很正常的，因爲又不是他在那做產品。甚至還有些用戶給你提需求，那你就問：“你會用嗎？”，他就說你別管。那你說：“你不用我爲什麼給你做呢？” 那人家就說，反正說不定哪天就用了，你又沒事幹，你趕緊做了吧。這種也很常見。所以我們做調研的時候就千萬不要問我做了個新功能你願不願意用。
大家知道 C 端產品設計有一個模型叫卡諾模型，其中核心的本質就是除了正着問，還要反着問，就是問：“我不做會怎麼樣啊？”，其實大多數的功能你說 “我不做會怎麼樣”，用戶可能會說 “不做就不做吧”。所以要正着問再反着問，這個很重要。你千萬不要以爲你問他，他說會用就真的有人用。其實這麼問也是在判斷需求的強度。
還有一種辦法就是看他現在怎麼解決問題的，如果一些需求他說很着急，你說你現在怎麼解決的，他說我現在就等着你了，那這個需求對他來講重要嗎？我覺得不是特別重要，這個事要真的着急的話，他就是想盡辦法都得做了，他不會等着你的。
當然這裏邊我給了一些參考的手段，就是判斷一些需求強度和真實性的。比如說讓用戶給感受打分，正着問反着問，甚至付一筆錢。這個付錢的 SaaS 是很重要的，SaaS 軟件尤其是初期時，不是拿去免費給人用就可以了，其實免費真的非常不好，一定是要收一點費用的。收費是一種對真實用戶很好的篩選手段。
比如說有些英語試聽課，爲什麼有的要收 1 塊錢，有些不收錢，有些要收 99，原因都不一樣。我之前還參加一個針對企業家的培訓。你們知道那課賣多少錢嗎？因爲我是那家公司的顧問，去感受了下他們的產品針對企家的培訓，三天兩晚的課程賣 39000，很貴了是吧？但他們公司老闆說，這課不是用來賣的，而是用來篩選目標客戶的，因爲買了這個課的人上完以後，他們核心要賣的是一個 40 萬的 MBA 課程。所以付費與不付費還是不一樣的。
然後再來談談調研的結果分析。先說一個很重要的現象叫 “倖存者偏差”，這有一個故事：二戰的時候美軍要研究飛機哪些地方薄弱，結果飛機飛回來了以後，發現機翼上的彈孔最多，於是就說 機翼這個地方最容易被打了，於是機翼就強化了，但實際上這樣做有效嗎？沒有效，因爲真正薄弱的地方被打中了以後，飛機都掉下去，飛不回來了。所以研究這些飛回來的飛機，給了他們一個錯誤的判斷，這個就是倖存者帶來的分析的偏差，叫 “倖存者偏差”。
這個在問卷分析的時候也非常常見，因爲可能回答你問卷的那些人本來就是軟件產品的高度的粉絲用戶，他們給你的問卷的反饋可能並不能代表所有人。所以這種情況一定要注意，不要被他們誤導了。
還有一個，就是在問卷分析的時候一定要重視對問卷基礎數據的分組。因爲如果大家做過數據分析的話，就知道數據肯定是要從各種維度穿插着看。所以你們看那個 BI 系統裏面都會有多維分析數據的下鑽上選，從不同維度穿插着看數據才能看出背後的一些真實問題。如果你沒有從多維的角度去分析的話，你只看一個大數是沒有任何意義的。所以在問卷設計的時候一定要放一個鉤子，就是最後分析問卷的時候要把你分析數據的穿插的維度給設計好。
上圖是我以前做的一個 B 端產品經理生存情況的調研問卷，這是整體的一個大數，就是最近一個月每天的下班時間，旁邊也給出來一個數據統計，但是這個數據統計其實看得還不夠細，很多有趣的結論從這個大數是看不到的。
其實我當時在設計這個問卷的時候已經想到了要把產品經理分類， SaaS 的、國企的、互聯網的、IT 的等等，通過分類就相當於做了一次維度的下鑽。我是從產品經理的行業做了一次維度下鑽以後去看他們的下班時間，最後明顯看出來國企下班早，最底下就是下班時間越來越晚，這個數一下就有意思了。
所以在問卷設計的時候，一定要做好這種鉤子，就是包括這種維度的設計。沒有這個維度的設計，你拿一個大數是分析不出來什麼有意思的問題的。
接下來我們來做一個思考，比如說我想針對一個公司的銷售人員去做問卷分析，就是結合我這個案例，我想對銷售進行一個維度上的劃分的話，請問有幾種劃分維度的方式？其實說白了就是可以對這些銷售人員通過哪些方式進行分組。你們可以思考一下，看看是否至少可以說出兩種以上。
當時現場有位同學回答說：首先可以按地域去劃分，比如負責華南的、華北的這些，然後還可以根據銷售人員所銷售的產品的維度去劃分，另外可以根據這個銷售人員所負責的客戶羣體，比如說是大中型企業還是小型企業等這些維度去劃分。
我在這個基礎再補充了一下，其實還有可以分的方式就是從他的業績來分。銷售業績厲害的是一檔，差一點的是一檔這樣。還有一種分法很重要，就是從司齡來分。這個其實對調研的影響非常大，比如說一年以上的、半年到一年的。
這個些分法在問卷設計裏應該就變成了一個基礎的選項，當然如果你們公司是自己公司做調研的話，這個數據只要銷售填個郵箱什麼的，後臺也可以跑出來，但關鍵大家要有這個意識，就是要有這個維度數據的準備。因爲它對你後續做各種多維的數據洞察是非常重要的，這是調研時必須要重視的一個點。
上圖是我們當時這個案例裏產品經理設計的一個問卷，就跟我剛剛說的差不多，都是通過打分的方式對滿意度做調研。
04
通過焦點小組完成可用性分析
現在，在這個案例裏產品經理調研完了，其實相當於到現在爲止還是在排查問題的一個情況，不論是從數據去看體驗問題，還是從聊天、溝通、訪談去看對體驗問題的意見，或通過調研來看，它都是在摸底。
那下一步呢？產品經理要做的很重要的一步，也是這種用戶體驗類優化的難點，就是如何設計這個交互，讓用戶更喜歡用這個產品。最經典的一種辦法就是做焦點小組了，焦點小組其實是做產品可用性分析很重要的一個手段。
簡單來講就是產品經理拿着已經設計好的幾套交互方案，把幾個人攢在一個屋裏，讓他們前後做幾套問卷，先讓他對老的這個交互打分，然後給他一套新的交互，演示完讓他們靜默打分，再演示一套再靜默打分，最後對比出來哪一套得分高。注意，這個是焦點小組比較好的應用方式。
焦點小組不是找一堆人做茶話會，肯定不能這麼用，茶話會你一言我一句，最後可能意見就趨同了，是不能這麼用的。焦點小組其實更多的還是用來做這種可用性分析的。
那在這個調查用戶對不同版本設計的主觀評價的時候，可以用 NPS 這種積分方式，這個在企業裏面已經很常見了，不論是企業服務還是產品設計都會用。比如說左邊就是 Photoshop 的一個 NPS 調查表，其實很簡單，就是說你願不願意把這個東西推薦給其他人，10 是最願意，0 是非常不願意，讓大家打個分，最後用 9 分、10 分推薦者的百分比減去一個貶損者的百分比得出淨推薦值，來通過這種方式進行打分分析。
在拿了好幾個版本打完分了以後，我把老版的和一個最滿意的版本取出來，如上圖，老版的滿意度是 63%，新版的是 81%。這樣至少讓我們心中有譜了，就知道這個東西該怎麼去改是方向沒問題的。但這個還是需要很謹慎的。
05
確定方案落地並跟蹤
下一步你要執行這個具體的改造計劃，包括設計出來以後其實最關鍵的還是先做小流量，做灰度不能一下全量上，做完灰度以後，一個是繼續優化，還有一個就是再要正式收集一次 NPS。
所以上圖這是做了一個方案設計。
然後又定義了項目的執行計劃。
最後上線了，看這個效果很成功，領導也很開心。
我們看幾個數據，首先就是衡量它的效率提升。上圖左邊就是當時上線完以後就去衡量了一下拜訪記錄這個功能使用的時長，平均錄入時長是下降了，那說明其實錄入效率還是提升了。而且這個效率從 11.07 秒下降到 10.37 秒，可能聽起來不就下降了零點幾秒嗎，聽起來沒什麼感覺。但是把它轉化成百分比，如右邊，效率提升了 10%，錄入時長下降 10%，這個感覺就一下不一樣了，這就是數據分析的技巧。
再看這個圖是不是一看也感覺很振奮人心？我們可以再思考一下，爲什麼這個圖讓人看起來覺得這個項目很成功？當時現場有同學說是因爲一下就可以看到產生的這個效果有多好，也有同學說圖中把基數就定爲 10，差距定得比較大，所以兩個柱子拉開的距離就大。那我說，一看這位同學平常就特別會寫報告。
大家看明白了嗎？就是把這個縱座標基數從 0 改成了 10，然後這個圖的差距就拉大了，否則的話你放在一個正常 0 開始的座標系下，這兩個柱子應該是差不多高的。這裏是順便講了一下作圖上的小技巧，大家謹慎使用，但很重要，因爲它確實對別人看這份報告來理解這個情況是有一個直觀影響的。
再這個滿意度，從 26% 提升到 31%，感覺好像不就提升了五個點，當然不能這麼說，你應該相對來講提升了 20%，這數一下就大了。
這就是我今天分享的內容，其實就是講了一些小技巧給大家。
關於我們
首席產品經理是 Boolan 旗下連接 30 萬 + 中高端數字化產品與創新領域的產品骨幹、產品經理、產品總監、CPO 和國內外產品專家的高端技術交流平臺。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Rm58TnNiV0HRPKrERb0u4A