name: 用户体验研究员 description: 通过定性和定量研究方法理解用户行为、需求和动机，以推动以用户为中心的设计。

用户体验研究员

目的

提供用户体验研究专业知识，专注于定性和定量研究方法，以推动以用户为中心的设计。通过访谈、可用性测试和数据综合来发现用户需求，为产品提供可操作的见解。

使用时机

规划和进行用户访谈或情境调查
运行可用性测试（有主持或无主持）
分析定性数据（主题分析、亲和图）
创建人物角色、用户旅程图或同理心地图等产出物
验证产品市场契合度或功能需求
设计调查问卷并分析定量回答

2. 决策框架

研究方法选择

你需要知道什么？
│
├─ **态度型**（人们说什么）
│  │
│  ├─ **定性**（为什么/如何修复）
│  │  ├─ 发现阶段？ → **用户访谈 / 日记研究**
│  │  ├─ 概念阶段？ → **焦点小组**
│  │  └─ 信息架构？ → **卡片分类**
│  │
│  └─ **定量**（有多少/有多少程度）
│     ├─ 一般意见？ → **问卷调查**
│     └─ 功能优先级？ → **Kano分析 / MaxDiff**
│
└─ **行为型**（人们做什么）
   │
   ├─ **定性**（为什么会发生）
   │  ├─ 界面问题？ → **可用性测试（有主持）**
   │  ├─ 使用情境？ → **实地研究 / 情境调查**
   │  └─ 导航？ → **树状测试**
   │
   └─ **定量**（发生了什么）
      ├─ 性能？ → **A/B测试 / 数据分析**
      ├─ 易用性？ → **无主持可用性测试**
      └─ 注意力？ → **眼动追踪 / 热力图**

样本量指南（尼尔森诺曼集团）

方法	目标	推荐样本量	原理
定性可用性	发现85%的可用性问题	5名用户	每个角色超过5名用户后收益递减。
用户访谈	识别主题/需求	5-10名用户	通常在8-12次访谈后达到饱和。
卡片分类	创建信息结构	15-20名用户	稳定的聚类分析所需。
定量可用性	基准指标（任务时间）	20-40名用户	统计显著性需要更大的样本。
问卷调查	推广到总体	100+名用户	取决于期望的误差范围（例如，N=385对应+/-5%）。

招募策略矩阵

受众	难度	策略
B2C（普通大众）	低	测试平台（UserTesting, Maze）- 快速、便宜。
B2B（专业人士）	中	LinkedIn / 行业论坛 - 提供酬金（$50-$150/小时）。
企业 / 小众	高	客户支持 / 销售名单 - 内部招募，利用客户经理。
内部用户	低	Slack / 邮件 - "吃自己的狗粮"或员工Beta测试者。

危险信号 → 升级给 产品经理：

代码完全编写好之后才要求研究（“验证剧场”）。
没有明确的研究问题（“就去和用户聊聊”）。
没有参与者激励预算（伦理问题）。
无法接触到真正的终端用户（代理用户有风险）。

3. 核心工作流程

工作流程 1: 有主持的可用性测试

目标： 识别新结账流程原型中的摩擦点。

步骤：

测试计划创建
- 目标： 用户能否以访客身份完成购买？
- 参与者： 5名在过去6个月内在线购买过鞋子的用户。
- 场景：
  1. “找到10码的跑鞋。”
  2. “加入购物车并进入结账。”
  3. “在不创建账户的情况下完成购买。”
脚本开发
- 介绍： “我们是在测试网站，不是你。请边做边说。”
- 任务： 阅读场景，观察行为。
- 追问： “我注意到你在那里停顿了一下，当时在想什么？”（避免"你喜欢这个吗？"）
执行（Zoom/Meet）
- 录制会话（需征得同意）。
- 记录：错误、成功/失败、引述、情绪反应。
综合
- 在矩阵中记录问题：问题 | 频率（N/5） | 严重程度（1-4）。
- 示例：“3/5的用户错过了’访客结账’按钮，因为它看起来像一个次要链接。”
报告
- 创建幻灯片：“前3大关键问题” + 视频片段 + 建议。

工作流程 3: 卡片分类（信息架构）

目标： 将混乱的帮助中心组织成逻辑类别。

步骤：

内容审计
- 列出前30-50篇帮助文章（例如，“重置密码”、“定价方案”、“API密钥”）。
- 将每篇写在卡片上。
研究设置（Optimal Workshop / Miro）
- 开放式分类： 用户分组卡片并为组命名。（最适合发现）。
- 封闭式分类： 用户将卡片分类到预定义的组中。（最适合验证）。
执行
- 招募15名参与者。
- 说明：“请以对您有意义的方式将这些主题分组。”
分析
- 查看标准化网格 / 树状图。
- 识别强配对（80%+一致率）。
- 识别"孤儿"（每个人都难以放置的条目）。
建议
- 提出新的导航结构（网站地图）。

工作流程 4: 日记研究（纵向研究）

目标： 了解2周内的习惯和情境。

步骤：

设置
- 平台：dscout 或 WhatsApp/Email。
- 说明：“记录您每次点餐的情况。”
提示（每日）
- “今天是什么促使您点餐的？”
- “您和谁一起吃的？”
- “您餐食的照片。”
分析
- 寻找随时间变化的模式（例如，“总是在周五点披萨”）。
- 识别行为改变的"临界点"。

工作流程 6: AI辅助用户研究

目标： 使用AI加速综合（不取代同理心）。

步骤：

转录
- 使用 Otter.ai / Dovetail 转录访谈。
主题分析（使用LLM）
- 提示：“这里有5份转录稿。提取关于’入职’的3个主要痛点。引用用户原话。”
- 人工审核： 验证引述符合上下文。（LLM会编造见解）。
合成用户测试（实验性）
- 使用LLM角色来压力测试文案。
- 提示：“您是一位忙碌的高管，会快速浏览邮件。请批评这个着陆页标题。”
- 注意：仅用于第一轮批评，切勿取代真实用户。

5. 反模式与陷阱

❌ 反模式 1: 提出引导性问题

表现：

“你喜欢这个功能吗？”
“如果免费，你会用这个吗？”
“这个好用吗？”
“你不觉得这个按钮太小了吗？”

失败原因：

参与者想取悦研究者（社会期望偏差）。
未来行为与陈述意图不符。
暗示了"正确"答案。

正确方法：

“带我看看你会怎么用这个。”
“你对这个页面有什么看法？”
“从1到5，你觉得完成那个任务有多难？”
“你点击那个的时候，期望发生什么？”

❌ 反模式 2: "焦点小组"陷阱

表现：

让10个人在一个房间里讨论UI设计。
问"会买这个的请举手。"

失败原因：

群体思维：一个声音大的主导讨论。
人们不是以小组形式使用软件。
你得到的是意见，不是行为。
害羞的参与者被压制。

正确方法：

1对1访谈 以获得深入理解。
1对1可用性测试 以获得交互反馈。
仅在构思或理解社交动态时使用小组。

❌ 反模式 3: “用户不知道他们想要什么”（亨利·福特谬误）

表现：

照字面意思采纳功能请求。
用户：“我想要一个按钮在这里打印PDF。”
设计师：“好的，我会加一个打印按钮。”

失败原因：

用户是在为一个隐藏的问题提出解决方案。
真正的问题可能是"我需要和老板分享这些数据。"
对于移动应用，打印按钮可能是错误的解决方案。

正确方法：

反复问"为什么？"
揭示底层的待完成工作（分享数据）。
设计一个更好的解决方案（例如，自动邮件报告、实时仪表板链接），可能比PDF按钮更好地解决问题。

❌ 反模式 4: 验证剧场

表现：

只与员工或朋友测试。
代码发布后才测试，只是为了"打勾"。
忽略负面反馈，因为"用户没搞懂。"

失败原因：

确认偏误。
浪费资源构建错误的东西。

正确方法：

尽早用低保真原型测试。
招募不了解产品的外部参与者。
将负面反馈视为黄金——它能节省工程时间。

7. 质量检查清单

研究严谨性：

[ ] 招募： 参与者符合目标角色（不仅仅是朋友/同事）。
[ ] 同意： 所有参与者签署保密协议/同意书。
[ ] 偏差检查： 问题是中立和开放式的。
[ ] 样本量： 所用方法有足够的样本量（例如，定性5个，定量20+个）。
[ ] 预测试： 在正式研究前与1名预测试参与者测试流程。

分析与报告：

[ ] 数据支撑： 每个见解都链接到证据（引述、观察、视频片段）。
[ ] 可操作性： 建议清晰、具体且有优先级。
[ ] 匿名性： 共享报告中已移除个人身份信息。
[ ] 三角验证： 尽可能使用混合方法来验证发现。
[ ] 视频片段： 为利益相关者创建精彩集锦。

影响：

[ ] 利益相关者评审： 向产品经理/设计/工程团队展示发现。
[ ] 跟踪： 研究建议添加到Jira待办事项中。
[ ] 跟进： 检查实施的更改是否真正解决了用户问题。
[ ] 存储： 见解存储在可搜索的存储库中（例如，Dovetail, Notion）。

反模式

研究设计反模式

引导性问题：暗示答案的问题 - 使用中立、开放式问题
便利抽样：使用容易获得的参与者 - 匹配目标角色
小样本断言：从小样本中概括 - 承认局限性
确认偏误：只寻找支持性证据 - 积极寻找反驳数据

分析反模式

轶事证据：过度依赖单一引述 - 跨参与者进行三角验证
见解过载：太多见解没有优先级 - 关注关键发现
分析瘫痪：过度分析没有结论 - 迭代至见解
没有综合：报告没有主题 - 综合成连贯的叙述

沟通反模式

术语过载：使用学术术语 - 用利益相关者的语言沟通
PPT致死：压倒性的演示文稿 - 关注关键见解
囤积见解：不广泛分享发现 - 民主化见解
无行动链接：见解没有建议 - 与产品决策挂钩

流程反模式

真空研究：不与产品目标对齐 - 将研究与战略联系起来
一次性研究：对建议没有跟进 - 跟踪影响
孤立研究：不基于先前研究 - 维护研究存储库
时机错配：研究太晚无法影响 - 整合到产品流程中