At Qualdesk, we’ve been grappling with the question “what is an insight?” for some time.
Through our own user research, we’ve seen a wide variety of definitions and approaches, from minimalist to maximalist, and from rigid to flexible.
Why does this matter to us? We want to make sure that we can build products that are as useful and relevant as possible for our users. If we build products that don’t allow our users to work with their own insight model, there’s a high probability that they won’t use them.
Where we’ve ended up is a position that we believe:
We call this approach molecular insights.
In the physical world, a molecule is made up of two or more atoms. A water molecule contains two hydrogen atoms and one oxygen atom. A carbon dioxide molecule contains one carbon atom and two oxygen atoms.
Both of these types of molecules, water and carbon dioxide, can coexist reasonably happily in the same space – such as a bottle of sparkling water. But each molecule is separate. Under a microscope you’d be able to see each molecule as a discrete unit.
We feel that this analogy works well in the field of user research.
Insight ‘molecules’ consist of two or more ‘atoms’ of different types. These might include:
The atoms are joined together to make an insight molecule. For those of you who are familiar with the concept of research ‘nuggets’ – hold tight for now.
In our previous post about insight repositories we talked about the fact that a repository would need to store all of these things together in order to be successful. But it shouldn’t make all of these things mandatory for every single insight.
Just like there are different types of physical molecule, there can be different types of insight molecule. Two examples:
In the this example, imagine we’re in a discovery project – trying to understand needs and emotions of our users at a broad level, and trying to identify unmet needs or explore some new product or feature opportunities.
To make sure we capture what we learn in a consistent format, we’ve defined a ‘discovery insight’ molecule to consist of:
1 × Definition atom 1 × Description atom 6 × Evidence atom 1 × Tags atom
This reflects the fact that during a discovery project, we’re focused on:
and that we’re less focused on:
In this example, imagine we’re assessing a specific feature or journey from a usability perspective.
Again, to make sure we capture our outputs in a consistent format, we've defined a ‘usability insight’ molecule to consist of:
1 × Definition atom 2 × Evidence atom 1 × Recommendation atom 1 × Tags atom
Here, we’re in a very different situation to that in the previous example. Speed is of the essence, and so we’re more focused on:
and we’re less focused on:
From these examples, you can see that it’s possible to define different molecules for different purposes. And, of course, these definitions might vary from organisation to organisation.
Even with these definitions in place, you might want to allow for some additional flexibility – perhaps by making certain atoms optional. You might want to store an insight without recommendations, for example, because you haven’t developed any recommendations yet. You might want to store one insight with a long description, and one with no description at all.
Whatever you use as your insight repository, it needs to be able to handle all of these scenarios.
Is a single quote from a research session an insight? No. What about two quotes and a photo? No. A definition atom without any evidence? Not an insight either. In our view, the answer is no.
It’s worth noting that we don’t believe that the molecular insights approach is original – it draws on a lot of the work done by Tomer Sharon in his time at WeWork, especially in defining research ‘atoms’.
The nuggets approach suggests a similar hierarchy between nuggets and insights to the hierarchy that molecular insights defines between atoms and insights. However, this has been misinterpreted in places, and the concept of an atom (or ‘nugget’ as Sharon describes them) is often blurred with that of an insight itself – something we don’t think is helpful.
The value in this approach is that it forces us to consider both:
It prevents us from:
When we’re thinking about how to design and build our own products at Qualdesk, we try to keep all of this in mind. Not every insight is the same shape or size, and they come in different types. We’ll dive into that challenge from a product perspective in more detail in a future blog post.
Two areas where the analogy breaks down slightly – but hopefully not to the detriment of its usefulness in the user research world: