研究用戶，需要透過用戶的語言、行為 去了解他們內心深處的需求，排除偽需求，篩選真實需求，也就是透過現象看本質。這都需要產品設計者始終保持一顆同理心與開放的心態，有時用戶的“是”與“否”也許是提問方式的不同導致的，是非判斷只在一念之間，不具有決策性，關鍵是要挖掘用戶的核心訴求。
有些產品或功能看似很“簡單”，但是越簡單的東西設計越難。在“體驗設計”逐漸被國內互聯網公司和設計師們重視的現在，我們或許更能體會到設計的“本質”。在當今環境下，不能僅僅是提供產品和解決辦法，而是要提供用戶想要的產品和服務。
用戶研究的方法有很多，如何對這些方法進行選擇，應該根據研究目標而定：
今天我們來聊一聊用戶研究中最常用的、和用戶面對面的：用戶訪談
一、什么是用戶訪談
用戶訪談在過程中可以與用戶有更深入、更專注、更有質量的交流，通過面對面溝通、電話、網絡視頻、問卷等方式都可以與用戶直接或間接進行交流。
深入探索被訪者的內心與想法，容易達到訪談的效果，并發現一些現有的問題和優化方向，因此也是比較常用的用研方法。用戶訪談一般在被訪者較少的情況下使用，常與問卷調查、可用性測試、A/B測試、眼動測試、產品體驗會等方法結合使用。
根據不同的研究目標，訪談可以分為結構式、半結構式和開放式：
結構式：訪談員拋出事先準備好的問題讓被訪者回答。為了達到最好的效果，訪談員必須有一個很清晰的目標，整個過程需要引導被訪者不偏離主線任務，提出的問題也需要經過仔細推敲和打磨。為了準備高質量的問題，可以列出所有問題讓有經驗的觀察員評估，甚至可以小范圍組織一波演練都是有必要的。
半結構式：結構式訪談和完全開放式訪談的兩種形式的結合，也涵蓋了固定式和開放式的問題。為了保持研究的一致性，訪談員需要有一個基本的提綱作為指導（訪談劇本），以便讓每一場訪談都可以圍繞主線任務。在開始之前，訪談員和觀察員認真學習一些訪談技巧也非常重要，文章后面會單獨對這一塊進行強調。
開放式：訪談員和被訪者就某個主題展開深入討論。由于回答的內容是不固定的，所以被訪者是根據自己的想法大致描述或簡短描述。但需要注意的是，訪談員和觀察員心中要有計劃和目標，盡量讓話題圍繞主題進行。有時，一些活躍的用戶會提出新的idea，因此訪談員需要控制訪談節奏，避免偏離主題。
二、為什么要做用戶訪談
常見的問卷調查和數據分析雖然可以覆蓋大面積的用戶群體，獲取更大量的用戶行為和數據情況（定量研究），但無法深入了解用戶做出某種行為的具體原因和場景。比如數據分析，我們只能知道在這個時間點APP活躍度下降，或者這個頁面跳出率增加，卻可能無法了解到用戶這樣做的實際原因和場景。而這個時候，用戶訪談就可以起到一定的補充作用（定性研究）。
再比如：最近用戶流失較嚴重、了解用戶有哪些新的需求和痛點、即將上線的新功能通過產品體驗會的形式做訪談，觀察用戶的使用情況等。
不同的產品階段，訪談的價值各有不相同：
1、當你還不知道功能該如何優化的時候，幫你發現新的機會；
2、當你對設計的產品有些想法的時候，幫你優化想法；
3、當產品已經面世的時候，幫你找出現有問題，并推出新的服務；
4、自己發現了一些產品問題，但不知道是否遺漏，幫助你發現設計盲點。
總之，就是用戶幫你尋找設計的機會點，然后你去做產品規劃
三、前期準備
1、明確研究目的和主題
訪談目的避免出現假大空的情況，比如說“小王啊，你幫忙對本APP用戶做針對性調研。”這就是背景目標都不明確。這時候要去溝通并明確目的，盡量把目的和背景范圍縮小，再做進一步的設計規劃。
假設詢問后得知：是因為新功能剛上線，想了解用戶在使用過程中有沒有遇到什么問題，是否符合他們的使用習慣。
那么在對用戶的訪談中，就需要詢問他們的使用流程：怎么發現入口、如何使用、還有沒有更好的展示方式等。
就像交互設計師與產品經理溝通需求時 也類似訪談，接到模糊需求時，先對需求方做一次訪談，明確他們的目的、背景、想解決什么問題，接下來才能動手設計解決方案。
在明確研究目的的同時，還要明確主題。訪談員和觀察員要盡快熟悉相關知識、對應的產品、訪談劇本，因為用戶一般都是對該主題或者產品有一定了解，如果組織人員都不熟悉這些內容，就會直接影響訪談的質量和進度。
因此，良好的訪談質量不只是取決于訪談的技巧，還取決于組織人員對訪談目的的了解，以及訪談主題的熟悉程度。
2、設計訪談提綱
明確訪談目的后，就要基于目的與受訪者，擬定訪談清單。在設計清單前，先問自己：
（1）我問這個問題的目的是什么？
（2）能去掉這個問題嗎？
（3）用戶能不能舒服地回答這個問題？
注意：所有問題必須要指向設計改進的價值
你可能會問，假設這個訪談提綱只能覆蓋90%的訪談內容，那么剩下10%的內容怎么辦呢？也許遺漏的內容里面才會有真正的痛點。
其實，真正執行過訪談的人都知道，訪談提綱一開始很難做到100%全面覆蓋，需要在實踐中逐步完善，通過與用戶交流，把新發現的點子補充進去，很快你的訪談提綱就能得到完善。
這里需要強調幾個注意事項：
1、由易變難，由淺入深，打開“心門”
最開始要設計一些簡單的問題，拉近與用戶之間的距離，建立信任感，營造輕松的訪談氛圍，這個過程可以稱為“開心門”，通過“開心門”的過程和用戶形成良好的互動。如果一開始就交流很難的問題或操作，用戶容易產生恐懼、不自信、多慮等負面情緒，這時“心門”就會關死，不利于后面訪談的深入。
2、發散到聚焦，先邊緣再核心
先從開放性的問題切入，不要一下子把問題限的太死，否則容易把用戶關進思維的籠子里。等對答逐漸往一個方向聚攏后，再漸漸往里收縮，重點追問核心問題，才能獲得更有價值的信息。就如同人與人溝通，都是先扯幾句有的沒的，再切入主題的道理是一樣的，其實我們都知道這樣很虛假（有啥事情直接放=_=）但作用還是顯而易見的。
3、描述要通俗易懂，避免專業詞匯。
不同的用戶群對訪談主題的了解程度不同，對于“專業型”用戶相對了解較多。但對于小白用戶、目標用戶，過多的專業術語會使訪談變得不順暢，導致用戶不說真話、消耗時間。
比如“您覺得這個APP我們要做iOS還是Android系統”，別問了，用戶沒辦法回答這種問題。任何涉及技術和設計層面的決定，本來就不該拋給用戶。
實際上他們最大的需求只有一個：盡可能減輕使用中的麻煩，讓我達成目標就行。
如果你是想得知用戶在使用手機時的舒適度，你完全可以這么問：“您目前在用什么手機？您覺得它有哪些好和不好的地方？”。
所以，無論你是產品經理、交互設計師 還是 UI設計師，都是產品的設計者，設計出用戶看得懂的語言是基本功，記?。河脩趔w驗無處不在。
4、控制時間和數量
通常一對一的訪談應控制在1個小時之內，多對多則控制在2小時之內，太長的訪談時間容易對用戶會造成負擔和疲勞，用戶會為了趕緊結束交流而不經思考、草率回答（emmm…有高顏值的妹子做觀察員可能會緩解這種情緒^_^）。如果要讓用戶上機操作，就要事先做好清晰明確的操作說明和指引，盡量讓用戶在一個輕松的場景下完成操作。
四、用戶招募的三大流程
1、訪談對象從哪里來
并不是每個團隊都有充足的時間和資源去準備訪談、邀約用戶，但我們每個人都是產品的用戶，一般的功能迭代完全可以優先考慮身邊符合用戶畫像的同事，因為彼此間有一定的了解，邀約和溝通的成本會小一些，當然最好是“小白”用戶，不然參與者都對產品非常熟悉，那就不是訪談，而是產品討論會了。
其次可以從種子用戶中征集和邀約，種子用戶本身就是產品第一批使用的對象，邀請他們做訪談對優化產品和推廣有一定的幫助。
2、篩選目標用戶
要注意的是，篩選訪談對象要注意平衡，避免同一類型的對象占了過多比例，導致訪談結果不全面，我們需要根據不同的用戶角色模型去篩選訪談對象。
例如做一次關于視頻社交APP的功能優化訪談，就要避免對象大部分是已婚、80后的情況，因為已婚用戶不是目標用戶、80后用戶的需求頻率不大。
很顯然，90后/95后/00后、大學生/剛進入職場的單身男女才是我們的目標用戶，那就根據這類人群的角色模型來篩選邀約對象。
如果之前沒有用戶角色模型作為基準，沒關系，可以先做用戶訪談，后期對完善角色模型也有幫助，兩者互不干涉。
用戶角色模型的制作可以查閱我之前分享的文章《用戶角色模型 | 拒絕“我認為”的設計》
3、邀約用戶
要提前和訪談對象約定合適的時間和地點，為了保證訪談效果，盡量約在訪談對象比較空閑或輕松的時間段。有時考慮到產品保密的情況，可以采取前面說的方法：邀請公司內部成員體驗，這也是比較敏捷的方法，可以快速得到產品設計中的一些問題和用戶建議。
記得提前準備一些合適的小禮品，比如產品里的限時會員、活動門票、優惠券什么的，這樣既能表示感謝，也可以宣傳自己的產品（關鍵是比較節約成本）。
五、現場訪談技巧
做完一切準備工作之后，我們就可以進行現場訪談了，做過訪談的同學都知道，偶爾遇到幾個不知道如何表達的用戶，如果沒有良好的訪談技巧，這時氣氛會有些尷尬。為了更好地引導用戶“說真話”，有什么技巧呢？
1、開場介紹
介紹訪談的背景、流程、內容、時間。告訴用戶今天的討論無對錯之分，任何疑問，對你們來說都是改進產品的重要信息，請暢所欲言，不要掩飾真實的想法，要讓受訪者明白不是為了迎合你 而做出與真實情況不一致的反饋，同時你要告訴用戶整個訪談都會保密，用戶的回答只會在研究中使用，如果要使用，也會采用化名或者匿名處理。
2、訪談中的八項注意
（1）傾聽用戶，不要隨意打斷，也不要給用戶關于產品上的解釋。
用戶是你產品的使用者，而你正在努力理解他們的世界。所以用戶在訪談中發言的時候，一定要仔細傾聽，不要打斷。如果你有有任何問題，可以等他們講完后再提出來。畢竟一旦你打斷了他，很可能會錯過一些對你十分珍貴的信息哦。
另外，如果你一直在試圖解釋用戶挑出的問題（毛?。?，試圖說明那些問題該怎么做，責怪是用戶的無知所造成的后果，并給用戶一些建議去完成產品使用上的目標。結果可想而知，一場與用戶面對面珍貴的訪談會，由于你失敗的情緒管理，變成了一場討論會、辯論會。此時此刻，不管你是PM、UE、UI，你的職責始終都是抱著解決產品問題的心態 去傾聽用戶，而不是解答產品問題。
（2）不要跑題，你來控場。
訪談過程中，有可能吐著吐著，變成吐槽大會了（親身經歷，撕逼有害健康），這個時候你需要把用戶拉回來，不要被用戶帶著跑偏了，訪談員就是主持人，不僅要學會傾聽，也要把控整個訪談過程。
（3）注意引導，而非誘導。
不要對用戶提出誘導性的問題，比如“支付按鈕在這里會不會不好用”，或者“很多人都認為這個功能不好用，你覺得呢？”通常這么問的話，用戶可能會產生從眾心理，只會說出你想要的答案，而不是他們內心的真實想法。
我們可以用開放式的提問方式“請你選擇一個你需要的套餐，然后進行支付”、“假如為這個功能打百分制，你會打多少分？為什么呢？”。
然后在用戶操作或回答的時候，我們注意觀察用戶的操作行為和情緒，比如“花了多長時間找到支付按鈕、在頁面停留時 面部表情是否有變化”（這里要做好記錄，所以為什么前面會提到觀察員這個角色）。
通過看到的、聽到的 可以綜合判斷出：是視覺引導性不強、是交互流程太復雜？還是產品性能較弱等易用性問題。
是的，古話都說爛了：設計師要懂心理學~
（4）引導用戶講“故事”
訪談的過程，我們要多傾聽用戶的想法，才能挖掘到用戶的需求和痛點。所以很多用戶遇到的問題，我們要盡可能引導用戶以講故事的方式，說出他的使用場景與行為，比如“這個問題對你有多大程度的影響、當時是如何解決的、結果怎么樣、什么情況下會使用這個功能等等。
把問題放到具體情境中，才能幫助我們了解用戶，并從中獲取我們需要的信息，讓用戶幫產品做設計。
（5）幫助用戶定義“說法”
用戶在描述一件事情時，會經常用到比較模糊的詞語，比如說“我覺得支付功能太復雜”，這時候，我們需要用戶對自己說的“復雜”進行定義，可以反問用戶“復雜是指找不到支付入口？找到了不會用？不知道優惠券規則？還是其他什么的？
當用戶描述自己觀點的時候，還可以對該問題繼續深挖，比如用對比和缺失的方法，引導用戶說出更多的想法。
對比方法：“對比其他產品的支付功能，這個功能還復雜嗎？哪里復雜？”或“之前沒有這個功能相比，你覺得這個功給你帶來什么變化？”
缺失方法：“如果沒有這個功能，你會怎樣達到自己的目標？”
（6）獲取用戶真實訴求
很多時候，我們給用戶做訪談，用戶可能只告訴我們淺層的信息，比如“我想要個xxx功能”，這時很多訪談者就不會往下追問了，所以我們獲取到的信息還不足以推動產品質的優化。
這時我們可以采用梯子理論，挖掘用戶深層想法，從而證實用戶說的“想要xxx功能”是否合理，或者看能否想到其他解決方案。
（7）做好訪談記錄
好處：方便事后存檔查閱、方便訪談后對用戶需求進行分析總結、功能設計的有力依據。
在用戶允許的情況下，還可以對訪談過程進行錄音，方便后期對原始場景還原，也能繼續琢磨、回顧當時用戶所說的話
訪談記錄只做一手記錄，切勿融入自己的主觀判斷和感受，比如“用戶認為某處的顏色過于沉重，那記錄的結果也是顏色過重，而不能得出把某處顏色提亮的結論。
（8）保持跟進，留條后路
訪談結束后，記得真誠的感謝用戶所提的建議，并把你之前準備的小禮品送給用戶。事后也可以與用戶保持聯系，或者通過用戶實現你想要的其他目的。把關系維護好，后續可以把你的產品原型發給用戶，進行可用性測試；或者你回去整理訪談記錄時，發現有個需求沒有搞明白用戶的動機，可以再追問用戶一個“為什么”。如果你希望訪談其他的種子用戶，也許可以讓當前的這位用戶轉介紹呢。
六、分析整理
訪談結束后，及時對訪談內容進行轉錄并整理。這里說的轉錄是指將口頭語言轉化為書面語言。轉錄的目的在于方便日后回顧、供相關人員參考。及時整理可以將記憶輸出最大化，另一方面減少所有訪談內容堆積在一起整理的壓力。
個人的心智是有限的，大家一起討論更能發現用戶的真實想法，可以將整理好的訪談內容做個用戶分析報告，提取出用戶獨特的信息進行分析，把分析結果拆解，哪些是產品需求層面的、哪些是設計層面的、哪些是技術層面的，只有把維度細分了，才能有效地規劃迭代計劃。
下面是我整理的一份分析報告（附源文件）：
請牢記：訪談的最終目的是行動！如果發現的問題不能被解決，久而久之成為成泡影，那么即使是最成功的用戶訪談，對利益相關者來說也是一文不值的，因此成功交接用戶訪談結果對整個團隊而言是至關重要的，而一份成功的用戶訪談報告應當方便產品團隊記住研究中的關鍵點，并將其投入使用。
訪談雖然有套路與技巧，但能否通過訪談獲取到用戶真實的信息，還要靠多做訪談，不斷精進。每次做完訪談都要復盤，和我們做設計一樣，多總結、多回顧。
以上便是我學習用戶訪談的一些總結，希望對你有所幫助。其實訪談是一門很深的學問，涉及到的知識和技巧有很多，后續還會再總結更加細致的心得體會。讓我們共同離用戶更近一些。