candy14432 使用者訪談法則
任務定義
用一對一質性訪談釐清使用者目標、真實行為、決策脈絡與痛點,產出可支撐設計決策的研究洞察。
何時使用
- 專案初期需要了解使用者需求時
- 驗證產品假設或設計決策時
- 探索新的使用情境或問題領域時
- 需要深入理解使用者動機和情感時
必要輸入
- 研究目標與核心問題
- 目標使用者輪廓
- 產品背景或使用情境
- 希望驗證的假設
- 可用時間與受訪者數量
預期輸出
- 訪談計畫與訪綱
- 訪談執行建議
- 訪談紀錄重點
- 洞察主題與研究發現
- 後續設計建議
完成條件
- 已定義清楚的研究目標、受訪者條件與訪談範圍
- 已產出可直接執行的訪綱,包含暖身、核心問題與追問方向
- 已整理至少 3-5 個具證據支持的關鍵洞察
- 已以引言、情境或行為證據支撐主要結論
- 已將研究發現轉化為後續設計、內容或流程建議
不適用情境
- 只有想收集大量偏好選項,更適合問卷或定量研究
- 已經只剩介面細節驗證,更適合可用性測試
- 沒有明確研究問題,卻想直接安排訪談
常見誤用
- 把訪談當成問卷,只收集偏好而沒有追問真實行為
- 問太多解法導向問題,卻沒有先理解目前流程與痛點
- 樣本角色混雜,導致洞察彼此衝突卻未分角色整理
- 只有整理逐字稿,沒有萃取模式、機會點與設計含義
- 用少量片段意見直接下大結論,缺乏交叉驗證
觸發條件
- 使用者提到「使用者訪談」、「深度訪談」、「訪談大綱」、「需求探索」、「質性研究」
- 任務需要了解使用者動機、痛點、行為模式或真實情境
- 任務需要在設計前先蒐集第一手研究資料
高複雜度觸發
- 任務涉及 B2B SaaS、後台審核流程、多角色採購流程或跨部門協作場景
- 訪談需要區分不同角色、權限、決策責任或跨系統工作流
必要澄清
- 這次研究主要想理解哪一段行為、決策或痛點?為什麼現在要訪談?
- 目標受訪者是誰?是否需要區分不同角色、熟練度或決策權限?
- 目前流程中最容易卡住或最需要釐清的是哪個環節?
- 受訪者會在哪個情境下使用產品?是否涉及例外流程、跨部門協作或工具切換?
- 是否存在權限限制、審批節點、跨系統切換或手動補資料的情況?
- 這次訪談希望驗證哪些假設?哪些資訊是未知但關鍵的?
可搭配技能
persona-creation: 將訪談結果整理成不同角色的人物誌information-architecture: 當訪談揭露資訊分類或導航問題時接續處理wireframing: 根據訪談洞察快速提出流程或介面草案usability-testing: 用原型或現有產品驗證訪談中發現的痛點
執行步驟
- 定義目標: 寫清研究問題、目標角色與要驗證的假設。
- 準備訪綱: 以開放式問題為主,避免引導與封閉式問法。
- 執行訪談: 建立信任、追問具體情境、記錄關鍵引言與非語言訊號。
- 整理洞察: 歸納重複模式、需求、痛點與機會點。
- 產出結論: 用引言與觀察支撐設計建議。
執行檢查
- 已定義研究問題與假設
- 已招募符合條件的受訪者
- 已使用開放式問題並避免引導
- 已記錄關鍵引言與使用情境
- 已整理洞察並形成建議
精簡範例輸出
# 使用者訪談摘要
- 研究目標: 了解結帳流程體驗
- 受訪者: 6 位
關鍵發現:
- 使用者覺得流程過長
- 使用者不知道還要填幾步
- 使用者找不到優惠券輸入位置
設計建議:
- 縮短流程
- 加入步驟指示器
- 提高優惠券欄位可見性
範例資料庫
本技能提供完整的訪談範例庫，請參考 examples.yaml：
- 訪談問題範本：依需求探索、痛點挖掘、目標動機、決策等分類的問題庫
- 訪談框架：5個為什麼、TEDW 等實用框架
- 最佳實踐：準備、執行、分析各階段的實用技巧
使用方式：根據研究目標從 YAML 中選擇適合的問題類別和框架，快速組建訪談大綱。
資料使用規則
- 產出內容前，先閱讀
TEMPLATE.md，確認欄位結構、最小必要欄位、品質標準與驗證方式。 - 接著再閱讀
examples.yaml，從既有分類、題型、框架與標籤中選取最適合的內容。 - 若要新增資料，優先沿用
TEMPLATE.md的格式與命名規則，避免建立重複或過度接近的項目。 - 最終輸出必須優先對齊
TEMPLATE.md的格式要求，其次再引用examples.yaml的內容細節。