大家好，我是张聿彤。用户体验研究是一个很宽泛的话题，也是一个很精细的工作。在体验上可以割裂成很多个问题，我们也可以就每一个问题出一份研究报告甚至一个研究文档库。但是，当问题变迁，项目流转之后，过往的研究报告也早已落满了灰……所以，我们需要原子用户体验研究，把研究报告“细分切片”，随时可以拿起其中一个片段反复端详，不断复用，而且从现象到解决方案的推演上，这种方法也更为科学。

你可能之前听说过 Atomic Design（原子设计），现在 Atomic Research（原子研究）来了，这是一种以无限强大的方式组织用户体验知识的新方法。

       在 Glen.ly 工具中的原子研究卡

简而言之，原子研究是将用户体验知识进行合理地分解：

                              

• 实验“我们这样做了……”
• 事实“……我们发现了这个……”
• 洞察“……这让我们认为……”
• 建议“……所以我们会这样做。”

通过像这样分解知识，就非常有可能发现非常之处。

1. 它是如何开始的

去年，我在一家 FTSE 100 科技公司工作。我们试图解决的问题是如何为业务中每个人提供合理的方法进行存储和分发用户体验知识，让他们都可以使用并从中受益。

就目前而言，UX（用户体验）团队、BA（商业分析师）和 PM（产品经理）将进行“实验”，写下他们了解到的东西以及如何使用这些知识。这些通常以 PDF、Google Docs 或 Slide-decks 的形式制作，然后归档在 Google Drive 中。

这些原本都是很好的，直到某一个人开发了一个功能，可以帮助我们快速找到已知所需的东西，然而即便找到了，却发现很难将这些用于另一个项目。

听起来有点熟？

大胆假设一下：“如果我们的用户体验知识不是在文件和文件夹中堆积灰尘，而是采用可搜索和可共享的格式，那会怎样？”

会简单对吗？我们没有将研究放入 PDF 中，而是将它们放入某种在线存储库，也许是某种维基？

我开始研究这种存储库，希望可以找到能够使我们的研究可标记和可搜索的东西。有一些系统声称可以做到这一点，但很明显，这些系统都是针对做小型、独立项目的小公司，并不适合处理大型项目。

研究通常非常聚焦于你正在研究的领域。这似乎是一个明显而毫无意义的陈述。但这很重要 —— 比如说我进行了一些研究，结果之一是我们了解到绿色在号召性用语上比红色更有效，这意味着它在那个非常特定的领域或对于某个角色……或两者兼而有之更有效。但这并不意味着我们就应该改变整个 UI 的颜色。

这种存储库要么不允许你为研究提供适当的来源，要么相反，让你无法在狭小的“围墙花园” 围墙花园【1】”之外发现和利用研究，这些研究并不比共享驱动器中的 PDF 文件更好。

(【1】：围墙花园（walled garden）：是一个控制用户对应用、网页和服务进行访问的环境。）

围墙花园把用户限制在一个特定范围内，只允许用户访问或享受指定的内容、应用或服务，禁止或限制用户访问或享受其他未被允许的。

我们需要的是以下能力：

• 记录并正确分类研究
• 以简单而灵活的方式进行搜索
• 了解研究的来源、环境和局限性
• 发现模式
• 支持基于证据的方法

彼时，正如 UX 设计师惯常做的那样，我也正在和一位同事讨论将研究分解为简单的部分。我非常感谢这位同事David Yates，因为我认为是他开始谈论如何将数据与洞察区分开来。

他提到了马斯洛需求层次。当我们交谈时，我们意识到可以将一项知识分解为 3 或 4 个部分。这种“众多小细节导致更大发现”的想法让我想到了原子设计。

当我们讨论它是如何工作以及像这样分解研究的好处时，我知道我们发现了一些重要的东西。

而且更为神奇的是在，之前就有类似的结构！那就是 DIKW 金字塔（数据、信息、知识和智慧），我们不小心“发明”了一个现有的，备受推崇的，至少有 60 年历史的科学数据模型！

尽管如此，这只是向我证实了这是看待用户体验研究的好方法——我觉得到处说“DIKW”（大多数人似乎都会念成dickwee）并不出色，而且我们的模型也略有不同，所以，我相信原子研究是一个更好的术语。当我将之与原子设计比较时，人们也更容易理解。

我已经使用原子研究原理近一年了，我觉得它确实是一种非常有用的思考产品知识的方法。

那么什么是原子研究？

2. 实践中的原子研究

2. Atomic research in practice

               

实践中的原子研究——真实知识的样子。

实验——“我们这样做了……”

我们从中获取事实的实验。

事实 ——“……我们发现了这个……”

从实验中我们可以收集到事实。事实不做任何假设，它们永远不应该只反映你的意见，而应该是“发现了什么”或“用户的情绪”。

例如：五分之三的用户不理解按钮标签。

洞察力——“……这让我们认为……”

这是你可以解释你发现事实的地方。一个或多个事实可以联系起来以产生洞察。即使它们来自其他实验。有些事实可能会反驳一个见解。

例如：按钮上使用的语言不清楚。

建议——“……所以我们会这样做。”

建议是关于如何使用从事实中收集到的宝贵见解与想法。与建议相关的见解越多，你对其价值的证据就越多。这有助于确定工作的优先级。

例如：让我们为按钮添加图标。

3. 多个来源意味着更好的决策

3. Multiple sources mean better decisions

     

 

我从这种方法中注意到的第一个好处是，不止一个事实可以支持或反驳一个见解，而且不止一个见解可以支持或反驳一个建议。

最终导致推荐的事实越多，你对这条前进路线的信心就越大。

               

         

同样，一个事实也可以通过多种方式来理解，并且可以从洞察中得出几个建议。因此，一个事实可以有很多见解，而一个见解可以有很多建议。

只要我们还在测试它们，就会源源不断地生成更多证据并证明哪些是正确的，哪些并不重要。直到我们有更多的证据可以联系起来证明或反驳一个洞察。

4. 最好的事情……适用于多个实验！

4.The best thing… This works across multiple experiments!

               

          

这与我们接下来所做的事情有关，但不依赖于我们接下来所做的事情，因为我们的发现与我们发现它的方式有关，但不依赖于我们发现它的方式，这让我们有机会利用多个实验的事实来支持一个单一的见解。我们可以从任何地方获取见解来创建建议。我们可以从组织中的任何地方发现相关结论的模式，以指导我们走向未来。

最初引导洞察的实验可能早已被遗忘，不再相关。但来自其他来源的证据继续支持这一见解，支持它并使其成为真理。

结果不再保留在特定研究的这个小泡泡（文字描述框）中，我可以提供尽可能多的证据来做出重大决定。

5. 研究不再是线性的

5. Research is no longer linear

一旦我们提出建议，也需要对其进行测试。

假设我们有一个洞察，说人们不理解我们的按钮。一项建议可能是向这些按钮添加图标。我运行了一个用户测试，似乎表明它有助于理解。现在，我想在实时系统上运行拆分测试。最终，数据进来并表明实际上这不起作用……害！

但好消息是我可以使用这些数据来反驳我的建议，同时保留导致该建议的见解完好无损。事实上，失败的测试数据可能会削弱一些洞察力，但实际上会加强其他洞察 —— 它可能证明另一种洞察是正确的。这无疑有助于我们更清楚地了解如何改进我们的产品。

传统的报告方法在一段时间内被卡住了——“我们的研究告诉我们……”在编写该文件时可能是正确的，但当几个季度后发现它不正确时，然而它不太可能被更新。

通过将见解独立于其来源，意味着它们可以不断地被重新检验，并允许它们根据证据生死存亡。

这导致了我认为最重要的好处：

6.原子研究迫使循证思维

6. Atomic research forces evidence based thinking

如果我没有支持建议的见解，我将无法创建建议。没有事实，我无法创造洞察力。我拥有的每个资源越多，我们对我的建议就越有信心。当然，我可以欺骗并说一个事实支持我的洞察（或者只是被误导了），但对于任何看起来不支持的人来说都是显而易见的。

原子研究证明了我的断言。

7. 实践原子研究的工具

7. Tools to practice Atomic Research

近一年来，我一直在自己的工作中使用 Atomic Research（原子研究）。

在这段时间的大部分时间里，我一直在手动执行此操作。用手绘线条在白板上写上粘滞便笺。这对于以小方式处理结果很有用，但它只是暂时的并且不太便于共享。

下一步是使用诸如draw.io 之类的思维导图工具——这会更持久，但仍然非常耗时且受到很大限制。

很明显，要使这种方法具有真正的价值，它需要一个合适的工具。

我开始与开发人员David Barker合作，我们一起构建为一个工作工具，我们希望尽快以Glean.ly 的名义公开发布它。

Glean.ly 原子研究库更新：

我很高兴地宣布，Glean.ly已经发布，你现在可以注册试用 30 天！

我已将“结论”一词更改为“建议”，因为我们发现这更平易近人且更准确。建议基于当前证据，并应在连接新数据时进行审查，而结论听起来非常具体和完善。

如果你喜欢不同的术语，无论是实验、事实、见解还是建议，都可以，因为这些本来就应该适用于你和你的组织。

               

原文：https://blog.prototypr.io/what-is-atomic-research-e5d9fbc1285c#e009

作者：Daniel Pidcock

译者：孙晨宇

审核：李泽慧、张聿彤

编辑：孙淑雅

本文翻译已获得作者的正式授权（授权截图如下） 

本篇文章来源于微信公众号: MicroUX