Published on <a href="https://blog.prototypr.io/what-is-atomic-research-e5d9fbc1285c?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Daniel Pidcock <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GZQF0O23VSJpYftwye2ozg.jpeg">Super artistic photo of my laptop screen showing Atomic Research cards in the Glean.ly tool
<blockquote>You may have heard of <a href="http://bradfrost.com/blog/post/atomic-web-design/">Atomic Design</a> — Now comes Atomic Research, a new way to organise UX knowledge in an infinitely powerful manner.</blockquote>
In short Atomic Research is the concept of breaking UX knowledge down into its constituent parts:
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NmUe3pXGyh7iDwFOjHwr5A.png">The Atomic Research model — a funnel from data to conclusions, then around again
<ul>
<li>Experiments “We did this…”</li>
<li>Facts “…and we found out this…”</li>
<li>Insights “…which makes us think this…”</li>
<li>Conclusions “…so we’ll do that.”</li>
</ul>
By breaking knowledge down like this allows for some extraordinary possibilities.
<a href="https://blog.prototypr.io/#e009">Click here to skip to how this works in practice &gt;&gt;</a>
<h3>How it started</h3>
Last year I was working for a FTSE 100 tech company. The issue we were trying to solve was how to store and distribute the UX learnings in a way that everyone in the business could use and benefit from them.
As it stood, the UX team, BAs and PMs would run experiments, write up what they learned and how they used that knowledge. These were normally produced as PDFs, Google Docs or Slide-decks and then were filed away in Google Drive.
That’s all fine until someone else came to work on a feature and needed to find out what we already knew, and it was hard to use those findings for another project.
Sound familiar?
<blockquote>We asked: “What if, instead of documents gathering dust in files and folders, our UX knowledge was in a searchable and shareable format?”</blockquote>
I was talking to <a href="https://www.linkedin.com/in/uxuiuk/">David Yates</a> about this problem and — as UX designers are wont to do — we started talking about breaking what research is into simple bits. David (one of the of the most insightful and knowledgeable folks I’ve had the opportunity to work with, also a lovely bloke) should take a great deal of credit, as I think it was he who started talking about how you could separate data from the insights. He referred to Maslow’s Hierarchy of Needs. This idea of ‘lots of small signals leading to larger discoveries’ made me think of Atomic Design, where user interfaces are built up from the smallest UI elements.
If you are thinking ‘this sounds like the DIKW hierarchy (data, information, knowledge, and wisdom) — you are spot on. We’d accidentally invented an existing and well respected scientific data model that is at least 60 years old.
Still, that just confirmed to me that this was a good way to look at UX research — I feel that going around saying ‘DIKW’ (which most people pronounce ‘dickwee’) isn’t brilliant, also our model was slightly different, so believe Atomic Research is a better term. When I use the comparison to Atomic Design people au fait with the method tend to get it.
I’ve been using the Atomic Research principle for nearly a year now and find it an incredibly useful way to think about product knowledge.
<h3>Atomic research in practice</h3>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3EWKo_agft5HPvTlfpvWHA.png">Atomic research in practice — how it looks with real knowledge.
Experiments — “We did this…” The experiments from which we have sourced our facts.
Facts — “…and we found out this…” From experiments we can glean facts. Facts make no assumptions, they should never reflect your opinion only what was discovered or the sentiment of the users.
For example: 3 in 5 users didn’t understand the button label.
Insights — ”…which makes us think this…” This is where you can interpret the facts you have discovered. One or more fact can connect to create an insight. Even if they come from other experiments. Some facts might disprove an insight.
For example: The language used on the buttons isn’t clear.
Conclusions — “…so we’ll do that.” Conclusions are your recommendations for how to use the valuable insights you have gleaned from the facts. The more insights connecting to the conclusions, the more evidence you have to it’s value. This helps when prioritising work.
For example: Let’s add icons to the buttons.
<h3>Multiple sources mean better decisions</h3>
One of the first benefits I noticed from this method is how more than one fact can support an insight and more than one insight can support a conclusion.
The more facts that ultimately lead to a conclusion the more you can be confident about that route forward.
Even across multiple experiments! Perhaps a colleague has some experiment results that also support the conclusions I’m forming.
Of course there is no reason that those sources couldn’t disprove my conclusions. Perhaps another colleague has run an experiment that goes some way to question my insights. This can be linked up and give us a more thorough picture
The results are no longer held in this little bubble of my specific bit of research and I can give as much evidence as possible to make major decisions.
<h3>Research is no longer linear</h3>
Once we have come to a conclusion, that needs to be tested too. If we continue the example of adding icons to buttons, perhaps I want to run a split test to see if it works? The data comes in and shows that this didn’t increase comprehension.
Damn!
But the good news is I can use that data to disprove my conclusion, while leaving the insights that led to that conclusion intact. In fact the failed tests data might weaken some insights but actually strengthen others.
It certainly helps us get a clearer picture of how to improve our products moving forwards.
Traditional reporting methods are stuck in a moment of time — “Our research tells us this…” — by holding insights as separate and independent of their sources means they can be constantly re-tested and allowed to live and die by the evidence.
This leads to what I think is the most important benefit:
<h3>Atomic research forces evidence based thinking</h3>
I can’t create a conclusion if I don’t have insights that support it. I can’t create insights without facts. The more sources I have for each one, the more confident we can be about my conclusions.
Of course I can cheat and say that a fact supports my insight (or just be misguided), but it will be obvious to anyone looking that it doesn’t.
Atomic Research gives provenance to my assertions.
<h3>Tools to practice Atomic Research</h3>
I’ve been using Atomic Research in my own work for nearly a year now.
For most of this time I’ve been doing this manually. Literally sticky notes on white boards with hand drawn lines. This is useful for playing with findings in a small way, but is temporary and not very shareable.
A next step up is to use mind mapping tools such as <a href="https://www.draw.io/">draw.io</a> — This is longer lasting but still very time consuming and massively limited.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CqW4OJI3EoKU7mHx8a0Yig.png">A screenshot of the upcoming Glean.ly beta Atomic Research tool.
It was obvious that for this method to have real value it needs a proper tool. I started working with developer <a href="https://www.linkedin.com/in/dawbarker/">David Barker</a>, to help me build this out as a working tool and we’re hoping to release it publicly soon under the name <a href="http://Glean.ly">Glean.ly</a>.
In the meantime we’ve recruited some private beta testers to see how it works for large internal teams. I need to give a shout out to <a href="https://monzo.com">Monzo</a>, <a href="http://Moo.com">Moo.com</a> and <a href="https://turo.com/">Turo</a> for helping us. I am overjoyed that such big names and well respected UX teams see the benefit in what we are doing.
Find our more at <a href="http://Glean.ly">Glean.ly</a>
<blockquote>If you think your team would benefit from being part of the <a href="http://glean.ly">Glean.ly</a> private beta or would like to be alerted when the official release is ready you can <a href="http://glean.ly">apply on our website &gt;&gt;</a></blockquote>
Also — as a small team, we are looking for investment and partnerships or just helpful feedback. So please drop me a <a href="mailto:daniel.pidcock@glean.ly">message</a>. I’d love to hear what you think.
<h3>Further reading:</h3>
<a href="https://medium.com/@danielpidcock/the-difference-between-atomic-research-and-atomic-research-22d2cb0227a8">We compare our concept of Atomic Research with the Polaris version &gt;&gt;</a>
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2Ff51076%3Fas_embed%3Dtrue&amp;dntp=1&amp;url=https%3A%2F%2Fupscri.be%2Ff51076%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252Ff51076%252F%253Fenpose&amp;key=d04bfffea46d4aeda930ec88cc64b87c&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a></iframe><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=e5d9fbc1285c" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/what-is-atomic-research-e5d9fbc1285c">What is Atomic UX Research?</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Atomic UX Research?

Top Stories