用户访谈提纲要围绕一次真实任务展开：先问最近发生的经历，再追问当时的步骤、判断、困难和替代办法，最后核对理解。每个问题都要对应一个研究目标，并能留下具体证据。“您喜不喜欢这个功能”可以收集态度，却不足以判断需求是否值得开发。
假设团队正在研究门店排班，真正需要弄清的可能是“员工为什么经常找不到最新班次”“临时换班如何确认”。把这两个问题讲透，比泛泛问完二十个功能偏好更有用。提纲的质量，体现在它能否帮助研究者追到事情发生的过程。
先把产品问题翻译成研究问题
产品问题常带着方案：“要不要做排班消息推送？”研究问题应留出多种解释：“员工如何得知班次变更，在哪一步容易错过信息？”后者允许发现消息问题，也可能发现版本混乱、责任不清或通知太多。
| 团队想决定什么 | 访谈需要弄清什么 | 可问用户的问题 |
|---|---|---|
| 是否增加消息提醒 | 变更怎样传达到员工，哪里中断 | 请回忆最近一次临时换班，你是怎么知道的？ |
| 是否新增统一排班页 | 员工去哪找最新安排，怎样判断版本 | 上次确认明天上班时间，你先打开了什么？ |
| 是否简化换班审批 | 参与者、条件和等待发生在哪里 | 从提出换班到最后确认，中间联系了谁？ |
写完问题后，再补一列“答案将影响哪个决定”。如果无论用户怎么回答，团队都不会改变任何行动，这个问题就不必占用本轮的主要访谈时间。
找对受访者，才能问到需要的经历
按与任务有关的条件招募：最近是否经历过换班、在流程里承担什么角色、使用哪种现有办法。不要只找愿意配合的同事，也不要只找高度活跃且熟悉产品的用户。店长、普通员工和跨店支援人员的流程不同，应在记录中区分。
不必先追求一个看起来标准的访谈人数。先覆盖关键场景和角色；每完成一轮，检查仍有哪些问题没有证据、哪些现象只有单个参与者提到，再决定下一轮找谁。少量访谈适合发现和解释问题，不宜据此推断全体用户中某种偏好的比例。
GOV.UK的深度访谈指南建议为主题准备开场问题和后续追问，并围绕真实经历展开。将提纲先试访一次，可以发现概念不清、问题跳跃或时间分配不合理的地方。
一份40分钟的访谈提纲
以下时间分配适合围绕一个主要任务展开，可按实际复杂程度调整。开场说明研究用途、记录方式并取得参与者同意；明确对方可以跳过不想回答的问题。
| 阶段 | 时间 | 主问题与追问 |
|---|---|---|
| 建立情境 | 5分钟 | 你的工作里哪些事情需要查看排班？最近一次是什么时候？ |
| 还原最近一次经历 | 15分钟 | 从你发现需要换班开始，按发生顺序讲一遍。先做了什么，接着找了谁？ |
| 深挖关键困难 | 10分钟 | 在哪一步停下来？当时看到什么信息？怎样决定下一步？ |
| 了解替代办法 | 5分钟 | 最后怎样解决？还试过什么方式，为什么没有继续用？ |
| 核对与收尾 | 5分钟 | 我理解为……是否准确？还有什么关键步骤没有谈到？ |
提纲不是逐字念完的问卷。如果用户提到一个具体意外，例如“我到了门店才知道班次已经改了”，可以暂时跳过后面的通用问题，追清那次事件。随后用自然的过渡回到研究主题。
五种追问，让答案从观点走向细节
- 追时间：“最近一次是什么时候？”把“经常”落到一次可回忆事件。
- 追动作：“你接下来打开了哪里？”了解实际流程，而非理想流程。
- 追判断：“你怎么知道这份安排是最新的？”找到用户依赖的线索。
- 追代价：“为此多做了哪些事？”记录额外动作，不急着让用户估一个抽象损失。
- 追差异：“有没有一次没遇到这个问题？”发现问题出现和不出现的条件。
对方说“操作很麻烦”时，先请其描述具体操作；不要立即接“所以你需要一键完成，对吗”。追问是在理解经历，不能把用户带进团队已经想好的答案。
把容易诱导的问法改掉
| 容易得到顺从回答 | 更容易获得经历与依据 |
|---|---|
| 如果有智能提醒，你会用吗？ | 上次错过变更通知时，你后来怎样发现？ |
| 我们的排班页是不是很直观？ | 请找到下一次上班时间，你会从哪里开始？ |
| 你是不是因为步骤太多才放弃？ | 当时发生了什么，让你决定先不继续？ |
| 你觉得这个功能很重要吗？ | 最近一次没有这个功能时，你怎么完成任务？ |
| 你愿意付多少钱？ | 目前谁决定采购、用了哪些预算或替代办法？ |
如果访谈中要展示原型，先完成对现有经历的了解，再切换到原型任务。否则用户很容易沿着新界面组织回忆，把“刚看见的选项”说成“一直以来的需求”。原型操作题也要给目标，不要直接告诉用户点哪个按钮。
记录时分清原话、事实和解释
下面用排班任务演练记录方法。三列必须分开，因为“用户说过什么”与“团队认为原因是什么”有不同的证据强度。
| 原话或观察 | 可确认的事实 | 待验证的解释 |
|---|---|---|
| “上周三我问了两个人才找到最新排班。” | 参与者描述了寻找版本与询问他人的动作 | 统一入口可能减少询问，但需观察更多任务 |
| 参与者先打开群聊，再翻到旧截图 | 本次操作通过群聊和截图查找 | 可能缺少版本线索，需确认其余查找方式 |
| “临时变更时，我会再问店长一次。” | 确认流程包含人工询问 | 可能涉及信任或责任要求，不能直接认定提醒不足 |
每条记录附参与者编号、时间点或笔记位置、相关任务。转述要标为转述；没有逐字记录就不要加引号。观察员可以单独记疑问，访谈结束后再一起核对，避免把讨论中的推测混进用户原话。
访谈后，如何得到可用于产品决策的结果
- 先按问题归类。把版本查找、变更确认、换班批准分开，不急着按想做的功能分类。
- 再看差异。同样的困难发生在什么角色和条件下？有没有反例？
- 写一个可验证判断。例如“用户需要在查看班次时知道它是否已更新”，而非直接宣布“必须做消息推送”。
- 选择下一步。事实缺失就补访谈，操作理解不清就做原型任务走查，需要规模判断则补适合的量化研究。
一页访谈总结可以按“研究问题—证据编号—主要发现—反例—待确认—下一步”整理。不要把几个用户的相似说法包装成全体用户的共同需求；也不要为了结论整齐删掉不一致的经历。
在墨刀白板上可把记录按任务归组，并保留原始笔记链接。形成待验证方案后，用墨刀原型呈现查看排班、辨认更新、确认换班的操作路径，再观察用户能否完成任务。
AI能帮忙整理什么
请根据以下已脱敏访谈记录，按研究问题归类。每条发现附原记录编号；严格区分原话、事实归纳和推测。保留相反经历，不补写用户发言、频次或比例。最后指出缺失的证据，并提出下一轮可使用的中性追问。研究问题：［填写］。记录：［粘贴］。
AI输出之后，逐条回到原记录核对。真正值得交给团队的成果，是带出处的问题理解与验证计划。需要决定采用访谈、问卷还是可用性测试，可继续阅读用户研究方法；方案已经可以操作时，参考原型可用性测试方法设计任务。
