Toolify

使用者訪談 提示詞 — 過去行為、不誘導

AI 寫的訪談指令碼多是變相誘導:「我們的功能對你有什麼幫助?」而不是「帶我重走一遍上次遇到這個問題的過程」。本提示詞強制基於過去行為提問、禁止假設、配套跟進戰術。

分類: research推薦模型: claude / chatgpt / any
prompt
生成 30 分鐘使用者訪談指令碼。

訪談目標: {你想學到什麼 — 要具體}
受訪群體: {你要找誰 — 角色、情境、當前行為}
工作假設 (可選): {你目前相信什麼是真的}

按以下結構輸出指令碼:

1. 暖場 (3 分鐘): 關於他們當前日常的 2 個開放問題, 不提產品。
2. 過去行為 (15 分鐘): 5-7 個問題, 每個錨定相關行動的最近一次例項。格式:「帶我重走一遍上次你...」。
   每題列 2-3 個跟進探針, 讓訪談者備用。
3. 約束 (8 分鐘): 3-4 個關於他們嘗試過、付過錢、失敗過的問題。把真實需求和禮貌客氣區分開。
4. 收尾 (4 分鐘): 1 個開放的「我沒問什麼你希望我問的」+ 致謝。

硬性規則 (Mom Test):
1. 不許有「你會不會...」「你覺得...」開頭的問題 — 都會誘匯出禮貌話。
2. 不許提及自家產品或假設的解決方案。
3. 每個問題必須問出事實(他們做過什麼)或付費(花了多少錢/時間), 不是意見。
4. 如果一個問題不靠想象未來就答不出, 改寫成關於過去的。
5. 跟進必須鑽具體: 「多頻繁」、「誰付的錢」、「實際試了什麼」。

只返回指令碼。每個跟進標 [follow-up: ...]。末尾加一段「訪談中的警示訊號」, 列出會讓資料失效的徵兆(例:參與者其實並不做這件事)。

什麼時候用

  • 動手做任何東西之前 — 5-10 次這樣的訪談替代幾個月的瞎猜。
  • 指標停滯卻找不到原因 — 過去行為問題暴露真實決策樹。
  • 驗證定價假設 — 約束部分(「你付了多少」)比「你願意付多少」誠實得多。

模型提示

claude
最善於避免誘導問題。被請求時會把假設性問題改寫成過去行為問題。
chatgpt
容易混進「你會不會」的措辭。「禁止 you would」規則最重要。
any
如果一個問題問起來很舒服, 多半是誘導。指令碼應該感覺略帶侵入 — 這才能拿到真實資料。

示例: 個人理財工具發現式訪談

目標: 理解 30 中段 SaaS 員工實際怎麼追蹤個人理財。

暖場 (3 分鐘)
  - 說說你的工作 — 平時每天主要做什麼?
  - 工作日早晨上班前一般是什麼樣?

過去行為 (15 分鐘)
  Q1: 上次你坐下來開啟銀行賬戶看, 是什麼時候, 觸發因素是什麼?
    [follow-up: 是計劃好的還是臨時反應?]
    [follow-up: 總共看了多久?]
  Q2: 上次你做超過 500 美元的財務決定 — 買東西、先等等、換銀行 — 把這個過程走一遍。
    [follow-up: 決定前你查了什麼?]
    [follow-up: 你和誰商量了?]
  ... [剩下 5 題]

約束 (8 分鐘)
  Q8: 你上次實際付費的理財工具是哪個? 哪怕只 5 美元。讓你停止或繼續付費的原因是什麼?
  ... [剩下 3 題]

收尾: 我沒問什麼你希望我問的?

訪談中的警示訊號:
- 受訪者說「我會」 — 他們其實並不做這件事。要追問最近一次真實例項; 找不到就說明這個細分可能沒有這個問題。
- 數字/日期含糊(「我有時候看一下」)。含糊 = 想象行為。問「上次具體是什麼時候?」來接地。

運作原理

為什麼大多數 AI 訪談指令碼毫無用處

預設 LLM 對「寫訪談指令碼」的輸出是誘導問題:「特性 X 對你有什麼幫助?」。Mom Test (Rob Fitzpatrick, 2014) 二十年前就證明假設性問題只能換來禮貌, 拿不到資料。真實使用者會說他們覺得你想聽的話。上面的指令碼強制基於過去行為錨定, 這才能到達事實。

跟進探針同樣重要。「帶我重走一遍上次遇到這個問題的過程」預設會得到 30 秒的回答。探針(「最先查什麼」、「誰付的錢」、「多久」)能把這 30 秒變成 5 分鐘有用的細節。

拿到輸出後怎麼做

改指令碼前先做 5 次訪談。3-4 次訪談後規律就顯現。5 次時你就能分清哪些問題在拿真資料、哪些在拿禮貌填充 — 把禮貌填充類問題砍掉, 給好的問題加更具體的跟進。

5-7 次訪談後用研究總結提示詞把它們跑一遍, 抽取主張與矛盾。組合(訪談指令碼 → 結構化總結 → 主張對映)遠比讀完所有文字稿、靠記憶找規律快。

常見問題

›為什麼不許「你會不會」?

因為當面給人描述某個功能, 大家都會說會用。假設性問題誘導禮貌, 過去行為問出事實。提升訪談質量最大的單一改進就是把所有「你會不會」從指令碼里刪掉。

›我的產品還不存在怎麼辦?

更好 — 你沒東西能給人施加偏見。每個問題都關於已有的痛點和當前的解決方案。這正是發現式訪談的用武之地。

›我需要多少次訪談?

每個細分 5-12 次比較常見。5 次時規律已經聽到。再多是細化規律而不是發現新東西 — 除非你研究新細分, 否則超過 10 次後邊際收益遞減。

›受訪者跑題了怎麼辦?

通常是寶藏。真實痛點會讓對話脫軌, 客氣答案不會。讓他們自由說 2-3 分鐘, 做筆記, 然後橋接回來: 「再說說 X — 那是不是和你做 Y 同一時間?」

›應該提前分享假設嗎?

不。用模糊的話告訴他們目標(「我在研究人們怎麼處理 X」)。分享具體假設會給他們的回答帶來偏見。

›可以用於可用性測試嗎?

目標不同 — 可用性測試需要任務指令碼, 不是發現式指令碼。有重疊(不誘導、觀察行為)但形式不同。可用性測試提示詞將另行釋出。

相關計算器

相關提示詞

最後更新: