文章類型
方法文 / 訪談教學文
這篇想先講的一句話
很多訪談做完之後，團隊會有一種很熟悉的感覺：
大家聊得很順，筆記也很多，錄音聽起來很熱鬧。
但回頭要做決策時，卻發現真正能用的 evidence 不多。
常見原因不是 participant 不夠會講，而是 interview guide 本身就有問題。
- 問題太像 survey
- 一開始就問太窄、太具體
- 問 hypothetical 問太多
- clarifying question 其實在偷偷塞 interpretation
- 一題裡面包兩三題
- 問法模糊，之後怎麼解釋都可以
所以訪綱不是把十幾個題目排順而已。
它真正的工作是：
讓你在不把答案塞進對方嘴裡的前提下，穩定地挖到可分析、可比較、可拿來做判斷的 evidence。
先拆掉一個迷思：interview guide 不是題庫，而是證據設計
如果把訪綱理解成「記得要問哪些題目」，很容易長成一種 checklist 腦：
- 開場暖身 2 題
- 問痛點 3 題
- 問功能 4 題
- 問建議 2 題
這種寫法看起來很完整，但真正進場之後常常很鬆。
因為研究不是要把題目問完，而是要讓 participant 把相關經驗、脈絡、決策過程、workaround、情緒、限制條件說出來。
所以我自己在寫 interview guide 時，第一步不是開始想問題，而是先把它拆成三層：
- 這次到底想學什麼
- 什麼樣的回答才算 evidence
- 為了拿到這種 evidence，訪談順序應該怎麼安排
這樣寫出來的 guide，才不會只是漂亮的問題表。
先從 research objective 開始，不要從「想問什麼」開始
很多不夠穩的訪綱，都是從這種句子開始的：
- 我想問問看大家怎麼想
- 我們來了解一下用戶需求
- 看看大家覺得這個功能好不好
這種 objective 太鬆，會直接導致後面問題越問越散。
比較有用的 objective，通常會更像這樣：
- 理解新用戶第一次嘗試完成任務時，在哪些地方開始失去信心
- 了解最近一次放棄預訂的脈絡、觸發點與替代方案
- 釐清使用者如何比較不同房源，以及哪些資訊影響最後決策
- 了解 ops 人員目前如何用 workaround 處理例外情境
你會發現，這種 objective 比較像「我要學哪一段行為與判斷」，而不是「我要問哪些看法」。
問題設計的主原則：先廣後窄，先故事後判斷
這是我覺得最值得保留的一個原則。
訪談不要一開始就衝進很窄的問題。
比較穩的順序通常是：
- 先讓對方進入情境
- 先請他講最近一次、具體一次、印象最深的一次
- 先講故事、講流程、講當時怎麼做
- 再慢慢往 decision point、emotion、friction、workaround 收斂
- 最後才進到比較具體的 clarifying questions
為什麼？
因為你一開始問太窄，對方就容易開始配合你的 framing，而不是帶你看到他的 framing。
例子
比起一開始問：
- 你是不是覺得比價很麻煩？
- 你會不會希望系統主動推薦最適合的房源？
更好的起手式通常像：
- 跟我講講你最近一次訂住宿的過程
- 上次你比較房源時，是怎麼一步一步做的？
- 到你最後決定之前，你看了哪些資訊？
- 有哪個瞬間讓你開始猶豫或想放棄？
你會發現，這種問法拿到的是過程、線索和語言，而不是被提示後的表態。
少問 hypothetical，多問 recent behaviour
這幾乎是 user interview 最常見的坑之一。
PM 很容易問：
- 如果有這個功能你會用嗎？
- 如果可以一鍵比較，你覺得好不好？
- 如果我們提供更多篩選條件，你會更想下單嗎？
這類問題看起來很自然，但其實證據很弱。
不是因為 participant 在說謊，而是因為人本來就不擅長準確預測未來情境下的自己。
所以比起問 hypothetical，我會更常問：
- 上次你怎麼比較的？
- 你那時候最後是怎麼決定的？
- 你有沒有試過自己做 workaround？
- 那次你放棄之後改用什麼方法？
假設題不是永遠不能問，但它不應該是主菜。
主菜還是 recent behaviour 和 specific incident。
小心這幾種很常見、但很會污染答案的問法
1. Leading question
像這種：
- 你是不是覺得這段流程有點 confusing？
- 這個提醒功能應該滿有幫助的吧？
- 你是不是會希望看到更透明的價格？
這些問法表面上像在確認，實際上是在暗示。
2. Clarifying question 裡偷放 interpretation
有時候你以為自己只是幫忙釐清，實際上你已經替對方下結論了。
例如：
- 所以你那時候放棄，是因為你不信任平台？
- 所以你其實想要的是更簡單的 UI？
- 所以問題主要是資訊不透明？
這種問法很危險，因為 participant 很容易順著你講。
這不是他真的同意，而是人類在對話裡本來就傾向配合。
3. Compound question
像這樣：
- 你當時是因為價格太高，還是資訊太亂，或者流程太麻煩才放棄？
- 你平常會怎麼找房、比價、安排行程和記錄預算？
一題裡包太多東西，最後很容易只得到一個扁平答案。
4. Ambiguous question
例如：
- 你平常怎麼用？
- 你覺得這個體驗怎麼樣？
- 你對這功能有什麼想法？
這種問法太大，participant 只能自己猜你在問哪一段。
開放式問題是主體，封閉式問題是補刀
這裡我會用一個很簡單的判斷。
如果你需要 participant 自己組織故事、帶出脈絡、暴露他在意什麼，那就優先用 open-ended questions。
如果你只是要釐清時間、頻率、角色、順序、是否發生過，closed questions 可以當 follow-up 用。
開放式問法常長這樣
- 跟我講講最近一次……
- 帶我走一遍你那時候怎麼做的
- 你那時候先看了什麼、後來又看了什麼？
- 哪一段最卡？
- 你怎麼知道自己該繼續還是放棄？
封閉式問法比較適合拿來補細節
- 那次是上週發生的嗎？
- 這是第一次還是以前也發生過？
- 最後是你自己決定，還是別人一起決定？
- 你當時是用手機還是電腦？
closed question 不是不能用。
但如果一開始就連發 closed question，整場訪談很容易變成審問或問卷口頭版。
我會怎麼排 interview guide 的基本結構
不同題目當然會調，但大致上我常用這個節奏：
1. Warm-up
目的不是聊天暖場而已，而是讓 participant 慢慢進入和研究相關的情境。
2. Context
先理解他的角色、任務、環境、頻率，不急著問核心痛點。
3. Recent episode / critical incident
這一段最重要。
通常會請對方講最近一次、印象最深的一次、最麻煩的一次。
4. Decision points / frictions / workarounds
開始往轉折點、猶豫點、替代方案、補救方式挖。
5. Clarifying detail
這時候才慢慢用比較具體的追問去確認細節，而不是一開始就拿具體問題框住他。
6. Light wrap-up
確認有沒有漏掉的重要部分，並讓 participant 補充。
好的追問不是一直問「為什麼」
很多新手 interview guide 會寫一堆 why。
但實際上，連續問「為什麼」很容易讓對方開始合理化，或覺得自己在被盤問。
我更常用的是這幾種 probe：
- 你可以多講一點那個 moment 嗎？
- 那時候你先做了什麼？
- 後來發生什麼事？
- 你怎麼判斷要不要繼續？
- 你當時還考慮了哪些選項？
- 那次和你平常做法一樣嗎？
這種追問比較像在幫他把經驗打開，而不是逼他立刻總結。
不要把 solutioning 偷塞進 discovery interview
這也是 PM 很容易滑進去的坑。
明明這輪要理解問題，卻會忍不住問：
- 那如果我們做成這樣呢？
- 你會不會比較想要這個版本？
- 這個功能 A 和功能 B 你比較喜歡哪個？
這不是完全不能問。
但一旦太早問，participant 就會從「回想自己的經驗」切成「評論你丟出的 idea」。
這兩種 evidence 完全不是同一件事。
既然你之後還會另外寫問題解決與設計思考系列，這裡更值得刻意打住。
這篇就守在 problem understanding，不往 solution evaluation 滑。
Interview guide 不是每題都要照唸
這一點很重要。
guide 的價值，不在於逐字照稿，而在於你知道：
- 這一題在驗證什麼
- 哪些題目是必要 evidence
- 哪些只是備用 probe
- 如果 participant 已經講到了，你就可以跳過
- 如果某段特別有料，你知道怎麼追
所以真正好的 guide，比較像一個有節奏的 evidence map，而不是 script。
什麼時候不要用 interview 當主方法
這篇雖然在講訪綱，但也要補一個邊界。
如果你的問題其實是：
- 某個 prototype 到底好不好用
- 某個 task flow 哪裡卡住
- 某個真實場域中的行為細節長什麼樣
- 某個長期行為怎麼隨時間變化
那 interview 不一定是主方法。
你可能更需要 usability test、field study 或 diary study。
所以寫訪綱之前，還是要先回到上一篇：你選的方法到底對不對。
這篇先停在這裡
這篇先把訪綱守在「如何問出比較不失真的 evidence」。
下一篇如果往下接，就很自然會到另一個難點：
真正進 session 時，PM 怎麼主持、觀察、記筆記，又不把現場帶歪。