170 lines
7.3 KiB
Markdown
170 lines
7.3 KiB
Markdown
# End User Interview Questions
|
|
|
|
終端使用者訪談的目標是理解真實的使用情境、工作流程、痛點和期望。使用者的實際操作往往揭示了系統真正需要支援的用例，而非理論上的設計。
|
|
|
|
## Phase 1: 背景與脈絡
|
|
|
|
**目的：了解使用者的角色、經驗和使用情境**
|
|
|
|
1. 能否簡單介紹一下你的工作內容？
|
|
2. 你每天會花多少時間使用這個系統？
|
|
3. 你使用這個系統多久了？
|
|
4. 除了這個系統，你還會用哪些工具來完成工作？
|
|
5. 你是單獨使用，還是需要與團隊協作？
|
|
|
|
**追問技巧：**
|
|
- "你覺得這個系統在你的工作中重要嗎？" - 理解系統定位
|
|
- "如果沒有這個系統，你會怎麼做？" - 了解替代方案
|
|
- "有沒有人教過你怎麼用？還是自己摸索的？" - 理解學習曲線
|
|
|
|
## Phase 2: 典型工作流程
|
|
|
|
**目的：觀察真實的操作序列，發現用例和任務模式**
|
|
|
|
1. 能否示範一下你平常是怎麼使用這個系統的？
|
|
2. 請描述一個你今天實際完成的任務，從頭到尾是怎麼做的？
|
|
3. 這個任務通常需要多長時間？
|
|
4. 完成這個任務需要經過哪些步驟？
|
|
5. 有沒有一些步驟是你覺得可以跳過或簡化的？
|
|
|
|
**追問技巧：**
|
|
- "為什麼要這樣操作？" - 理解操作背後的意圖
|
|
- "有沒有其他方法可以達到同樣的目的？" - 發現替代流程
|
|
- "如果這一步出錯，你會怎麼辦？" - 理解錯誤處理
|
|
|
|
## Phase 3: 痛點與困難
|
|
|
|
**目的：識別使用者體驗的瓶頸和挫折點，這些往往指向設計改善的機會**
|
|
|
|
1. 在使用過程中，什麼地方最讓你感到困擾？
|
|
2. 有沒有經常出錯或需要重做的步驟？
|
|
3. 什麼情況下你會覺得「系統怎麼這麼笨」？
|
|
4. 你最希望改善的功能是什麼？
|
|
5. 有沒有一些「變通方法」(workaround) 你不得不使用？
|
|
|
|
**追問技巧：**
|
|
- "這個問題多久會遇到一次？" - 評估頻率
|
|
- "這個問題會耽誤你多少時間？" - 量化影響
|
|
- "你有向誰反映過這個問題嗎？" - 理解溝通管道
|
|
|
|
## Phase 4: 決策點與判斷
|
|
|
|
**目的：理解使用者如何做決策，什麼資訊影響他們的選擇**
|
|
|
|
1. 在 [某個步驟] 你如何決定要選擇哪個選項？
|
|
2. 你需要哪些資訊來做這個決定？
|
|
3. 有時候會選錯嗎？什麼情況下會選錯？
|
|
4. 做這個決定時，你會考慮哪些因素？
|
|
5. 如果不確定該怎麼選，你會怎麼辦？
|
|
|
|
**追問技巧：**
|
|
- "系統有沒有給你足夠的資訊來做決策？" - 評估資訊充分性
|
|
- "你希望系統能提供什麼建議或提示？" - 發現輔助需求
|
|
- "有沒有某些選項你從來不會選？為什麼？" - 理解選項的實用性
|
|
|
|
## Phase 5: 異常與例外情況
|
|
|
|
**目的：發現「不在手冊上」但實際會遇到的情況**
|
|
|
|
1. 有沒有遇過系統無法處理的情況？
|
|
2. 遇到特殊情況時，你是如何處理的？
|
|
3. 什麼情況下你會需要尋求他人協助？
|
|
4. 系統有沒有給過你意外或奇怪的反應？
|
|
5. 有沒有一些「理論上不該這樣做但實際上得這樣做」的操作？
|
|
|
|
**追問技巧：**
|
|
- "這種情況常見嗎？" - 評估特殊情況的頻率
|
|
- "你覺得系統應該怎麼處理這種情況？" - 收集改善建議
|
|
- "這種情況對你的工作影響大嗎？" - 評估優先順序
|
|
|
|
## Phase 6: 協作與溝通
|
|
|
|
**目的：理解多人協作的模式和資訊交換的需求**
|
|
|
|
1. 你的工作成果會交給誰？
|
|
2. 你需要從其他人那裡得到什麼資訊？
|
|
3. 團隊成員之間如何協調工作？
|
|
4. 有沒有需要同時編輯或共同決策的情況？
|
|
5. 如果有衝突或不一致，如何解決？
|
|
|
|
**追問技巧：**
|
|
- "你們如何知道對方的進度？" - 理解可見性需求
|
|
- "有沒有遇過「我以為你會做,你以為我會做」的情況？" - 發現協作盲點
|
|
- "系統如何幫助或阻礙你們的協作？" - 評估協作支援
|
|
|
|
## Phase 7: 期望與理想狀態
|
|
|
|
**目的：理解使用者的願景，這有助於識別真正的需求而非表面要求**
|
|
|
|
1. 如果可以改變這個系統的一件事，你會改變什麼？
|
|
2. 你理想中的工作流程是什麼樣子？
|
|
3. 有沒有其他系統或工具有你希望這個系統也有的功能？
|
|
4. 如果系統能自動幫你做一件事，你希望是什麼？
|
|
5. 你認為新手使用這個系統最大的障礙是什麼？
|
|
|
|
**追問技巧：**
|
|
- "為什麼這個功能對你很重要？" - 理解深層需求
|
|
- "如果有了這個功能，你的工作會有什麼改變？" - 評估價值
|
|
- "這個改變會不會影響到其他人？" - 考慮連鎖效應
|
|
|
|
## Phase 8: 頻率與模式
|
|
|
|
**目的：量化不同用例的重要性，幫助優先順序決策**
|
|
|
|
1. 你最常做的任務是什麼？多久做一次？
|
|
2. 哪些功能你每天都會用？
|
|
3. 哪些功能很少用，但用的時候很關鍵？
|
|
4. 在一天當中，什麼時候最常使用這個系統？
|
|
5. 使用的強度會隨著時間變化嗎？（月初月底、旺季淡季？）
|
|
|
|
**追問技巧：**
|
|
- "能給我一個大概的百分比嗎？" - 量化使用分布
|
|
- "這個任務緊急嗎？還是可以慢慢做？" - 理解時效性
|
|
- "如果這個功能變慢了，對你的影響大嗎？" - 評估效能敏感度
|
|
|
|
## Phase 9: 學習與適應
|
|
|
|
**目的：理解使用者如何學習和適應系統，這影響 UI 設計和訓練需求**
|
|
|
|
1. 當初學習使用這個系統時，什麼最難理解？
|
|
2. 現在還有什麼功能你不太會用嗎？
|
|
3. 你有沒有發現一些「早知道」的使用技巧？
|
|
4. 如果要教新人，你會從哪裡開始教？
|
|
5. 系統的哪些部分是「憑直覺」就知道怎麼用的？
|
|
|
|
**追問技巧：**
|
|
- "你是怎麼學會這個的？" - 理解學習路徑
|
|
- "系統的提示或說明有幫助嗎？" - 評估輔助功能
|
|
- "有沒有一些術語或概念讓你困惑很久？" - 發現溝通障礙
|
|
|
|
## Phase 10: 觀察而非只是詢問
|
|
|
|
**重要提醒：真實的使用行為往往與使用者的描述不同**
|
|
|
|
在訪談過程中，儘可能：
|
|
- **請使用者實際操作** - "能否示範給我看？" 而不只是 "你會怎麼做？"
|
|
- **觀察猶豫和錯誤** - 使用者卡住或選錯的地方往往最有價值
|
|
- **注意非語言訊號** - 皺眉、嘆氣、快速點擊都是痛點的訊號
|
|
- **記錄實際用詞** - 使用者如何稱呼功能和概念
|
|
- **關注繞過的功能** - 使用者刻意不用的功能可能有問題
|
|
|
|
## 訪談後整理重點
|
|
|
|
根據終端使用者訪談，應該能識別：
|
|
|
|
1. **使用者旅程地圖** - 完整的任務流程和接觸點
|
|
2. **高頻用例** - 最常執行的任務和操作序列
|
|
3. **關鍵痛點** - 影響體驗的主要問題
|
|
4. **實際術語** - 使用者真正使用的詞彙 (vs. 系統或專家用的術語)
|
|
5. **協作模式** - 多人協作的方式和需求
|
|
6. **隱藏需求** - 使用者的變通方法揭示的真實需求
|
|
|
|
記住：使用者訪談提供的是「系統被如何使用」的真相，而非「系統應該如何使用」的理論。這些洞察需要與 PM 的業務目標和領域專家的規則結合，才能設計出既符合業務又好用的系統。
|
|
|
|
## 跨角色驗證
|
|
|
|
將三種訪談結果交叉比對：
|
|
- **PM 說的重要功能，使用者真的常用嗎？** - 驗證業務假設
|
|
- **使用者的痛點，在領域專家眼中是規則問題還是 UI 問題？** - 區分根因
|
|
- **領域專家的術語，使用者真的這樣說嗎？** - 調整 Ubiquitous Language
|