# OfferKu B2B 用户研究与需求证据模板

版本：2026-08-13

这套无需注册即可使用的模板把两类记录分开：

- offerku-b2b-interview-guide.csv：一场访谈中的问题、行为、原话或事实笔记。
- offerku-b2b-requirement-evidence-matrix.csv：跨访谈合并后的问题证据、方案路线与决策状态。

CSV 中的 example 和 synthetic 行全部是合成示例，不代表真实个人、公司或研究结果。空白行用于直接填写。模板不构成隐私、数据保护、伦理或法律意见；请让组织内的数据保护、信息安全或法律负责人审核你的实际做法。

## 角色图

不要只访谈采购者或提出需求的人。一个 B2B 流程通常同时受到目标、规则、日常操作和系统约束。

    业务发起人 / 采购者
              │ 目标与预算
              ▼
    流程负责人 / 审批人 ── 规则 ── 安全与合规
              │
              ▼
    请求者 / 一线用户 → 一线操作员 → 系统管理员
              ▲                         │
              └──── 实施 / 支持团队 ────┘

根据研究问题选择相关角色，而不是机械覆盖所有角色：

| 角色组 | 需要了解的内容 |
| --- | --- |
| 请求者、一线用户 | 目标、触发条件、实际步骤、等待和返工 |
| 一线操作员 | 高频任务、例外、手工补偿和上下游交接 |
| 流程负责人、审批人 | 决策规则、责任、时效和升级路径 |
| 系统管理员 | 权限、配置、集成、数据和维护成本 |
| 安全、合规、财务 | 风险、审计证据、保留和控制要求 |
| 采购者、业务发起人 | 业务结果、预算、采用约束和成功标准 |
| 实施、支持团队 | 可重复差异、一次性差异和长期支持负担 |

## 从计划到决策的使用流程

### 1. 把假设改写成研究问题

先写团队必须知道什么，才能做下一步决定。把“客户需要自动审批”改为“用户目前如何发起和审批请求，哪些步骤造成延误或风险”。一个研究轮次只保留最重要的问题，并明确要覆盖的角色和流程阶段。

### 2. 招募、知情同意和个人信息最小化

招募当前用户或很可能执行该流程的人。邀请前提供易懂的信息说明，至少包括：

- 谁在研究、目的是什么、活动会发生什么；
- 会收集哪些数据、如何使用、与谁共享、保存多久；
- 是否有人旁听，是否录音、录屏或录像；
- 参与完全自愿，可以停止或撤回同意；
- 数据控制者、其他处理方以及联系或投诉渠道。

每位参与者都要留下与组织流程相符的知情同意证据。录音和录屏需要单独明确。参与者不同意记录时，recording_status 应写明未记录，不能默认录制。

最小化个人信息：

- CSV 只用不透明的 research_id 和 session_id。
- 不写姓名、邮箱、电话、精确地址、账号、客户机密或可识别公司的细节。
- 联系信息、同意记录和研究笔记分开存放，并限制访问。
- 原话进入 CSV 前去标识化；没有必要时，用事实笔记代替逐字引语。
- 按已告知的保存期删除信息，并确保撤回同意时可以定位和删除相关材料。

### 3. 使用开放、中立、基于事实的问题

从最近一次真实事件开始，不要让参与者预测未来：

- 推荐：“请带我回顾你上一次完成这个任务的过程。”
- 推荐：“接下来发生了什么？”“你当时看了哪些信息？”“哪里需要等待？”
- 避免：“如果我们做自动审批，你会使用吗？”
- 避免：“这个步骤是不是很低效？”

neutral_prompt 只写开场问题；临场追问可以记录在 evidence_quote_or_note。优先请参与者展示当前工具、材料和步骤，并在得到相应同意后记录。

### 4. 把事实、原话和解释分开

访谈表中的信息应保持可追溯：

| 字段 | 记录规则 |
| --- | --- |
| observed_behavior | 可观察事实，例如打开了什么、复制了什么、等待了多久；不要写原因推测 |
| evidence_quote_or_note | 去标识化原话或事实笔记；说明是原话还是研究者笔记 |
| current_workaround | 用户今天实际采用的替代路径 |
| frequency、impact | 参与者描述或团队验证的范围；不确定时明确写 unknown |
| follow_up | 下一次需要观察、核对或反证的事项 |

解释和综合判断放到证据矩阵的 problem_statement、evidence_strength 和 solution_route，不要倒填成参与者“说过”的事实。

### 5. 合并证据，而不是累计意见票

完成一轮访谈后：

1. 统一 role_type 和 workflow_stage 的命名。
2. 按同一个底层问题聚合记录，保留可回查的 source_session_ids。
3. evidence_count 统计独立会话数，不统计一句话被复制了几次。
4. 检查问题是否跨相关角色、细分公司和真实行为重复出现。
5. 分别判断 frequency、impact 和 risk；高声音不等于高频，高职位不等于强证据。
6. 主动寻找相反证据、成功路径和不受影响的角色。

evidence_strength 可采用团队定义的等级：

- weak：单一会话、转述、未来意愿或尚未观察的假设。
- directional：多个独立会话出现相同模式，但角色或细分覆盖仍有限。
- strong：在目标范围内反复出现，并有行为、工件、日志或其他证据交叉印证。

这些是判断框架，不是固定样本量公式。样本应随风险、差异性和决策成本调整。

### 6. 判断标准功能、配置、定制或不做

按顺序判断，避免从客户提出的方案直接跳到开发：

1. 问题是否真实、重复且足够重要？
2. 哪些角色和流程阶段受到影响？边界是否清楚？
3. 现有产品、流程或配置能否解决？
4. 解决后如何验证行为或结果变化？
5. 实施、安全、隐私、迁移和长期支持成本是否可接受？

| solution_route | 何时使用 |
| --- | --- |
| standard_feature | 多个目标客户共享稳定问题，符合产品核心，统一行为能带来清晰价值 |
| configuration | 底层工作流相同，但字段、规则、角色、阈值或界面需要由客户配置 |
| custom_extension | 需求已验证但边界窄；有明确商业价值、接口边界、所有者和支持模型 |
| do_not_build_yet | 证据弱或冲突、已有替代方案足够、偏离战略，或风险与维护成本高于价值 |

每个决策都填写 owner、next_test、decision_status 和 review_date。“不做”可以是当前证据下的可逆决定，而不是永久否定。

## CSV 字段说明

访谈表：

| 字段组 | 字段 |
| --- | --- |
| 追踪 | research_id, session_id, owner |
| 样本与场景 | role_type, company_segment, workflow_stage |
| 研究设计 | research_question, neutral_prompt |
| 原始证据 | observed_behavior, evidence_quote_or_note, current_workaround |
| 严重程度 | frequency, impact |
| 治理 | consent_status, recording_status |
| 下一步 | follow_up |

证据矩阵：

| 字段组 | 字段 |
| --- | --- |
| 需求 | requirement_id, problem_statement, workflow_stage |
| 覆盖与来源 | role_types, evidence_count, source_session_ids |
| 严重程度 | frequency, impact, risk |
| 当前状态 | existing_workaround, evidence_strength |
| 决策 | solution_route, decision_status, owner |
| 学习闭环 | next_test, review_date |

多值字段使用分号分隔。日期建议使用 YYYY-MM-DD。保持 ID 稳定；不要在排序后重新编号。

## CSV 安全与质量检查

- 两个文件采用 RFC 4180：第一行为表头，每行字段数一致，字段用双引号包裹。
- 不要让任何 CSV 单元格以等号、加号、减号或 at 符号开头，避免电子表格公式注入。必要时改写为安全的纯文本标签。
- 导入表格软件时，把 ID、状态和日期列显式设为文本或日期，不要让软件自动改写。
- 发布或分享前检查个人信息、客户机密、同意范围、重复 session_id、缺失来源和无所有者的决策。

## GOV.UK 官方参考

- [Plan user research for your service](https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service)
- [Using in-depth interviews](https://www.gov.uk/service-manual/user-research/using-in-depth-interviews)
- [Getting informed consent for user research](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research)
- [Managing user research data and participant privacy](https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy)