3 用户访谈的六步标准流程
用户访谈不是随意的聊天，而是一次需要精密设计的结构化信息获取活动。在IoT领域，用户行为往往被设备交互界面、物理环境、网络延迟和自动化规则所影响，其真实需求比纯软件产品更为隐蔽。本章将六步标准化流程进行拆解，帮助你用“工程化思维”完成每一次访谈。
核心认知：六步流程不是线性走过场，而是一个“计划‑执行‑收敛”的闭环。前三步（目标设定、用户招募、提纲设计）决定访谈质量的上限；后三步（执行访谈、记录整理、需求提炼）决定信息转化为需求的效率。
3.1 六步流程总览
3.2 每一步的核心操作与避坑指南
| 步骤 | 核心操作 | IoT常见误区 | 输出物 |
|---|---|---|---|
| ① 目标设定 | 明确访谈要回答的3-5个核心业务问题；区分“验证型”和“探索型”目标。 | 将“了解用户使用习惯”作为唯一目标，过于宽泛。 | 访谈目标清单 |
| ② 用户招募 | 按目标设定筛选条件（角色/频率/环境/设备型号）；每场6-8人。 | 只招“活跃用户”或“抱怨用户”，导致样本偏差。 | 招募问卷+人员名单 |
| ③ 提纲设计 | 采用“漏斗结构”：宽泛场景→具体行为→问题细节→未来期望。 | 过早进入细节，忽略用户对整体流程的描述。 | 访谈提纲文档 |
| ④ 执行访谈 | 一人主持、一人记录；关注“行为”而非“意见”；追问具体案例。 | 根据录音转文字，忽略现场的非语言信息（如皱眉、重复操作）。 | 原始笔记+录音/录像 |
| ⑤ 记录整理 | 24小时内完成结构化整理；按时间线、关键事件、用户原话、需求标签分类。 | 只保留“有用”片段，丢弃看似无关的信息（可能含隐性需求）。 | 结构化访谈记录表 |
| ⑥ 需求提炼 | 将用户原话转化为“用户目标”与“系统能力”；区分真需求和伪需求。 | 直接记录用户提出的“功能请求”作为需求，跳过背后动机。 | 用户场景+需求卡片 |
3.3 目标设定：确定访谈的北极星
在开始招募用户之前，你必须回答三个问题：
- 为什么要做这次访谈？（例：为了验证某款智能门锁的“离家模式”是否符合真实使用逻辑）
- 需要回答的核心问题是什么？（例：用户在离家时通常会触发哪些设备？触发顺序和等待容忍时间是多少？）
- 访谈结束后，输出什么？（例：用户场景流程图 + 环境触发条件列表 + 异常处理规则）
小贴士：在IoT访谈中，目标应包含“设备‑环境‑人”三维度。例如“了解用户在厨房使用智能插座时，如何应对网络断连”比“了解用户使用智能插座的感受”更具可操作性。
3.4 用户招募：找到“对的”而不是“方便的”
IoT用户招募的筛选条件至少包含以下维度：
- 角色：是终端用户（业主）还是运维人员（管理员）？
- 使用频率：高频（每天） vs 低频（偶尔/应急）
- 环境类型：家庭、办公室、工厂还是户外？
- 设备型号：同一个产品系列的不同硬件版本？
- 连接方式：Wi-Fi、Zigbee、LoRa还是蜂窝网络？
| 场景类型 | 招募重点 | 常见样本偏差 |
|---|---|---|
| 预防性维护 | 设备维保人员、工厂设备主管 | 只招购买方，不招使用方 |
| 故障诊断 | 近期报修用户、安装调试人员 | 忽略没有报修但有小问题的用户 |
| 功能优化 | 使用时长1个月以上的活跃用户 | 只招给好评的“铁粉” |
3.5 提纲设计：漏斗结构与IoT前缀问题
采用“宽入口—窄出口”的漏斗结构。每个环节设计2-4个问题，避免超过15个。以下是一个智能照明场景的提纲片段：
【开场 · 建立情境】 5min
- 请描述您一天中最早开灯的场景是什么？
- 在开灯之前，您通常先做什么？
【行为 · 具体操作】 10min
- 您怎么控制客厅主灯的开关？
- 从您产生“想开灯”的想法到灯真正亮，中间会经历几个步骤？
- 当语音指令没有反应时，您通常怎么处理？
【问题 · 痛点挖掘】 8min
- 在过去一个月里，有没有发生过“灯该亮但没有亮”或“灯不该亮却亮了”的情况？
- 当时您做了什么？最终结果如何？
【期望 · 未来愿景】 5min
- 如果这个照明系统可以变得“更聪明”，你希望它帮您自动完成什么？
避坑：不要问“您对智能灯光的自动调光功能满意吗？”这是封闭且引导性的问题。应改用行为性问题：“请回忆最近一次在家看电影的场景，当时灯光是如何变化的？”
3.6 执行访谈：关注行为而非意见
用户说的“我会这样做”和实际做的往往是两回事。执行访谈时要注意：
- 追问具体案例：当用户说“经常断连”时，追问“最近一次断连是什么时候？当时你在做什么？断连持续了多久？”
- 双线记录：主访谈人负责交互，记录员负责记录时间戳、用户原话、非语言信号（如叹气、重复点击、看手机时间）。
- 不要打断沉默：用户回忆细节时的沉默，往往是最有价值的信息产出时刻。
3.7 记录整理：结构化表格模板
使用统一的结构化记录表，避免在整理阶段丢失关键信息。推荐采用以下模板：
| 时间戳 | 关键事件/行为 | 用户原话（精确） | 非语言信号 | 需求标签 |
|--------|--------------------------|-----------------------------------|--------------|------------------------|
| 02:15 | 从沙发走到开关前 | “我其实不想走过去，但手机又不在身边” | 皱眉、摊手 | 就近控制需求 |
| 05:30 | 尝试用语音控制灯 | “我叫了三次它都没反应，后来发现要加唤醒词” | 声音变大 | 语音识别反馈不及时问题 |
| 08:00 | 打开手机App操作 | “我把亮度拉到最左边，它过了两秒才变暗” | 摇头 | 响应延迟 > 1秒 |
效率建议：整理记录时，使用不同颜色标记“需求类别”——蓝色=功能需求，红色=体验痛点，绿色=环境约束，黄色=意外发现。这样在后续提炼阶段可以快速聚合。
3.8 需求提炼：从“用户原话”到“系统能力”
将用户对问题的描述转化为系统设计需要满足的“能力”，而非直接写入功能列表。以下为转化示例：
| 用户原话 | 背后动机 | 系统能力（非功能） | 是否是真实需求 |
|---|---|---|---|
| “我不想每次出门都绕回去关空调” | 离家场景下，需要一种不折返的关闭方式 | 支持手机远程关闭 + 离家模式自动执行 | ✅ 真需求 |
| “能不能加一个一键回家按钮” | 用户想要在回家前预启动设备 | 地理位置触发规则 + 预设场景 | ✅ 真需求（但实现方式不应是UI按钮） |
| “我希望灯光能随音乐变化” | 娱乐氛围场景下的视听联动需求 | 支持外部音频源识别 + 灯色/亮度动态调整 | ❌ 伪需求（需验证用户真实使用频率） |
关键判断：如果用户提出的“方案”中涉及的实现复杂度远高于其实际收益，且没有足够的数据支撑其高频发生，则倾向于将它标记为“待验证假设”而非直接列入PRD。
至此，你已经完成了一次标准化的用户访谈流程。在下一阶段，所有的访谈记录将进入“需求拆解”环节，转化为可执行的产品功能定义。请确保你的结构化记录表完整、可追溯，它是整个课程后续交付物的“原材料仓库”。