在 軟體開發的用戶需求哪裡來？ 介紹了很多軟體開發時，蒐集需求的方法，但每個蒐集方法得執行方式都不同，今天要來分享其中一個方法 - 用戶訪談 得執行方式。

為了能夠更貼近用戶的想法與使用需求，因此在軟體業擔任產品經理的我，會透過訪談的方式來了解以下內容：

1. 了解特定一個功能下，優先需要優化或調整的操作環節
2. 了解用戶目前最需要的產品功能是什麼
3. 了解特定業態目前產品的使用需求

往下會進一步說明，我是怎麼執行用戶訪談的，主要會分成以下幾個環節：

• 一、訪談目的
• 二、訪談策略
• 三、訪談對象
• 四、訪談大綱
• 五、準備問題集
• 六、訪談過程
• 七、訪談紀錄

一、訪談目的

雖然前面有說，透過訪談能夠了解到三個面向的內容，但真的要執行訪談時，需要釐清一下為什麼要做這件事情，是為了 探索新的軟體開發方向，或是 了解特定一個軟體功能可以優化的方向 等，畢竟訪談非常花時間，不管是用戶的時間還是產品經理的時間都很寶貴。

二、訪談策略

確定好前向的目的後，要 breakdown 到下一層可以達到目的的策略是什麼，例如 需要找特定偏好的用戶做訪談、找尋已經有類似使用經驗的用戶做訪談 ，或是 透過正向和反向的問法驗證用戶的使用需求等。

三、訪談對象

因為軟體業的用戶有很多的類型，因此在大方向尋找訪談的對象時，要先確認一下什麼樣的用戶輪廓能夠回答想要達到的訪談目的，大方向可以用以下幾種類型來區分：

• 有特定使用經驗的用戶
• 對特定軟體功能有需求的用戶
• 抱怨特定軟體功能的用戶
• 很有使用想法的用戶

確定完方向後下一步是要找出適合的人選，之前的經驗是能夠透過以下幾種方式找：

• 透過系統資料找出適合的人選
• 透過功能建議的內容找出適合的人選
• 業務夥伴的推薦

四、訪談大綱

根據訪談的目去發想訪談的題目，因為在訪談當下，受訪者可能會很難想像產品經理要詢問的內容，為了幫助受訪者思考，建議先請受訪者分享曾經的發生過或是使用過經驗，透過已經發生過的事情，讓受訪者能夠依循一個脈絡思考。

若是想要了解用戶的使用需求，或是了解用戶為什麼抱怨某個軟體功能不好用，建議直接請受訪者分享使用情境，透過情境的方式去尋找用戶的核心痛點。

如果怕訪談的題目會讓受訪者誤解方向，能夠再多設幾題問題，而新增的問題可以和其他題目互相驗證。

五、準備問題集

為了回饋受訪者花心力協助訪談，通常會在訪談的過程中，留一小段時間給受訪者，讓受訪者發問，因為在訪談當下，很難預測受訪者會問的問題是什麼，建議能夠提前準備一些問題集，避免當下被受訪者問倒回答不出來，若是當下真的發生回答不出問題的狀況也別緊張，能夠先收下受訪者的問題，使後確認完答案後再回覆給受訪者。

六、進行訪談

破冰暖場

準備完那麼多的前置作業後，終於要正式進入訪談的環節，通常會希望整個訪談的過程不要太過僵硬讓受訪者不自在，因此前面會先安插個 破冰暖場 的環節，先和受訪者介紹一下此次訪談的目的，而產品經理平常主要負責的部份是什麼，並和受訪者聊一下近期軟體的使用狀況，等到受訪者心情稍微放鬆後就可以 進入正式的訪談。

隨機應變

在訪談的過程中，其實非常的緊張刺激，因為這時候非常考驗產品經理的應變能力，需要根據不同的受訪者的類型，隨時調整訪談方式

• 第一種類型，非常喜歡分享的受訪者

  要好好控制時間，適時的幫受訪者收尾，不然非常有可能發生訪談時間已經到了，結果用戶還沒回答完。

• 第二種類型，不愛講話的受訪者

  要想辦法換個問法讓受訪者多說一些，從中交叉驗證確認受訪者回答的方向和需求。

• 第三種類型，很容易離題的受訪者

  要記得想辦法讓受訪者回到主幹道上面回答，不管是用引導的方式，或是換不一樣的問法來詢問都可以，這邊要小心用引導的方式不能讓受訪者最後順著自己的脈絡回答下去，所以還是要適時的讓受訪者能主動的發想和回答。

七、訪談紀錄

在訪談前，要先和受訪者確認是否可以錄音，方便在訪談結束後回放內容，在訪談時同時需要有另一位人員在現場做紀錄，會需要有錄音和記錄手的原因是紀錄只是當下快速寫下重點，但事後整理訪談內容時，很有可能忘記當時紀錄的意思，因此會需要回放錄音的內容還原當時的狀況。

以上七大點就是自己在軟體開發過程中，執行用戶訪談的方式，一開始覺得用戶訪談應該很簡單，就像是和用戶聊天，沒想到真的執行過幾場後非常的不容易，中間有很多的小撇步而且非常燒腦。