gh-mileschou-claude-marketplace-plugins-ddd/skills/ddd-strategic-design/references/user-questions.md

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