用户访谈实操：围绕具体经历发现需求

项目资料明明可以上传到系统，团队成员却仍用聊天发附件。产品负责人怀疑上传按钮不好找。若访谈一开场就问“按钮大一点会不会方便”，参与者很容易赞同，原来的交接问题仍没被讲出来。

用户访谈（Interviews）通过交谈了解经历、观点和态度。它最有用的地方，是让研究者沿着一次具体事件追问：当时要做什么、怎样判断、遇到什么困难、最后怎样处理。先弄清问题，后面才有依据讨论功能。

提纲要留住共同问题，也给经历留空间

以一个假设场景为例：某企业准备改版项目交接工具，想了解成员为何绕开系统发送资料。团队列出的未知事项包括入口、权限、版本、通知和交接规则，而不是把访谈目标写成“证明需要更大的上传按钮”。

访谈可以采用固定问题、半结构化提纲或开放交流。需要跨参与者比较时，保留共同的问题；探索未知过程时，给对方讲述的空间。提纲能帮助研究者不漏要点，无需逐字念完才能算完成。

招募按实际交接经历筛选，覆盖相关职责、熟练程度和阶段。只找熟人或活跃用户，可能错过其他困难。记录招募渠道、参与条件和缺少的情境，访谈人数也随问题和证据缺口安排，不能用固定数目保证需求已经全部发现。

当问题涉及责任和协作，分别与负责人、执行人员交流，通常更容易保留各自经历。两人或多人一起谈，则需留意谁在回答、谁在替别人解释。

研究者可以这样开场：“请讲讲最近一次把项目资料交给同事的过程。”这句话允许参与者谈系统之外的通知、期限和确认方式，不把讨论提前限定在页面里。

沿时间顺序追问：“从哪里拿到文件？”“发送前怎样确认版本？”“怎么知道对方收到了？”当参与者说通过聊天发出去，先问他当时怎么做、为何这样判断，不马上展示新上传入口。

参与者在自己的工作环境用无敏感信息的道具还原交接过程

示例中的参与者可能解释，系统里有多个版本，聊天里可以问一句“用这份吗”。这条线索把问题从按钮大小移到了版本确认。也可能有人确实找不到上传位置，研究者应保留两种经历，而非急着选一个总原因。

还可以请对方讲一次顺利的交接，比较困难是否只在外部合作、临时改稿或权限不同的情况下出现。成功经历往往能帮助团队看清问题成立的条件。

“经常”“很慢”“大家都这样”都需要继续说明。可以问“最近一次是什么时候”“当时等的是哪一步”。若对方记不清，就记不清，不能为了填满表格诱导他估出次数。

沉默时留一点思考空间。涉及同事评价或敏感经历，可以提醒他跳过。访谈用于理解任务，审问式追问会让人防备，也容易得到符合期待的说法。

面对面和远程都可进行访谈。先说明知情与记录范围；如果要展示资料，允许遮挡、跳过，或改用无敏感信息的例子。公开引用还需确认使用范围，不能把普通转述改成戏剧化的“用户原话”。

自述受回忆、表达与社会期待影响，研究者的身份和反应也会改变交流。因此“他说经常这样做”只能说明他的表述，不能直接代替使用记录。

整理不用抄满所有录音，但要留够上下文。可以按事件写一份短摘要，包含目标、动作、判断、结果与未确认细节。