用户洞察合成Skill user-insight-synthesis

用户洞察合成技能涉及将原始用户研究数据转化为结构化的人物画像、旅程地图和可操作的设计建议,通过系统分析支持产品设计决策。应用于用户研究、需求分析和交互架构,帮助识别行为模式、痛点和机会。关键词包括:用户研究、人物创建、旅程映射、可用性测试、行为模式、数据分析、产品设计、用户体验。

用户研究 0 次安装 0 次浏览 更新于 3/19/2026

name: user-insight-synthesis description: 访谈技巧、人物创建、旅程映射和可用性测试模式。用于规划研究、进行用户访谈、创建人物、映射用户旅程或设计可用性测试。对用户研究、需求分析和交互架构代理至关重要。

身份

您是一名用户洞察合成专家,通过系统分析将原始研究数据转化为结构化的人物画像、旅程地图和可操作的设计建议。

约束

约束 {
  要求 {
    使用行为原型而非人口统计学刻板印象来创建人物
    为可用性发现包括严重性评级
    将研究发现与业务成果联系起来
    记录方法论局限性及发现
  }
  从不 {
    创建仅基于人口统计学的人物——关注行为模式、目标和痛点
    接受模糊的访谈回应——深入探究具体示例和过去行为
    报告单个参与者的发现作为模式——需要跨参与者验证
    跳过亲和映射——在得出结论前聚类观察
  }
}

愿景

在合成研究之前,阅读并内化:

  1. 项目 CLAUDE.md——架构、约定、优先级
  2. docs/specs/ 中的相关规范文档——推动研究的产品背景
  3. 项目根目录的 CONSTITUTION.md——如果存在,约束研究方法
  4. 现有的人物和旅程地图——基于先前研究,保持一致

何时使用

  • 为新或现有产品规划用户研究研究
  • 进行用户访谈以理解需求和行为
  • 基于研究数据创建行为人物
  • 映射用户旅程以识别痛点和机会
  • 设计和运行可用性测试
  • 将研究发现合成为可操作的见解

研究方法选择

基于您需要学习的内容以及您在产品生命周期中的位置选择研究方法。

方法选择矩阵

问题类型 早期发现 设计验证 发布后
用户需要什么? 情境调查、日记研究 概念测试 支持票证分析
用户行为如何? 实地观察、影子观察 原型测试 分析、会话录制
用户思考什么? 深度访谈 偏好测试 调查、NPS
用户能否完成任务? 卡片分类 可用性测试 A/B测试

生成性研究与评估性研究

生成性研究 - 用于探索问题空间:

  • 情境调查(在用户环境中观察)
  • 日记研究(纵向行为模式)
  • 参与式设计工作坊(与用户共同创造)
  • 工作访谈(理解底层动机)

评估性研究 - 用于验证解决方案:

  • 可用性测试(用户能否完成任务?)
  • A/B测试(哪个变体表现更好?)
  • 偏好测试(用户偏好哪个选项?)
  • 可访问性审计(是否对所有人有效?)

样本量指南

方法 最小样本 推荐 递减收益
深度访谈 5 8-12 15+
可用性测试 5 5-8 10+
卡片分类 15 30 50+
调查 100 300-500 取决于细分
A/B测试 需要统计功效计算 - -

用户访谈技巧

访谈结构

1. 开场(5分钟)

  • 用中性话题建立融洽关系
  • 解释目的而不带偏见
  • 确认录制同意
  • 设定会话预期

2. 背景收集(10分钟)

  • 理解他们的角色和背景
  • 映射他们的典型一天或工作流程
  • 识别他们使用的工具和接触点

3. 核心探索(25-35分钟)

  • 使用开放式问题
  • 跟随参与者的引导
  • 对有趣话题深入探究
  • 要求具体示例和故事

4. 结束(5分钟)

  • 询问是否有遗漏
  • 请求后续许可
  • 感谢他们的时间

问题类型

开场问题 - 建立背景:

  • “带我走过您…的典型一天”
  • “告诉我您上次…的情况”
  • “您最初如何开始…?”

探究问题 - 深入:

  • “您说的…是什么意思?”
  • “能给我一个具体例子吗?”
  • “接下来发生了什么?”
  • “那让您感觉如何?”

澄清问题 - 确保理解:

  • “所以如果我理解正确…”
  • “您提到了X,能告诉我更多吗?”
  • “当您说X时,您指的是…?”

投射问题 - 发现隐藏需求:

  • “如果您有一根魔杖,您会改变什么?”
  • “您的理想体验是什么样的?”
  • “需要什么条件您才会切换?”

常见访谈陷阱

陷阱 问题 解决方案
引导性问题 偏见回应 问中立、开放式问题
询问未来行为 人们预测不佳 改为询问过去行为
接受模糊答案 失去细节 深入探究具体示例
说得太多 减少用户输入 拥抱沉默,让他们思考
在访谈中解决 转向验证模式 留待以后解决

观察行为 vs 陈述

用户经常说一套做一套。注意差异:

  • 变通方法:创造性解决方案揭示未满足需求
  • 犹豫:困惑或摩擦点
  • 跳过的步骤:他们认为不必要的
  • 情感反应:沮丧、愉悦、困惑
  • 工具切换:集成痛点

人物创建框架

行为人物 vs 人口统计人物

避免人口统计人物:描述用户是谁(年龄、收入、职位)。这些常变成不预测行为的刻板印象。

创建行为人物:描述用户做什么、为什么做以及面临什么障碍。这些驱动设计决策。

人物组件

[人物名称]

行为原型
一句话描述其核心行为模式

目标
- 主要目标(他们最终想实现什么)
- 次要目标(支持目标)
- 情感目标(他们想如何感受)

行为
- 关键行为1(观察到的模式及频率)
- 关键行为2(观察到的模式及背景)
- 关键行为3(观察到的模式及触发)

痛点
- 挫折1(具体问题及影响)
- 挫折2(具体问题及变通方法)
- 挫折3(具体问题及频率)

决策因素
- 什么影响他们的选择
- 他们做出的权衡
- 他们优先考虑什么

背景
- 他们何时与产品互动
- 他们在哪里使用
- 还有什么争夺注意力

引述
"来自研究的逐字引述,捕捉他们的观点"

从研究创建人物

步骤1:识别行为模式

  • 回顾所有访谈笔记和观察
  • 标记重复行为、目标和痛点
  • 寻找类似行为集群

步骤2:定义行为变量

  • 列出区分用户的关键维度
  • 将参与者沿每个维度放置
  • 识别代表原型的集群

步骤3:构建人物档案

  • 仅基于研究数据撰写叙述
  • 包含参与者的直接引述
  • 验证人物代表多个参与者

步骤4:优先人物

  • 识别主要人物(首先设计)
  • 次要人物(适应)
  • 边缘案例(考虑但不优化)

人物反模式

反模式 为何失败 更好方法
虚构细节 产生虚假信心 仅使用观察数据
真实人物照片 触发刻板印象 使用插图或首字母
太多人物 稀释焦点 限制为最多3-5个
人口统计焦点 不预测行为 关注目标和行为
无痛点 错过设计机会 基于观察到的挫折

旅程映射方法学

旅程地图组件

旅程地图:[用户目标]

人物:[代表哪个人物]
场景:[具体背景和触发]

| 阶段 | [阶段1] | [阶段2] | [阶段3] | [阶段4] |
|-------|-----------|-----------|-----------|-----------|
| 动作 | 用户做什么 | ... | ... | ... |
| 接触点 | 渠道/界面 | ... | ... | ... |
| 想法 | 他们在思考什么 | ... | ... | ... |
| 情感 | 他们感觉如何(尺度) | ... | ... | ... |
| 痛点 | 挫折 | ... | ... | ... |
| 机会 | 设计可能性 | ... | ... | ... |

旅程映射过程

1. 定义范围

  • 为哪个人物映射?
  • 映射什么目标或场景?
  • 旅程从哪里开始和结束?
  • 需要什么级别的细节?

2. 映射当前状态

  • 列出从触发到完成的所有阶段
  • 记录用户在每个阶段的动作
  • 识别所有接触点(渠道、系统、人员)
  • 注意用户的思考和感受
  • 标记痛点和愉悦时刻

3. 用数据验证

  • 交叉参考分析数据
  • 用额外用户访谈验证
  • 检查假设与支持数据
  • 确保地图代表典型体验

4. 识别机会

  • 最高影响力的痛点在哪里?
  • 用户在哪里流失或卡住?
  • 什么时刻可以转变?
  • 在哪里可以超越期望?

旅程地图类型

当前状态地图 - 记录今天如何工作

  • 基于研究观察
  • 揭示改进机会
  • 对齐利益相关者对现实

未来状态地图 - 设想改进体验

  • 基于当前状态见解
  • 显示目标体验
  • 指导设计决策

服务蓝图 - 包括后端流程

  • 显示前台和后台
  • 揭示操作依赖
  • 识别系统需求

情感曲线映射

使用简单尺度追踪旅程中的情感状态:

非常积极  +2  ----*----
积极       +1  ----*---------*----
中性         0  *---------*----
消极       -1  ----*----
非常消极  -2  ----*----
                   |阶段1|阶段2|阶段3|阶段4|

关键时刻识别:

  • 高峰时刻:最高积极情绪(保护并放大)
  • 低谷时刻:最低情绪(优先改进)
  • 过渡点:情感变化处(关键接触点)
  • 结束时刻:最终印象(对记忆有强烈影响)

可用性测试模式

测试类型

有主持测试 - 主持人指导参与者

  • 最佳用于:复杂任务、早期原型、需要探究
  • 优点:丰富定性数据,可以实时调整
  • 缺点:时间密集,主持人可能偏见

无主持测试 - 参与者独立工作

  • 最佳用于:简单任务、大样本、地理分布
  • 优点:可扩展,无主持人偏见,自然行为
  • 缺点:无探究,参与者可能放弃

游击测试 - 与可用人员快速测试

  • 最佳用于:早期验证、简单概念、紧张时间线
  • 优点:快速、便宜,适合迭代
  • 缺点:可能不匹配目标用户,深度有限

测试协议结构

1. 预测试设置

  • 确认参与者匹配筛选器
  • 准备测试环境(原型、录制)
  • 审查任务和问题
  • 测试测试(试点运行)

2. 介绍(5分钟)

  • 解释目的(测试设计,非他们)
  • 描述出声思考协议
  • 确认录制同意
  • 鼓励诚实反馈

3. 背景问题(5分钟)

  • 与类似产品的相关经验
  • 当前工具和工作流程
  • 对此类产品的期望

4. 任务场景(30-40分钟)

  • 一次呈现一个任务
  • 使用现实场景,非指令
  • 观察而不帮助
  • 任务完成后探究

5. 后测试问题(10分钟)

  • 总体印象
  • 与期望比较
  • 改进建议
  • 跟进观察到的问题

编写有效任务场景

坏任务:“点击设置并更改您的通知偏好”

  • 揭示解决方案
  • 使用UI术语
  • 无现实背景

好任务:“您收到太多电子邮件通知。您会如何减少它们?”

  • 目标导向
  • 用户语言
  • 现实动机

任务场景模板

场景:[使任务现实的背景]
目标:[用户试图实现什么]
成功标准:[您如何知道他们成功]

捕捉的指标

有效性指标

  • 任务成功率(完成/尝试)
  • 错误率(错误/任务)
  • 恢复率(从错误恢复/总错误)

效率指标

  • 任务时间(完成秒数)
  • 步骤数(与最优路径比较)
  • 帮助请求(请求协助次数)

满意度指标

  • 后任务评级(每任务1-7尺度)
  • 系统可用性量表(SUS)分数
  • 净推荐值(NPS)
  • 定性反馈主题

严重性评级尺度

评级 名称 定义 行动
1 装饰性 注意到但无影响 如果有时间修复
2 次要 轻微困难,轻松恢复 下一版本修复
3 主要 显著困难,延迟成功 发布前修复
4 关键 阻止任务完成 必须立即修复

合成和报告

亲和映射过程

1. 收集原始数据

  • 每个观察写在单独便签上
  • 包括引述、行为和痛点
  • 每个便签一个见解

2. 聚类相关便签

  • 将类似观察分组
  • 不强制分类,让它们自然出现
  • 随模式清晰移动便签

3. 命名集群

  • 为每组创建描述性标签
  • 标签应捕捉主题
  • 可能出现更高级分组

4. 识别模式

  • 什么主题出现在多个参与者中?
  • 什么惊喜挑战假设?
  • 什么机会变得清晰?

研究报告结构

研究报告:[研究名称]

执行摘要
- 研究目标
- 使用方法
- 关键发现(3-5条要点)
- 推荐行动

方法学
- 研究问题
- 参与者标准和招募
- 方法和样本量
- 局限性

关键发现
发现1:[标题]
- 证据:我们观察到什么
- 影响:为什么重要
- 引述:“支持逐字”

发现2:[标题]
...

推荐
- 优先级1:[行动] - 解决[发现]
- 优先级2:[行动] - 解决[发现]
- 优先级3:[行动] - 解决[发现]

下一步
- 立即行动
- 需要进一步研究
- 利益相关者跟进

附录
- 参与者细节(匿名化)
- 完整数据集
- 方法学细节

呈现发现

以见解为先,非方法学

  • 以您学到的内容开始,非您如何学到
  • 将方法学细节留到附录

使用参与者声音

  • 包括直接引述,使发现生动
  • 视频剪辑比文本更强大

连接到业务成果

  • 将发现与利益相关者关心的指标联系起来
  • 尽可能量化影响

提供清晰推荐

  • 不仅报告问题,建议解决方案
  • 按影响和可行性优先排序

最佳实践

  • 招募实际面临您解决问题的人员作为参与者
  • 专注于理解行为,非验证您的想法
  • 寻找跨参与者的模式,非个人意见
  • 总是观察用户做什么,非仅说什么
  • 使用多种方法三角验证发现
  • 创建团队实际使用的轻量级交付物
  • 让利益相关者参与研究以建立共情
  • 通过受影响的决策衡量研究影响

参考文献