寫完上一篇 實踐版 | B端用戶訪談的20條心得（前10條） 后，很多小伙伴私信知果覺得看了很有收獲（知果當然很開心啦~）。由于最近事情較多，這篇更新有點慢了，還請小伙伴們見諒哈。那話不多說，接著上一篇我們再來看看B端用戶訪談調研還需要注意哪些。
在訪談中你會發現，有可能用戶的知識面是非常廣的，他提到的問題我們可能未曾想過，或根本不知道。此時，我們會產生想把問題搞明白的心態。可能有小伙伴要問了，假如我不明白這個問題，去問用戶，會不會讓用戶覺得我什么也不懂呢？
其實你不用擔心，既然用戶受邀了訪談，就不排斥與我們溝通。并且他希望自己反饋的問題，是可以被真正得到重視和解決的。記得曾經有個受邀訪談的用戶和我說：“我最擔心的是你訪談了我，但卻不對我提出的問題重視，并在后續改進。而是訪談完，就把問題擱置一邊了。”
可見，我們在訪談中可以與用戶真心地交流，不用害怕不懂而不敢問。我們要把用戶說的問題搞懂，并且給出達成共識的解決方案，才是搞懂問題的根本。
我在訪談中經常會出現這種情況，和用戶聊著聊著，會希望調整訪談的內容。例如，有些問題覺得已經解決了，就想跳過；有些問題原來沒想到，想在訪談中增加。
依據我的經驗，我認為訪談內容在可控范圍內，是可以做一些調整的。我們無需根據原來列好的訪談大綱，照搬來做。畢竟，訪談的雙方都是活生生的人，而不是兩個機器人，我們在訪談中需要根據用戶表現出來的相關信息（如表情、肢體動作、言語等），做一定程度的調整。
我們心中要始終明確，任何訪談內容，最終是為了訪談目標服務的。在訪談目標范圍內的調整，都是可以接受的。
我們在用戶訪談的一些文章中，會看到說，我們盡量不要讓用戶發散思維，而是要在我們劃定好的訪談范圍里面進行。若用戶不小心跑題了，那我們需要把他們的思緒抓回來，回到本該訪談的范圍里。
我在實際訪談中發現，假如你和用戶在訪談前提前達成了訪談范圍，那跑出范圍的概率也不會很大，最多是用戶通過A問題引申到了B問題，而不會故意去談一個B問題。此時，我們可以允許用戶發散一下思維，這對我們更全面地了解用戶的所思所想是有益的。
但若出現用戶直接談到了B問題（他能談到，說明他比較在意這個問題），我們盡量不要打斷用戶，讓用戶說完。等用戶說完后，我們可以看下這個B問題是否屬于自己可解答的范圍，是的話，不妨簡單解答下，接著將話題引回到本次訪談中。若不屬于自己的負責范圍，可與用戶溝通自己會記錄下來，帶回去反饋給相關負責人，后續會聯系用戶。
有時候，我們訪談的內容是針對界面操作的，那么就非常有必要讓用戶現場演示，而不要通過口頭描述來傳達。若通過口頭傳達，一方面，我們理解的可能與用戶描述的有偏差；另一方面，我們回去自己找場景驗證，也容易找錯。
這就對應了上一篇中的第7條，我們需要提前羅列合適的訪談環境。若預見到可能需要用戶進行界面操作的，那么就需要提前準備電腦。如此，在訪談時，針對某些溝通內容，就可以直接演示界面現狀了。
我在最開始訪談時，經常是用戶演示界面上的一些問題，我用筆記下來的情況。之后，我再自己到電腦上找用戶當時說的問題是哪些，逐一截屏記錄下來。但我發現，回去后我可能壓根找不到用戶當時演示的問題了，我就只能用文字描述，但這不利于場景復現與排查問題。
因此，我們在訪談時，就可以和用戶溝通在信息脫敏的情況下，保留一些關鍵頁面，可以是截圖，也可以錄制視頻。
我的習慣是，不論開會、與同事溝通，等等情況，都會拿上本子和筆，將一些關鍵信息記錄下來，用戶訪談也不例外。
古話說：“好記性不如爛筆頭。”確實如此。人的記憶容量是有限的，特別是短時記憶的容量，更是非常有限。而且對于有些信息，你現在覺得自己記住了，可回過頭來卻發現你從未覺得它們存在過。
用戶訪談長則需要2-3個小時，若我們一天訪談2-3個用戶，那幾乎一天大腦都在處理信息。因此，想要在事后將這些信息都回憶起來，我們就必須要依靠本子和筆的幫忙。
用筆和本子記錄訪談關鍵詞，結束后立馬整理，復現具體內容。
很多用戶訪談文章指出，在訪談結束環節，建議給被訪談人送個小禮物。我的感受是，對于被訪談人來我方公司的情況（專門受邀訪談的），可以送小禮物，還可一起吃個簡餐。如果是我們到對方公司，可能帶上禮物并不方便，就可以從言語上、肢體上（如握手）對用戶做出感謝。
當然，這都不是唯一答案，我們可以根據實際情況需要，做出真心地感謝。
打鐵要趁熱。所以，當一天的訪談結束后，我們需要及時梳理訪談內容，把與用戶談到的問題，盡可能的還原和記錄。如果思路清晰的話，還可以將同類問題合并起來，讓信息盡量精準，不冗余。
我有時候一天可能訪談不止一個用戶，因此我會根據實際情況，在訪談完一個用戶的空隙時間進行內容整理。這時候記憶是最清晰和深刻的，稍微晚一點時候，可能就回憶不起來了。
關于內容的梳理格式，用excel、word還是其他工具，都可以，只要能把問題說明白即可。
每次訪談完，我們都可以思考下是否本次訪談還有不足之處，是可以改進的。
記得有一次我訪談一位事業部的BU總，我覺得自己準備的已經較為充分了，包括產品核心理念、產品原型、本次訪談的主要問題，等等。而且在我去訪談前，各種要注意的事項我都再檢查了一遍。可真正訪談中我發現還是有很多意料之外的事情出現了。比如，BU總希望不只看到原型，還希望看到原型交互的效果（至少是核心交互），否則他還需要自己想象。再比如，他希望知道業界競品是怎么做的，但當時我對這個準備并不充分，因此沒有很好的回答他。
之后，我在訪談中會評估是否有必要把原型做成帶交互的，若需要，就把交互做出來。或者也會做成視頻，方便用戶理解。
我們訪談后回憶整個過程，若發現還有待改進之處，可以梳理出來，在之后的訪談中盡可能規避這些問題。當然，我們也要根據下次訪談的實際情況調整，并不是一股腦兒都改進到下次的訪談中，要具體問題具體分析。
其實這不是訪談后立馬要做的，而是把每一次訪談當成產品未來規劃的輸入。若訪談中合適納入到產品規劃的，可以把這些零碎的點進行整理，讓這些點的需求形成價值。
記得在一次關于設計體系表格功能的用戶訪談中，用戶提出了很多我曾經并沒有考慮過的功能（因為我服務的場景并不需要這些功能）。后來我也找了很多競品，發現也并未有這些功能。可仔細思考發現，這些功能確實可以解決某些特定場景的問題，因此我將它們規劃到了產品中，也可以說這是該表格的特色。
最后，分享給你一個小框架，是關于單問題調研的，我將其稱之為4步法。
第一步：描述事實： 讓被訪談者描述此問題發生的客觀情形。
第二步：內心感受： 讓被訪談者對該問題描述自己的感受。若感受非常不好，則可以描述為什么不好的原因。
第三步：使用場景： 讓被訪談者描述該功能/菜單在什么情況下會使用；還可以談談使用頻率。
第四步：解決方案： 讓被訪談者簡單聊聊他對此問題是否有建議的解決方案（若其描述不出來，也無妨；我們要是立馬感覺有解決方案，可以主動與用戶探討）。同時，該方案是否被接受，需視情況再定。
為了方便大家回看「知果日記」的往期文章，我做了一份「知果日記」日·常·分·享·錦·集，會持續更新，歡迎你收藏和隨時查閱。關注公眾號，聊天窗口發「錦集」就可以領取鏈接。
好啦，知果今天的分享就結束了，如果你喜歡今天的文章，歡迎點贊 + 在看 + 分享；如果你想和知果進一步交流，也歡迎下方 加我微信， 一起交流、進步~
我的書籍與你分享
這是在我從業6年之際，寫的一本合適B端從業者（產品經理、設計師、研發工程師等）的入門書籍 《B端思維-產品經理的自我修煉》,已經再印數次。
前些日子，有一位剛入門B端沒有人帶的小伙伴，因為認認真真自學了《B端思維-產品經理的自我修煉》，不僅形成了自己的B端認知體系，也幫助他找到了更好的工作。當他和知果說到這事兒的時候，知果真的很為他開心。
還有一些剛入門B端的小伙伴，看了書以后，對B端的認知有了很大地提升，在工作中更游刃有余了。
