ux-researcher

UX 研究员

目的

提供用户体验研究方面的专业知识，专长于定性和定量研究方法，以推动以用户为中心的设计。通过访谈、可用性测试和数据综合，发掘用户需求，并形成可执行的产品洞察。

适用场景

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

---

---

2. 决策框架

研究方法选择

What do you need to know?
│
├─ **Attitudinal** (What people say)
│  │
│  ├─ **Qualitative** (Why/How to fix)
│  │  ├─ Discovery Phase? → **User Interviews / Diary Studies**
│  │  ├─ Concept Phase? → **Focus Groups**
│  │  └─ Information Arch? → **Card Sorting**
│  │
│  └─ **Quantitative** (How many/How much)
│     ├─ General opinion? → **Surveys**
│     └─ Feature prioritization? → **Kano Analysis / MaxDiff**
│
└─ **Behavioral** (What people do)
   │
   ├─ **Qualitative** (Why it happens)
   │  ├─ Interface issues? → **Usability Testing (Moderated)**
   │  ├─ Context of use? → **Field Studies / Contextual Inquiry**
   │  └─ Navigation? → **Tree Testing**
   │
   └─ **Quantitative** (What happens)
      ├─ Performance? → **A/B Testing / Analytics**
      ├─ Ease of use? → **Unmoderated Usability Testing**
      └─ Attention? → **Eye Tracking / Heatmaps**

样本量指南（Nielsen Norman Group）

方法	目标	建议样本量 N	理由
定性可用性测试	找出 85% 的可用性问题	5 名用户	每个人物画像测试 5 名用户后，收益递减。
用户访谈	识别主题／需求	5-10 名用户	通常在 8-12 次访谈左右达到饱和。
卡片分类	创建信息结构	15-20 名用户	稳定的聚类分析需要此样本量。
定量可用性测试	衡量基准指标（任务用时）	20-40 名用户	达到统计显著性需要更大的样本量。
问卷调查	推断总体情况	100 名以上用户	取决于期望的误差范围（例如，N=385 对应 ±5%）。

招募策略矩阵

受众	难度	策略
B2C（普通大众）	低	测试平台（UserTesting、Maze）——快捷、廉价。
B2B（专业人士）	中	LinkedIn／行业论坛——提供报酬（$50-$150/小时）。
企业／细分领域	高	客户支持／销售名单——内部招募，借助客户经理。
内部用户	低	Slack／Email——“自家试用”或员工 Beta 测试者。

危险信号 → 升级至 product-manager：

• 代码全部编写完毕后才提出研究需求（“验证表演”）。
• 没有明确的研究问题（“就去和用户聊聊”）。
• 没有参与者激励预算（伦理问题）。
• 无法接触真正的终端用户（代理用户风险较高）。

---

---

3. 核心工作流

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

目标： 找出新版结账流程原型中的阻碍点。

步骤：

1. 制定测试计划

   • 目标： 用户能否以访客身份完成购买？
   • 参与者： 5 名过去 6 个月内在网上买过鞋的用户。
   • 场景：
     1. “找到 10 码的跑鞋。”
     2. “加入购物车并继续结账。”
     3. “无需创建账户即可完成购买。”

2. 编写脚本

   • 开场： “我们测试的是网站，不是你。请边做边说出你的想法。”
   • 任务： 读出场景，观察用户行为。
   • 追问： “我注意到你刚才停顿了一下，你当时在想什么？”（避免问“你喜欢吗？”）

3. 执行（Zoom/Meet）

   • 录制会话（需获得同意）。
   • 记录：错误、成功／失败、原话、情绪反应。

4. 综合分析

   • 在矩阵中记录问题：问题 | 频率（N/5）| 严重程度（1-4）。
   • 示例：“5 名用户中有 3 名没注意到‘访客结账’按钮，因为它看起来像次要链接。”

5. 报告

   • 制作幻灯片：“最严重的 3 个问题”＋视频片段＋建议。

---

---

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

目标： 将杂乱的帮助中心整理成逻辑清晰的类别。

步骤：

1. 内容审查

   • 列出排名前 30-50 的帮助文章（例如，“重置密码”“定价方案”“API 密钥”）。
   • 将每篇文章写在一张卡片上。

2. 研究设置（Optimal Workshop / Miro）

   • 开放式分类： 用户对卡片分组并为各组命名。（最适合探索。）
   • 封闭式分类： 用户将卡片分到预先定义的组中。（最适合验证。）

3. 执行

   • 招募 15 名参与者。
   • 指示语：“请按照你认为合理的方式将这些主题分组。”

4. 分析

   • 查看标准化网格图 / 树状图。
   • 找出强关联组合（一致率达 80% 以上）。
   • 找出“孤立项”（所有人都难以归类的项目）。

5. 建议

   • 提出新的导航结构（站点地图）。

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

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

步骤：

1. 设置

   • 平台：dscout 或 WhatsApp/Email。
   • 指示语：“每次订餐时都记录下来。”

2. 提示词（每日）

   • “今天是什么促使你订餐的？”
   • “你和谁一起吃饭？”
   • “上传你的餐食照片。”

3. 分析

   • 寻找一段时间内的规律（例如，“每周五都会点披萨”）。
   • 找出行为改变的“转折点”。

---

---

工作流 6：AI 辅助用户研究

目标： 利用 AI 加快综合分析（而不是取代共情）。

步骤：

1. 转录

   • 使用 Otter.ai / Dovetail 转录访谈。

2. 主题分析（使用 LLM）

   • 提示词：“以下是 5 份访谈记录。提取关于‘引导流程’的 3 个主要独立痛点。引用用户原话。”
   • 人工审核： 确认引文与上下文相符。（LLM 会编造洞见。）

3. 合成用户测试（实验性）

   • 使用 LLM 用户画像对文案进行压力测试。
   • 提示词：“你是一位忙碌的高管，浏览邮件时只会快速扫读。请点评这个落地页标题。”
   • 注意：仅用于第一轮点评，绝不能取代真实用户。

---

---

5. 反模式与注意事项

❌ 反模式 1：提出诱导性问题

表现：

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

为什么无效：

• 参与者想让研究人员满意（社会称许偏差）。
• 未来的行为与口头表达的意图并不一致。
• 暗示存在一个“正确”答案。

正确做法：

• “请向我讲讲你会如何使用它。”
• “你对这个页面有什么看法？”
• “按 1-5 分打分，这项任务有多难？”
• “你点击它时，预期会发生什么？”

❌ 反模式 2：“焦点小组”陷阱

表现：

• 把 10 个人聚在一个房间里，询问他们对 UI 设计的看法。
• 询问“觉得自己会买这个的人请举手。”

为什么无效：

• 群体思维：一个声音最大的人会主导讨论。
• 人们不会以群体形式使用软件。
• 得到的是看法，而非行为。
• 性格内向的参与者会被压制。

正确做法：

• 进行 一对一访谈，深入了解情况。
• 进行 一对一可用性测试，获取交互反馈。
• 仅在构思创意或了解社交动态时使用小组。

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

表现：

• 照字面理解功能请求。
• 用户：“我想在这里加个按钮，用来打印 PDF。”
• 设计师：“好的，我会加一个打印按钮。”

为什么会失败：

• 用户提出的是针对某个隐藏问题的解决方案。
• 实际问题可能是“我需要把这些数据分享给老板”。
• 对移动应用来说，打印按钮可能并不是正确的解决方案。

正确做法：

• 反复追问“为什么？”
• 找出背后的待完成任务（分享数据）。
• 设计更好的解决方案（例如，自动发送报告邮件、实时仪表板链接），可能比 PDF 按钮更有效地解决问题。

❌ 反模式 4：验证作秀

表现：

• 只找员工或朋友进行测试。
• 代码发布后才进行测试，只为“勾选完成”。
• 因为“用户没理解”而忽视负面反馈。

为什么会失败：

• 确认偏误。
• 把资源浪费在开发错误的产品上。

正确做法：

• 尽早使用低保真原型进行测试。
• 招募不了解产品的外部参与者。
• 把负面反馈视为宝贵信息——它能节省工程时间。

---

---

7. 质量检查清单

研究严谨性：

• **招募：**参与者符合目标用户画像（而不只是朋友或同事）。
• **同意：**所有参与者均已签署 NDA/同意书。
• **偏见检查：**问题保持中立且开放。
• **样本量：**样本量符合所用方法的要求（例如，定性研究 5 人，定量研究 20 人以上）。
• **试点：**在正式研究前，先与 1 名试点参与者测试研究方案。

分析与报告：

• **数据支撑：**每条洞察均关联证据（引述、观察记录或视频片段）。
• **可执行：**建议清晰、具体且经过优先级排序。
• **匿名性：**从共享报告中移除个人身份信息（PII）。
• **三角验证：**尽可能采用混合方法验证研究结果。
• **视频片段：**为利益相关方制作精彩片段集锦。

影响：

• **利益相关方评审：**向 PM/设计/工程团队展示研究结果。
• **跟踪：**将研究建议添加到 Jira 待办事项列表。
• **跟进：**检查已实施的变更是否真正解决了用户问题。
• **存储：**将洞察存入可搜索的资料库（例如，Dovetail、Notion）。

反模式

研究设计反模式

• 诱导性问题：暗示答案的问题——应使用中立、开放式问题
• 便利抽样：使用随手可得的参与者——应匹配目标用户画像
• 小样本推论：从小样本得出普遍结论——应说明局限性
• 确认偏误：只寻找支持性证据——应主动寻找相反证据

分析反模式

• 轶事证据：过度依赖个别引述——应综合不同参与者的证据进行验证
• 洞察过载：洞察过多且缺乏优先级——应聚焦关键发现
• 分析瘫痪：过度分析却得不出结论——应通过迭代形成洞察
• 缺乏综合：只报告信息而不归纳主题——应综合信息，形成连贯叙述

沟通反模式

• 术语过载：使用学术术语——应使用利益相关方熟悉的语言进行沟通
• PowerPoint 滥用：演示内容令人应接不暇——应聚焦关键洞察
• 洞察藏私：不广泛分享研究结果——应让更多人能够获取洞察
• 缺乏行动关联：洞察没有建议——应将洞察与产品决策联系起来

流程反模式

• 孤立研究：未与产品目标保持一致——应将研究与战略联系起来
• 一次性研究：不跟进建议的落实情况——应跟踪影响
• 研究孤岛：不以过往研究为基础——应维护研究资料库
• 时机错配：研究开展太晚，无法影响决策——应将研究融入产品流程