UX 研究中建立可追溯引用的三种模式

在很多场合，我都见过产品高管们围坐在桌旁，仅凭他们当时恰好记得的研究数据，就为重大举措据理力争。即使他们的记忆是准确的（这本身就是一个很大的“如果”），并且客户研究确实被有效地应用了，但那个特定的洞察也无法得到验证，因为根本无法找到支撑该洞察的数据：缺乏可追溯性。如果研究的作者碰巧在场，他们或许能够指出该洞察的来源。

但无法保证研究作者每次其研究被引用时都在场以提供背景信息，也不能指望他们记住每一个来源。虽然有可能将这种能力系统化，但大多数组织——至少那些不属于科学或医疗领域的组织——尚未进行这方面的投入。因此，它们无法轻松核查洞察的来源——更正式地说，即引用——以便当场了解其背景。

“背景”在不同的研究、初步研究用途以及随时间推移的洞察应用中可能意味着不同的东西。例如，稳健的民族志方法可以构建关于客户世界的丰富背景描述，而范围狭窄的调查则可以保留特定样本及其在产品开发中时间点的背景特征。即使在稀疏、敏捷的文档中，精心选择的措辞也能讲述一个关于未被发现的需求和可能行动的大故事。在研究期间，至少在协作理想的情况下，研究人员及其利益相关者倾向于在会议、观察环节、展示与汇报以及通过消息应用程序分享故事。

随着时间的推移，他们会建立起一种共享的背景，这种背景会影响他们围绕该研究进行的每一次互动。这些故事之所以可知，是因为它们植根于协作之中。但在研究完成且研究人员及其利益相关者继续前进后，层层背景很容易丢失。维护背景溯源可能成为一项重大的知识管理挑战，也是一个建立存储、结构和连接的机会，从而从现有研究中运营性地榨取价值。

本文概述了如何在研究库中利用引用来实现更具背景丰富性的研究洞察使用，如何从计划链接到库内容以为产品决策者和洞察生成者增加价值（并为组织提供更多研究价值），以及如何通过引用模式有效地将这些链接付诸实践。我将分享良好、更好和最佳的示例。

编者注：本文最初发表于ResearchOps Review，您可在此阅读。

理解引用——以及为何它们至关重要

如果您读过（或写过）学术论文或书籍，您可能遇到过正式的学术引用。引用只是对原始来源的参考或致谢。在用户体验研究的背景下，引用是研究人员、团队或 ResearchOps 专业人员可以遵循的链接，以了解特定洞察是否以及在何处被应用于产品决策。每当决策者引用促成特定选择的洞察——他们的洞察时，每位研究人员都会感到高兴。

尽管生成式 AI 工具正在使参考链接规范化——像 Google 的 NotebookLM 和 Perplexity 这样的深度研究工具将引用作为标准配置包含在内——但“citation”（引用）这个词在产品开发环境中可能显得过于学术化。我建议在此类使用场景中避免采用正式的引用标准，如 APA、MLA、Chicago 或 IEEE。使用引用的目的是在研究与产品文档之间建立上下文；重点在于使上下文可追溯，而不是吹毛求疵或追求学术完美。尽管如此，引用的核心前提在产品环境中具有不可替代的价值，原因如下。

促进对证据的深入探究

我在 ResearchOps 知识管理领域工作时，经常需要跟进路线图主题、产品需求文档、设计及其他交付物的作者，以了解所引用的客户语录或统计数据来自何处。对于其中一些查询，答案并不令人信服，往往依赖于精心挑选的信息片段来为已经在推进的想法提供理由。而在其他时候，由于存在引用，我可以清楚地看到洞察的来源研究。我知道可以深入研究某份报告或联系研究人员以获取更多信息。收集更多背景信息的能力帮助我建立了信任，从而能够使用可追溯的证据来支持决策。但这不仅仅关乎对我个人有效的做法；引用也有助于在整个产品组织中扩展信任。

改进研究影响追踪

在技术组织工作的研究人员经常被要求展示其工作成果的影响。为了有效满足这一期望，许多研究从业者会主动寻找方法来记录他们的影响力和结果。在一次 Learners 会议演讲中，题为“Impact and UX Research: What Is It and How Do We Know We've Achieved It?”，Victoria Sosik 分享了一些基本的可追踪影响类别，例如促成未来的合作和影响产品策略，以及记录个人成就（或引用它们），以便在状态报告中汇编和共享。

研究人员完成研究后，追踪研究与规划之间的联系可能会变得模糊不清。研究人员通常希望决策者能在初始项目之外，继续从他们的研究库中发现价值并加以利用。但是，即使“旧”洞察在当前计划（待办事项列表、规格说明、用户故事、路线图、目标和设计等）中产生了影响，除非有某种形式的引用，否则这些影响往往是无法追溯的。

在研究库中构建上下文

我从 2013 年开始专注于研究库设计，当时我是亚马逊的一名首席研究员（后来过渡到 ResearchOps 角色），那时研究库的工作尚处于前沿阶段。当时的用户体验研究团队产生了大量深入的洞察，为客户和业务带来了可衡量的影响。即使有了这些即时成果，研究人员收集的过往学习成果仍然能为未来举措提供很多价值——研究这棵果树上还有汁水可榨。为了收获这份研究财富，团队调整了一个常用的现成问题跟踪工具，使其充当洞察级别的研究库。随着时间的推移，该库在三个部门的多个产品团队中的采用率逐渐增长。

随着采用率的提高，我注意到一个令人惊讶的现象：决策者开始在自己的工作成果中引用研究文献，例如产品需求文档、路线图和战略文件。对特定洞察的引用出现在各种交付物中，有时这些交付物是由研究人员从未见过的同事创建的。值得注意的是，引用出现在产品团队的发布公告中。一些产品负责人在将关键业务指标的提升归功于自己时，会引用那些激励并塑造其发布的研究洞察链接。因此，研究人员能够将他们早期的工作与具体的胜利联系起来，而这些胜利需要花费一些时间——以及许多人的努力——才能实现。这不仅仅是一种普遍的概念性影响。这些发布数据是对北极星关键绩效指标（KPI）的具体、可追溯的改进。由于引用了研究，研究团队能够汇总这些跨发布的指标，以展示集体影响力。

在维护（甚至建立）这种引用实践方面，研究资源库是一个重要的杠杆。虽然定义差异很大，但我倾向于将研究资源库视为用于研究存储、访问和使用的有意为之的“场所”。资源库不必是专门构建的工具——人们经常使用标准的工作流工具来构建资源库——但它可以是。尽管技术很重要，但围绕它建立的协作意图和运营才是使资源库有效的关键。越来越多的情况下，这些运营可以扩展到构建 检索增强生成（RAG）系统，并将 AI 代理（连同人类）视为常规的资源库用户，其中关键要求是通过 模型上下文协议（MCP）提供结构化和机器可读的内容。

回到亚马逊的故事，在你急于尝试复制它之前，请记住这一经验只是针对特定时间和背景为研究资源库提出的一个想法。研究资源库是系统，而系统可以根据设计要解决的问题采取多种形式。例如，一些研究组织需要一个支持研究工作流关键方面的资源库，如转录视频访谈和标记新兴主题。其他研究组织则专注于通过多种研究为重要的用户洞察构建证据。还有许多其他可能的结果，并非每个解决方案都能满足所有要求，但无论你的要求或技术是什么，深思熟虑地记录上下文是关键。

建立引用研究的模式

定位证据并引用它——即进行引用——是需要付出努力的，而在忙于完成主要工作的过程中，决策者可能不会优先考虑这项努力。即使 AI 已经完成了创建指向支持性研究内容链接的工作，决策者也可能不会想到保留这些联系。当他们确实引用研究来源时，你很可能会看到方法上的巨大差异，且没有真正的原因，而有些方法会比其他方法更好。

研究引用模式可以通过明确重视什么和期望什么，并提供人和 AI 都能用来嵌入清晰、一致、（人类和机器）可读的引用的标准来解决其中一些问题。在 Stop Wasting Research 的第 11 章中，我写过研究团队和内部社区如何共同设计引用模式。我写道：“你的知识管理工具的早期采用者会发展出各自不同的方法，将基于研究的理由纳入他们的待办事项列表、路线图、目标、设计、规范和其他规划交付物中。你不必等待这些模式自然出现——你可以制定可追溯的研究引用标准并鼓励其采用”（第 237 页）。那些“可追溯的研究引用标准”就是我现在所说的 citation patterns（引用模式）。在那一章名为“Link Research Rationale to Plans”（将研究理由与计划关联）中，我确定了具有不同引用内容量的示例模式，从仅包含信息性链接的基本引用，到将深入探究带入引用本身的全面研究摘录。

最近，我意识到在引用中链接的信息类型也是一个值得形成模式的要素。如果你进行一次审计，审查组织中人们如何在规划文档中引用研究——假设这些文档存在——你可能会发现决策者引用了非常不同类型的研究内容，从单个证据点到整份研究报告。这些现有的例子可以是构建更正式化模式的一个很好的起点。

以下三种模式代表了一种观点，即产品决策者——或任何人——的交付物中好的、更好的和最佳的研究引用可能是什么样子的。请记住，这套模式并非详尽无遗。此外，这些模式也不是万无一失的。决策者仍可能在计划中引用错误的洞察。然而，这些模式可以使基于研究的理由的应用更具可发现性和可评估性，使组织中的任何人都能更容易地评估数据是支持还是反驳产品决策。

Good (Pattern 1): Linking to Research Evidence

第一种模式是关于引用研究证据片段作为决策的理由，并提供指向证据存储位置的链接。例如，我曾审阅过一位设计师的 PowerPoint 幻灯片，其中链接到存储在共享驱动器项目文件夹中的研究亮点视频集锦，该驱动器充当了一个基本的集中式研究库。这是一种有力的视频证据，可以用来证明设计方向。但要理解视频的背景及其所属的研究，我必须浏览文件夹结构，起初这感觉像是一个毫无信息量的文件名列表，才能找到研究名称和计划（见图 1）。我需要四处摸索才能了解更多关于视频的信息以及它产生的背景。

或者，这种引用模式可能深度链接到一个专门的分析工具，该工具同时充当研究资料库。如果查看者有权限访问该应用程序并愿意深入探索，他们或许能够看到项目中相关的主题、分析和数据。

模式 1 的优点：

• 链接目标可能会提供关于谁创建了证据以及研究性质的上下文线索（也可能相当不透明）。
• 跟随链接可能有助于进行一些上下文调查以了解更多内容。

模式 1 的缺点：

• 决策者需要知道去哪里寻找证据，并浏览内容直到找到支持其理由的相关佐证。
• 有限的上下文可能使得难以判断引用的证据是为了支持某个选择而精心挑选的，还是经过精心设计的研究过程的结果。
• 根据用于存储证据的资料库工具，审阅者可能只有很少的选项来导航和查找更多信息。
• 同一学习在不同研究中的额外证据未包含在链接目标中，降低了研究的清晰度和说服力。
• 研究治理政策可能导致证据被删除，从而造成引用中出现死链。

这种模式并不理想，但总比没有好。使用一致的描述性元数据可以提高单个证据片段的可读性。一位同事曾将描述性元数据称为研究资产的“营养成分表”。这些描述性信息还可以帮助 AI 代理在执行任务时选择哪些信息拉入其上下文窗口。

作为一个研究资料库贡献者社区共同定义一套标准化的元数据是有价值的。像 ResearchOps Community 发布的标准，例如 Ian Hamilton、Emily DiLeo、India Anderson、Mark McElhaw 和 Annette Boyer（代表整个 Research Repositories Program Team）编写的 “Minimum Viable Taxonomy Level 1”，可以作为讨论的起点。

更好（模式 2）：链接到研究报告中的洞察

第二种模式是关于一个标题，它引用了来自单个研究报告的理由，并链接到其在研究资料库中的目标位置。那个链接的研究报告可以为引用中的具体发现提供丰富的上下文。链接的报告还可以鼓励从同一研究的其他领域进行额外学习。例如，我很高兴看到产品领导者的需求文档中有链接到研究报告的引用。仅引用文本本身就提供了强烈的上下文线索，而链接的文档则提供了更多线索（见图 2）。

‍

模式 2 的优点：

• 命名的研究链接提供了关于谁创建了引用证据以及研究性质的上下文线索。
• 引用本身使用了研究语言，展示了研究人员作者的解读工作和有意为之的框架设定。
• 链接的报告可以提供丰富的上下文信息，具体取决于文档的深度。
• 链接的报告本身可能包含指向特定证据的链接，类似于模式 1。
• 研究人员通常会创建报告，因此将这些成果贡献到研究库中的工作量并不大（并且可以通过一些自动化来提供支持）。

模式 2 的缺点：

• 使用此模式的决策者需要知道研究存储库的存在、拥有该工具的访问权限，并了解所需的引用标准。
• 根据所使用的存储库工具，你可能无法使用 锚链接（直接指向文档中特定位置的链接）。如果链接未能将读者带到页面上的正确位置，理解和评估引用的理由可能需要额外的阅读和认知负担，这虽然可能带来更深入的理解，但也存在失去注意力或耐心——或者两者兼有——的风险。
• 同一学习成果在不同研究中的额外证据并未包含在链接目标中。如果同一个洞察在其他地方被发现了十次，单个报告通常不会纳入这些扩展证据。

最佳方案（模式 3）：链接到洞察摘要

第三种模式涉及一个定义明确的洞察标题，它链接到一个特定的、预先准备好的洞察摘要，其中包含从各报告中摘录的证据。这些洞察摘要充当了关于单一洞察的研究的一站式商店。鉴于准备洞察摘要需要专门的努力（这项任务可能由生成式 AI 支持），研究人员可能只为他们希望看到更多行动的高优先级、未被充分利用的顶级洞察准备摘要。

我见过由产品经理准备的 CEO 级倡议规划文档，其中包含链接到洞察摘要以证明特定待办事项列表项的合理性。在审查规划文档时，这些洞察摘要的标题可以被视为关于用户需求的独立陈述（见图 3）。跟随引用链接会导向一个丰富的清单，其中包含迄今为止相关研究的证据。这些引用的具体性使得能够跟踪复杂主题领域中针对个别客户问题的进展。

洞察摘要可以作为常见生产力工具中的简单文档来实现，也可以在专门的存储库软件中作为更复杂的东西来实现。类似于记录和更新  “营养成分表”（或描述性元数据），存储库贡献者可以共同制定共享标准，规定他们如何记录和更新洞察摘要。

模式 3 的优点：

• 清晰的标识符提供了一个品牌线索，表明这项研究来自特定社区，并存储在特定的、可信的研究存储库中。
• 由研究人员撰写的洞察标题提供了核心的用户观察和业务影响，展示了研究人员的集体解释劳动，并精确地框定了下一步行动。
• 洞察寻求者可以深入探究并被单一“场所”中的特定洞察所说服，审阅所有支持（甚至矛盾）的证据。洞察摘要保留了摘录研究的上下文，同时在跨研究中构建新的意义。
• 与模式 2 类似，洞察摘要内的链接报告提供了丰富的上下文信息，具体取决于文档的深度。洞察摘要可能允许对证据进行更深入的检查，包含类似于模式 1 的链接。
• 每当一份洞察摘要产生影响时，其内容所涵盖的研究人员都可以获得认可。（这可以成为研究人员参与撰写摘要的强大动力。）

模式 3 的缺点：

• 与模式 2 一样，使用此模式的决策者需要了解研究库、有权访问该工具（或已从收集目录中收到“他们的”相关洞察列表），并了解所需的引用标准。
• 研究人员需要在典型研究流程之外付出额外努力，为顶级洞察创建洞察摘要。生成式 AI 在此过程中可能很有用，它可以回答有关标准的问题、识别跨研究的潜在证据以支持洞察摘要，并帮助格式化摘要中的内容。

通过正向反馈循环实现保存

类似于在生成式 AI 聊天摘要中显示参考文献的价值，在规划交付物中显示指向相关研究的链接是那种能展开为更清晰、更可信图景的“双击”。当一些团队探索如何将整个 UX 研究库变成 AI 代理的上下文输入时，人们很容易认为这类引用已经过时——仿佛知道研究在哪里被应用正在成为一种陈旧的想法。事实并非如此。重要的产品决策始终会从清晰的理由中受益，而这一基本需求正是研究运营可以寻找新方法去满足的。如果说有什么变化的话，那就是 新技术可能会提供识别和支持引用的新颖方式。

与产品开发的许多方面一样，没有单一的角色或个人负责在产品决策中成功进行研究引用。鉴于此，洞察驱动的领导者和研究库贡献者可以突出他们希望看到变得更普遍的行为。我发现，公开庆祝那些引用了研究的成功产品发布和实验，可以推广将引用视为值得采用的最佳实践这一理念。

即使你的组织拥有一个内容丰富的研究库，你也永远不会看到关键产品决策中对研究引用的完全采用。但提高引用的频率可以将研究人员现有的学习成果注入到更具战略性的规划决策中——这是高管领导层关注的类型。反过来，增加引用频率可以激励研究人员更投入于为其共享研究库做出贡献，从而建立互联学习的深度。随着正向反馈循环持续运转，研究影响范围扩大，客户和业务的结果也随之改善。这一切都源于保持研究学习成果的活力、保留其背景信息，并将其连接到新的、有意义的选择中——从标题到深入剖析。