開始閱讀
「如果我們推出這個服務，你會不會想用？」是一個很容易得到好答案的問題。受訪者可能願意鼓勵你，也可能覺得假設情境沒有成本，於是回答會。但當服務真的推出，對方的時間、預算與優先順序都會影響選擇，原本的支持未必轉成行動。
需求訪談更值得關心的是最近一次真實行為：問題在什麼情境發生、對方如何處理、花了多少精力、為什麼沒有選其他方式。這些細節能幫助企劃理解決策，而不是只收集對點子的評價。
先談對方的工作，再談你的方案
如果一開始就介紹產品，後續問題容易圍繞產品優點，受訪者也可能順著你的語言回答。可以先請對方描述最近一次遇到的困難，再追問過程。當具體情境清楚後，才用方案確認是否理解正確。
例如不要先問「你是否需要 AI 提高效率」，而是問「最近一次整理社群月報是怎麼完成的」。再追問資料從哪裡來、哪一步最花時間、誰會使用報表、最後做了什麼決定。這些資訊才能幫你判斷問題是否值得解決。
三類問題比滿意度更有資訊
第一是事件問題，找出實際發生的情境；第二是過程問題，理解目前做法；第三是取捨問題，了解為何選擇或放棄。問完後可以請對方確認你的摘要，避免把自己的解釋當成對方原意。
| 常見問法 | 更具體的問法 |
|---|---|
| 你喜歡這個功能嗎 | 最近一次需要它是在什麼情境 |
| 你覺得很麻煩嗎 | 哪一步花最多時間，怎麼處理 |
| 你會付費嗎 | 目前為解決這件事投入哪些資源 |
| 這是不是很好用 | 有哪些情況你仍會選擇原本做法 |
詢問最近一次真實行為及其情境，比只問未來意願更容易取得具體線索。
不急著替受訪者命名問題
對方說「每次都要重新確認」，可能是資料版本不清、權責不明，也可能是主管尚未決定。若立刻把它歸類成需要自動化，就可能跳過真正原因。先追問具體例子，再整理可能的問題類型。
訪談紀錄最好分成原話、觀察與研究者推論。原話保留意思，觀察描述發生什麼，推論則標示你的判斷。這能讓團隊回頭討論時，不會把分析結論誤認為受訪者直接說過的事實。
教學情境：行政流程改善
假設要改善請假流程。員工可能覺得表單難填，主管可能困擾於資訊不完整，行政人員則花時間追問附件。三者看的是同一流程的不同位置。只訪談其中一方，方案可能解決局部問題，卻把工作轉移給另一方。
可以讓每個角色描述最近一筆申請如何流動，標出等待、補件與重複輸入。不要先承諾把全部流程搬到某個工具，而是先找出最常造成返工的交接點。工具選擇應跟著問題走，而不是讓訪談替既定工具背書。
可複製的訪談提綱
請描述最近一次遇到這個問題的情境。
當時想完成什麼？實際採取哪些步驟？
哪一步需要等待、重做或請別人幫忙？
曾考慮哪些替代方式？為什麼沒有採用？
如果不解決，會有什麼影響？
最後請確認：我的理解是否正確，有沒有漏掉重要條件？
樣本選擇會影響你聽見的故事
只找熟識且願意支持的人，可能得到偏樂觀的回應。可以依工作角色、使用經驗與問題程度挑選不同受訪者，也納入曾經放棄或選擇其他方案的人。訪談不是追求人數看起來很多，而是理解重要差異。
少量訪談適合發現問題與形成假設，不宜直接推論整個市場比例。若要知道某需求有多普遍，還需要適當的調查或行為資料。不要把「五位受訪者都提到」寫成「所有消費者都需要」。
整理時保留相反證據
當多數人說流程很慢，但有人覺得現況足夠，應了解差異來自哪裡。可能是工作量不同、已有替代工具，或對精確度要求不同。這些差異能幫你界定適合與不適合的客群，而不是被當成雜訊刪掉。
同時避免只挑支持原案的引言放進簡報。完整的需求摘要應包含共同模式、例外情況與仍需驗證的問題。讓決策者看見限制，比用幾句漂亮引言製造一致意見更有價值。
訪談之後要改變什麼
每次訪談結束，列出它影響了哪個假設、哪個功能優先順序或哪段文案。如果所有訪談都沒有改變任何決定，可能只是拿研究當裝飾。真正的洞察會讓你更清楚做什麼、暫時不做什麼，以及下一步需要驗證哪個問題。
訪談前先寫下你最想被證明的事
每個研究者都可能帶著偏好。先寫下自己希望聽到什麼，有助提醒不要在問題裡暗示答案。例如你希望證明自動報表有需求，就更要追問現有流程何時其實運作良好、哪些工作不值得自動化，以及對方曾經拒絕哪些工具。
訪談時可以保持好奇，但不要急著辯護產品。如果對方不理解方案，先記錄他如何理解與哪裡卡住，而不是立即補上一大段解釋。你在場時能說清楚，不代表未來網站上的讀者也能理解；誤解本身就是有價值的內容線索。
也不要把受訪者當成產品設計師，要求他直接提出完整解法。他可能很清楚自己的困難，卻不知道技術選項。研究者的工作是理解情境與限制，再提出可測方案，不是把所有設計責任交回給對方。
整理成需求模式，而非人物標籤
可以把回應整理成「資料分散造成重複確認」「交付標準不明造成返工」等問題模式，再保留各自情境。不要因為某位受訪者不使用新工具，就貼上抗拒改變的標籤。對方可能有合理的成本、權限或可靠性考量，這些才是企劃需要理解的資訊。
引用受訪內容時，應依原先同意的用途處理；內部研究與公開案例是不同範圍。即使移除姓名，職稱、地點與特殊經歷的組合仍可能識別人物。公開前應再次檢查，而不是只把名字改成代號就認定足夠。
訪談結果可以轉成一張機會清單：問題、影響、目前替代方式、支持證據與下一步驗證。不同問題不必立刻變成功能，有些可以用更清楚的說明、表單或服務流程解決。先找最小可行改善，能避免把所有抱怨都變成龐大的開發需求。
最後回看哪些問題在後續行為中得到支持。若受訪者說很在意，但試行時完全沒有使用，應繼續了解原因，而不是直接判定對方說謊。訪談與行為資料互相補充，才能形成比較完整的需求理解。