创建一个用户洞察力知识库来跟踪研究结果

Behance / 2023年5月10日

设计理论 73 1 0

如何创建一个用户洞察力库，以跟踪研究结果，并更好地沟通用户需求。

做用户研究，比如可用性测试、用户访谈和调查，当然是用户体验的核心，但是一旦研究结束，所有收集到的数据会怎样？我的经验告诉我，与用户的互动可以是非常有洞察力的，但是如果你没有办法把它们记录在可消化的大块中并传播知识，那么这些洞察力就会像它们获得的一样迅速丢失。这就是为什么我和同事们一起在我现在的公司Digitec创建了一个 “用户洞察力知识库”–我在那里担任D3产品系列的产品设计师，为外汇交易提供几种软件产品–以便在整个公司传播关于用户的知识，使工作更加以用户为中心，并且不再失去一个用户洞察力。这篇文章将介绍所有的好处以及如何创建一个用户洞察力知识库。

什么是用户洞察力知识库？

“知识库是一个关于产品、服务、部门或主题的自我服务的在线信息库”。- 阿特拉斯公司

这是对知识库一词的一个相当基本的定义，从字面上看，它可以是任何东西。但正如其名，用户洞察力知识库是一个知识库，用于分组和访问关于用户的所有洞察力–比如他们的问题和需求–特定产品。我将会告诉你更多关于如何构建其中的数据以及哪些类型的数据可以在用户洞察力知识库中存在，但首先让我们深入了解这样一个知识库可以解决哪些问题。

用户洞察力知识库解决的问题

把用户研究的结果分解成可以理解的小块：用户研究的结果往往是一份长长的报告，其中有一部分是可视化的，但通常需要大量的时间来阅读和理解。用户洞察知识库的目的是将其进一步分解，提供小块的信息–简短的见解而不是长篇大论。
跨部门沟通用户需求：在大多数公司中，并不是所有的员工，例如开发人员，都与客户有（密切）接触。然而，为了以真正以用户为中心的方式工作，每个人都应该对产品的开发对象有一个概念。因此，在各部门之间沟通用户的见解，并使其能够被理解是很重要的。
以用户为中心的决策：产品的决策除了要考虑可行性之外，还应该以用户需求为基础。为此，重要的是，重要的用户数据/见解要容易获取，并呈现给决策者，如产品经理、用户体验设计师和利益相关者。
沟通 “我们为什么要这样做？”：当开发一个新的功能或改进时，它所解决的问题并不总是那么明显。用户洞察知识库的设计正是为了让每个人都能获得这些信息。
让数据从你的头脑中出来并 “放到纸上”：如果太多的数据只存在于员工的头脑中，这对公司来说是致命的。如果一个员工离职或者干脆忘记了某些信息，那么很多知识就会丢失。用户洞察力知识库包含所有关于用户的知识，并作为一个中心位置和参考点。

如何建立一个用户洞察力知识库

用户洞察力知识库的总体概念是将尽可能多的原始数据，也就是与用户的互动或接触点的数据–如用户访谈的协议、分析数据或用户的电子邮件–纳入数据库，然后从中得出更有价值的数据，如用户洞察力、角色或机会解决方案树–我将进一步解释。

此外，用户洞察力知识库通过每一个数据点的关键词、其他相关数据点的链接和其他重要的标签，如我们的软件的 “用户角色”，保持可搜索性。由于我们在外汇市场有一个B2B产品系列，对我们来说，一个用户角色就是 “外汇交易员 “或 “贸易支持”。

机会解决方案树

在她的书《持续发现》中，Teresa Torres描述了一种持续发现未满足的客户需求和解决这些需求的解决方案的技术。她还发明了一种可视化的持续发现的形式：机会解决方案树。该树的目标是解决对公司结果影响最大的客户机会。

虽然Teresa Torres的机会解决方案树相当小，而且寿命很短，但我们决定它确实是一个很好的工具，可以将我们的用户洞察力知识库中的衍生数据结构化，使相关的用户需求可视化，并更容易找出解决方案或用户请求所要解决的需求。我们对机会解决方案树做了一些改变，包括区分请求（用户提出的解决方案）和解决方案（我们作为公司/团队制定的解决方案），我们将树顶改为用户的角色而不是公司的结果。

1pnXCzZdecZRvzjvIaI3gPQ — 修改后的机会解决方案树用于用户洞察力知识库中

这个机会解决方案树是用户洞察力知识库的主要成果。它使团队能够做出数据驱动的决策，并与用户产生共鸣。在我们的案例中，我们的主要机会解决方案树（针对外汇交易者的角色）有近1000个数据点和许多层的机会。但需要注意的是，最底层总是请求和解决方案层，而顶层是单一角色。

数据点

在我们进入实际使用中的情况之前，我想深入了解一下我们在用户洞察力知识库中使用的不同数据点：

原始数据：任何进入知识库的关于用户的数据点，例如来自支持热线的电子邮件，采访、演示或支持会议的协议，其他研究数据或分析数据。
机会（衍生数据）：用户的需求，痛点和欲望，可以从与用户的互动中得出（原始数据）。机会不需要是具体的，也不需要与软件的某个部分直接相关。
洞察力（衍生数据）：对用户的工作、公司内部程序的松散见解，或类似的见解，应该被记录下来。(这些可以与机会相联系，但不像树的其他部分那样遵循严格的规则)
请求（衍生数据）：一个用户提出的具体（功能）要求，例如：”需要有一个表格字段，我可以输入XY”。重要的是，请求不是 “读入 “用户说的东西，而只是真正被请求的东西。
解决方案：与请求类似，但这是一个由同事（如开发人员或用户体验设计师）在内部提出的对某个机会的解决方案。一个解决方案可以是一个模糊的想法和一个详细的计划之间的任何东西。实施细节并不是解决方案的一部分。

用Atlassian Jira实现

由于Jira是一个已经被采纳并在公司广泛使用的工具，我们也用Jira实现了用户洞察力知识库。然而，原则上，这里提出的基本概念也可以在任何其他工具中实现。

问题类型和链接

每个数据类型（Opportunity, Insight, …）都由一个自定义的Jira问题类型表示。对于原始数据，我们也创建了与我们相关的数据类型作为问题类型，目前这些是协议和电子邮件，据此我们在协议中总结了不同类型的 “数据生成”，例如，我们为用户访谈、与客户的演示或支持会议编写协议。

然后，不同的票据通过自定义链接相互连接–据此，链接类型也代表了票据之间的关系，后来被用来生成机会解决方案树。

“产生于 “和 “是原因 “的链接用于建立原始数据和派生数据之间的联系。此外，它还被用来表达一个原始数据点是支持还是反对一个解决方案（请求或解决方案）（”产生于 “与 “反对”）。

机会是以父子关系相互连接的。洞察力也可以通过同样的链接与机会相联系。此外，解决方案和请求可以通过 “试图解决”/”可能被解决 “的链接与机会相联系。

此外，还有与开发票（一种在用户洞察力知识库创建之前就已经存在的票据类型，由开发人员、产品所有者等使用和编辑）的链接。由此产生的关系使得软件开发可以很容易地访问用户洞察力知识库，例如，了解为什么要建立一个特定的功能，它解决了什么用户问题。重要的是，只有 “解决方案 “和 “请求 “可以直接链接到开发票，这就迫使人们在对 “解决方案 “做出最终决定之前，首先要找到并考虑一个机会的多种解决方案。

另一个直接集成到机会解决方案树中的开发票类型是特征票。它在树上被表示为机会的一个子项，并且本身可以有子项（机会、解决方案和请求）。这将使我们更容易识别与软件的某一特征相关的用户问题。

问题域和自定义指标

一个Jira票据（=数据点）有不同的字段，可以手动或自动填写。

作为手动字段，所有数据类型都有强制性的 “标题 “以及关键词。原始数据还有 “客户ID “字段，以及它们的实际内容（协议、电子邮件文本、截图…）。机会总是被分配给一个角色。此外，它们的名称有一些规则：它们总是以第一人称书写，通常以 “我想”（”IWT”）、”我需要”（”INT”）、”我必须”（”IHT”）、”我不知道”（”IDK”）和 “我不明白”（”IDU”）开头。解决方案和请求总是有一个描述，应该是描述解决方案的，但不涉及实施细节。此外，它们还有一个 “实施决定 “字段，可以是 “是”、”不是 “或 “无”（=尚未作出决定）。