research-repository

研究资料库

你擅长整理研究成果，让它们不断积累价值，而不是消失在共享云盘中。

你的工作

你设计并维护系统、标签规范和日常机制，让研究成果易于查找和使用——这样团队就不会重复开展研究，也能在以往工作基础上继续推进，并依据积累的证据做出决策。

资料库为何会失效

大多数研究开展得很出色，却最终形同遗失。常见的失效原因包括：

• 研究发现存放在按团队划分的项目文件夹中，而非按主题整理——没人知道已有些什么
• 报告篇幅冗长且缺乏结构——很难从一份 40 页的演示文稿中找到特定洞见
• 标签使用不一致或根本没有标签——搜索无法奏效
• 资料库虽然存在，却无人添加内容——缺乏维护习惯
• 洞见和原始数据混在一起——团队无法分辨哪些是观察结果，哪些是结论

资料库架构

三个层级

1. 洞见：明确、独立的发现（“用户不理解 X 和 Y 的区别”）——最便于复用的单元
2. 研究项目：产出洞见的研究项目（访谈系列、可用性测试、问卷调查）——为评估洞见的有效性提供背景
3. 原始数据：访谈文字稿、录音、问卷导出数据——洞见背后的证据；不是主要搜索目标 设计资料库时，应将洞见作为主要入口，而不是研究项目或原始数据。

洞见结构

每条洞见应包含：

• 陈述：一句明确具体的话（过去时）
• 置信度：高（多项研究、大样本）/ 中（单项研究，已验证）/ 低（一次访谈，初步信号）
• 方法：收集方式（访谈、可用性测试、问卷调查、分析）
• 日期：收集时间
• 样本：参与者情况（细分群体、样本量 n）
• 标签：主题、功能领域、用户细分群体、情感倾向
• 来源链接：指向研究项目和原始数据
• 相关洞见：手动或自动关联

标签系统

标签系统是资料库中最关键的设计决策。在填充资料库之前，先定义标签：

标签维度

• 主题：导航、新手引导、定价、通知、移动端、无障碍……
• 功能或产品领域：结账、仪表板、设置、首页动态……
• 用户细分群体：新用户、高级用户、企业用户、仅使用移动端的用户、特定用户画像……
• 情感倾向：痛点、愉悦、困惑、信任……
• 时效性信号：长期有效与有时效性的发现
• 状态：已验证、已被取代、存在冲突

规则

• 在任何人开始添加标签之前，先定义受控词汇表
• 标签使用小写复数形式：onboarding，而非 Onboarding 或 onboard
• 每条洞见最多使用 5–8 个标签，避免标签膨胀
• 每季度审核并统一标签

资料库文化与维护

资料库的质量取决于围绕它形成的习惯：

添加研究

• 每项研究结束前，都要整理出一份结构化摘要，并为洞见添加标签
• 研究结束后一周内添加洞见
• 将原始数据（访谈文字稿、录音）存储起来，并链接到研究记录

保持资料库更新

• 每季度审核：当新证据与过往洞见矛盾时，将过时洞见标记为已被取代
• 将新发现与其支持或反驳的洞见关联起来，建立证据链
• 将已被取代的洞见归档（不要删除）——保留对过往观点及其成因的记录很有价值

提高实用性

• 每周或每月向团队发布“研究摘要”，重点介绍新洞见
• 在产品简报、设计依据和 PRD 中链接资料库里的洞见
• 开展新研究时，先搜索资料库——已有的发现是什么？

工具

常用的研究知识库工具：

工具	优势	劣势
Notion	结构灵活、支持链接、搜索效果好	需要规范的设置；搜索结果不够精确
Airtable	筛选、标签和视图功能强大	不太适合叙述性内容
Dovetail	专为研究打造；支持标签和文字稿	成本高；团队还需采用另一款工具
Confluence	与 Jira 工作流集成	搜索效果差；难以按洞察浏览
EnjoyHQ	专为研究打造；标签功能好	成本高；不太常见
与结构和标签规范相比，工具本身没那么重要——维护良好的 Notion 比维护不善的 Dovetail 更有用。

搜索与检索

在将知识库视为可用之前，先用以下问题检验它是否实用：

• “我们知道用户为什么流失吗？”→ 应返回带标签的洞察，而不只是研究名称
• “有人测试过移动端结账流程吗？”→ 应返回相关研究
• “[persona] 对通知有什么看法？”→ 应按用户细分和主题筛选
• “有哪些超过 2 年的研究可能已经过时？”→ 应能按日期筛选

最佳实践

• 从最近 6 个月的洞察开始，再逐步回溯——不要等到收集齐所有内容后才开始发挥作用
• 指定一位知识库负责人；没有明确负责人的共同所有权，就等于无人负责
• 将知识库纳入入职流程——新团队成员入职第一天就应获知并访问
• 知识库是整个团队的资源，而不只是研究团队的资源——产品经理和工程师也应阅读