### 第4章 访谈提纲设计:结构化提纲与半结构化提纲、关键问题类型(开放、封闭、追问)、避免引导性 用户访谈的质量,七分在提纲,三分在现场。本章围绕用户场景与业务问题,深入拆解提纲设计的三种核心能力:**结构选择**(结构化 vs 半结构化)、**问题类型组合**(开放、封闭、追问)以及**引导性回避**。掌握这三者,你才能从访谈中提取出驱动原型迭代的真实需求。 ---

用户访谈驱动的Figma原型迭代案例 - 第4节

4.1 结构化提纲 vs 半结构化提纲:场景决定框架

提纲的“结构化程度”直接决定了数据的横向可比性与纵向深度。在产品需求早期,纯结构化提纲几乎无法触达意外发现;而完全无结构又容易散失焦点。下表对比了两种典型提纲的适用场景。

对比维度 结构化提纲 半结构化提纲
问题形式 封闭式为主,固定顺序,固定措辞 开放式为主,按话题块引导,措辞可微调
数据产出 高度可量化,适合统计对比 丰富定性,适合挖掘“为什么”
对用户场景的敏感度 低(需提前假设场景) 高(可随场景深挖)
原型迭代阶段 验证假设、指标验收(后期) 探索痛/需求、方案表达(前期)
典型耗时 20-30分钟,节奏快 45-60分钟,弹性节奏
课程核心结论:用户访谈驱动的Figma原型迭代案例建议在需求拆解与方案表达阶段优先采用半结构化提纲;只有当核心指标已确定、需要进行量化验收时,才转向结构化提纲。
---

4.2 关键问题类型:开放、封闭、追问

每个问题类型在提纲中有其不可替代的战术位置。错误的类型组合会导致用户“猜答案”或“说你想听的话”。

4.2.1 开放式问题——挖掘用户场景与业务问题

开放式问题以“什么、如何、为什么”开头,允许用户自由描述。典型句式:

  • “你上次在场景X中遇到困难时,具体发生了什么?”
  • “你如何处理这个业务问题的?”
  • “为什么对你来说这一点很重要?”

4.2.2 封闭式问题——验证假设与确认指标

封闭式问题给出选项,用于快速确认或否定假设。在访谈末尾或需要对齐认知时使用:

  • “你平均每周会使用这个功能3次以上还是以下?”
  • “以下选项中,哪一项最接近你对预期结果的描述?”
混合使用技巧:先开放后封闭。先用“你这次操作中最不顺畅的一步是什么?”(开放式),等用户完整描述后,再用“你指的是A还是B?”(封闭式)确认具体卡点。这种组合可以同时获得深度故事与可量化标签。

4.2.3 追问——触及需求拆解的底层

追问是半结构化访谈的灵魂。每一轮追问都应更靠近用户的真实动机与业务目标。常见的追问模式:

  • 释义式追问:“我确认一下,你刚才的意思是……对吗?”
  • 细节式追问:“你能再描述一下那个具体步骤吗?”
  • 因果式追问:“你提到想要更快的反馈,是因为它会影响你后面的验收决策吗?”
---

4.3 避免引导性:让用户说出真实需求

引导性问题会直接污染需求来源,导致原型迭代路线偏离真实用户场景。必须从提纲设计的每个语句中剔除。

❌ 引导性问法(禁止) ✅ 替代问法(推荐)
“你觉得这个按钮放在这里是不是很顺手?” “你第一次看到这个按钮时,做了什么?”
“大多数用户喜欢更快的速度,你也这么认为吗?” “对你来说,什么速度才算‘快’?”
“如果没有这个功能,会很麻烦吧?” “如果移除这个功能,对你的日常工作会有什么影响?”
常见陷阱:即使你认为自己在中性提问,一旦问题中包含了你的设计偏好或价值判断(如“很棒”“不合理”“太慢”),用户就会下意识地迎合。请一定在提纲撰写后,用“引导性检查清单”逐条核验。
---

4.4 本章强关联结构图:提纲设计核心框架

下方SVG将提纲设计的关键选择节点(结构化程度、问题类型、引导性风险)与原型迭代阶段(用户场景→业务问题→需求拆解→方案表达→指标验证)对应起来,展示了提纲如何作为需求输入的过滤器。

提纲设计核心框架:从用户场景到需求输入 提纲类型选择 结构化 / 半结构化 问题类型组合 开放 + 封闭 + 追问 引导性过滤 ① 用户场景 ② 业务问题 ③ 需求拆解 ④ 方案表达 ⑤ 指标验证 提纲验证要点 • 每个阶段有对应的问题 • 开放/封闭比例恰当 • 无引导性措辞 • 追问链路可延展

该框架清晰地展示了:提纲设计并非孤立事件,而是与用户场景→业务问题→需求拆解→方案表达→指标验证的各阶段紧密嵌套。左侧的“提纲类型选择→问题类型组合→引导性过滤”构成提纲设计的内核,右侧则是此内核的输出目的地。

---

4.5 本章交付物模板:半结构化提纲样例

下方是一个面向“用户场景与业务问题”的半结构化提纲片段,供你直接适配使用。注意追踪每个问题与原型迭代阶段的对齐关系。

# 用户访谈提纲(半结构化 · 30分钟版)
## 阶段:用户场景探索(0-5min)
1. (开放)描述你最近一次使用X产品完成Y任务的全过程。
2. (追问)你提到步骤3经常出错,能具体说一下当时发生了什么?

## 阶段:业务问题确认(6-12min)
3. (开放)这个错误给你带来了哪些直接影响?
4. (追问)你说影响了“效率”,具体是多少时间/成本?
5. (封闭)这个问题的优先级,在你们团队属于P0/P1/P2?

## 阶段:需求拆解(13-20min)
6. (开放)你理想中的解决方案是什么样子的?
7. (追问)为什么这个方案对你来说比另一个方案重要?

## 阶段:方案表达验证(21-25min)
8. (开放)这里有一个示意图,你看到的第一反应是什么?
9. (封闭)以下三种表达方式中,哪种最接近你的预期?

## 阶段:指标验收(26-30min)
10. (封闭)你判断这个方案是否成功,会看哪1-2个指标?
使用建议:在每次模拟访谈后,标记每个问题的实际回答质量。如果某个封闭问题经常需要用户解释,说明它应该改为开放问题;如果追问总被“是/不是”阻断,说明追问不够深入。这份提纲本身也需要迭代——提纲设计迭代与原型迭代同频。
---

4.6 验收标准:如何判断提纲合格

完成提纲设计后,使用以下清单进行自检或交叉评审:

  • 场景覆盖:提纲是否覆盖了至少3个用户典型场景?
  • 业务问题饱和:每个业务问题都有至少2层追问链路吗?
  • 引导性为0:所有问题中没有任何一个出现“是不是、会不会、好不好”等预设词?
  • 问题类型均衡:开放 : 封闭比例是否接近 3:1 或更高?
  • 阶段对齐:每个问题都能在右侧迭代阶段中找到对应位置吗?

具备以上条件的提纲,才能进入访谈执行环节,确保生成的用户反馈真实、可回溯、能直接驱动Figma原型的下一次迭代。