Dcard實習生活日記：使用者訪談！？別再犯這些錯誤
前言
Hi，我是 PM Team Intern 的 Weiwei，
今天想跟大家分享訪談的注意事項，好的訪談能幫助驗證專案的假設，也更能獲取發想時所遺漏的洞見。
介紹
推行專案之前，PM 會跟設計師們一起 brainstorm 流程，設計 UI/UX的 prototype 。從便利貼貼滿整面白板、分類、刪減，到做成基本的 prototype ，我們會設法以各種工具驗證假設的正確性，使用者訪談為一常用手段，以最直接的方式了解使用者操作的習慣，再修正原型做出擁有最佳體驗的產品。
從訪談想得知的訊息，可能是某個按鍵的直覺路徑，也可能是視覺上的修正，抑或者日常使用 app 的順序習慣。訪談的過程中，有許多值得注意的地方，舉例來說，專案的發想設計者，很有可能會因為先前討論時推敲出的結論，擅自假定使用者的行為，因而在問問題時誘導受訪者道出自己心中的答案，這樣的訪談結果參考價值較低，也不容易從中有新的發現。
以下是一些訪談時需要避免的情況：
1. 別急著解釋自己的設計
面對一個新的功能改變，訪談者在展示 prototype 時，不用急著解釋自己的設計細節，可以詢問受訪者「你覺得這是什麼？」，更能得到自己意想不到的回答。受訪者所提供的答案，很有可能是更直接、符合直覺的設計。
2. 不應否定使用者的回答
假定受訪者在看完 prototype 後，認為某個按鍵觸發的功能跟自己初始的設計理念不同，訪談者也不用去直接了當地否定受訪者的回答，此舉很可能造成受訪者信心受挫，不敢誠實回答接續的提問。
3. 發問不應引導使用者回答
不應詢問「你覺得這個功能棒嗎？」，而是改成問「你覺得怎麼樣？」更能聽到真實的想法。通常，使用者面對「你覺得棒嗎？」的提問，多半不願破壞訪談氣氛，不太可能提出「我覺得不棒。」的回答，因此，引導式的提問，幾乎只會得到迎合式的答案。
4. 不應問使用者沒想過的問題
除了不該引導式提問，同樣的也不該問使用者沒想過的問題。當訪談者丟出「哪個比較方便？」的問句，若受訪者對某一個功能的感受是「有趣」，與方不方便無關，在聽到訪問者的提問後，才開始思考此功能是否方便，這樣一來，受訪者情急下提供的答案，不論方便與否，都很有可能是為了應付訪談者所編造的答案了。
5. 不應幫使用者舉例
以使用的社群軟體為例，應直接詢問使用者「你最常用哪些社群軟體？」，而非問「你常用 Facebook, Instagram 這一類的社群軟體嗎？」，舉例式的提問容易將使用者的回答導向訪問者自己心中的答案，或許使用者最常使用的社群軟體是微博和 wechat，但是因為訪問者的舉例，使用者只回答了：「我常用 Facebook, Instagram 和 LINE 。」
6. 不應幫對方下結論
在訪談的過程中，訪談者很容易會不自覺以日常聊天的情緒進行對話，進而幫對方的回答下結論。舉例來說，當使用者說明「我都在通勤的時候滑手機。」，訪談者不應擅自幫對方下「所以你覺得通勤很無聊才滑手機。」這樣的結論。如此帶有自己的猜想復述使用者的回答，很可能在不知不覺中摻入了自己個人假設，降低訪談的參考價值。
後記
上一週為了發想、驗證一個新的專案，在三天內訪談了五位使用者，實際訪談下來才發現遵守上述規則的重要性，或許為了維持訪談熱絡氣氛不小心幫對方下了結論 ; 也似乎擔心使用者想不到答案，在提問時舉了一些範例……這些都是未來該努力改善的錯誤行為。
身為一個 PM實習生，第一次進行使用者訪談，深刻感受訪絕非聊聊天而已，每一個帶有情緒的提問，都很有可能會影響受訪者的回答。期許未來能更避免上述訪談時易犯的錯，以完成可信度更高的使用者訪談。
