This is a topic I’ve written on multiple times, both in my first explorations into building a research repository or thoughts around democratising research.

I’m also not the first or last to write about any of these topics (links can be found at the end), but it’s a topic that still seems to create challenges for folks, especially with AI becoming such an integral part of research.

Before we get started, there is one point I want to make that has been key to how I look at research in general and has been a baseline principle for all research teams I have worked with: “The purpose of research is to provide a service to product teams, which is about providing them the tools to make better, more informed decisions.”

Many research teams and researchers I’ve worked with over the years seem to focus so much on the craft, that they forget that without providing the service, they are not serving their purpose. Which in turn, makes the case for a dedicated research team harder to make, usually resulting in reduction of size or complete extinction.

It’s funny that I have to repeat this so many times, but research is not easy. 

These are some of the myths I’ve read/heard (and in some cases, used them myself):

The reality is a whole other ball game. 

Over a decade ago, I started digging into research practices and methodologies, with particular focus on UX. I started reading books and started applying a lot of what I learnt.

Through trial and error, I got better and better until the point where I was reasonably good enough to get by and even teach other designers how to conduct research. And yet, I can admit that working with an experienced researcher who has built their expertise around the craft is on a whole other level and always amazing to see.

Getting research right is genuinely complex, especially because of the constant balancing act of having empathy for the user, while maintaining objectivity to not project our own bias to both how we interact with them and the insights we extract.

But there are a few key points that help me keep that objectivity that I’ve learnt from other experts and some of my own experiences:

At the end of the day, proper research is a complex animal and I always recommend really working to build the craft or have experts to help you out.

I also tell people they’ll be terrible at research for the first few attempts, that’s how it works. After enough repetition, you can get to a place where you aren’t doing more harm than good.

But make no mistake, that unless conducting research is your full focus and you really build up your craft around the topic, you will never be as good as a well trained researcher.

In the list of reading suggestions, I call out Jake Burghart’s “Stop Wasting Research” and it’s an essential read around the topic, but I wanted to share my general point of view and how it came about.

Since I first started understanding the world of UX, I realised the importance and value of doing proper research.

When I moved to an agency/consultancy as a UX designer, I quickly realised that we were conducting research for each customer project, but we weren’t leveraging it across customers or surfacing patterns that spanned them.

We were wasting the incredible research we were doing and so I started looking early at ways we could stop wasting it. 

Around 2018 I joined a small startup, where I was allowed to constantly talk to customers and conduct experiments. In fact, it’s where I was able to take my interviewing expertise to a whole new level.

This coincided with the birth of the Research Ops community, and I remember that one of the first conversations that came up was around research repositories. You can read the full story in my Building a Research Repo When you don’t know how article.

Long story short, I just created a research repository. It wasn’t glorious or at the level that I’ve seen others approach the topic, but it was functional, useful and really solved quite a few issues for us.

It also helped me start my path into understanding how to better synthesise and structure research outputs. The seed of an idea I would build on later.

Over the next few years, I didn’t have a direct influence on research practices and operations, but I always took the opportunity to nudge folks with the experience I’d picked up over the years.

I still kept seeing the pattern of wasted research, but I also started seeing another familiar pattern in larger product organisations. Product teams were having difficulty finding what they needed when exploring research that was already conducted.

Between a research repo, reports, presentations, documentation and analytics, the teams were wasting so much time looking for the information, trying to decipher what it was telling them and then being able to decide what to do next. 

In fact, in most cases, it was so complex and time consuming that I noticed one of two outcomes:

Either case meant that researchers would need to spend time on work that has already been completed, keeping them from the new or strategic work they needed to do.

For the teams, it meant extra time and effort that could have been avoided.

In my head, the simple answer was building a better research repo, but what I didn’t realise was that in many cases, the research teams seemed to be building the research repositories for the researchers and less for consumption by the product teams. This seemed very confusing to me, because I was seeing researchers complain that they didn’t have time to do the research they needed to do because they were “curating” research already conducted.

The solution was simple enough (please read with a sarcastic tone). We needed to build an insights system that is useful and functional for the product teams to consume.

I go into much more detail on the full system in my Democratising Research article, because it was about making sure we were connecting all aspects of research to one another rather than distributed systems, making sure they were synthesised in an objective way across all research teams and that the end result was a curated system that could help product teams and remove the blockage of being overly dependent on the research teams for insights.

It seemed to me that research teams had developed a certain wariness. As if their value were tied to the repository itself, rather than to the quality of insights they could surface. And this results in research teams constantly battling to justify their value and why they should exist.

But for me an important aspect to keep in mind was that researchers bring an added value on top of what product teams can do. If they are no longer bringing that value and are just doing small, tactical research at a granular level, it becomes harder to justify having specialised folks to do that. Stakeholders will accept lower-quality research if the teams can handle it themselves. I know it’s a challenge, but it’s the truth of what I’ve seen.

This thinking helped me shape how I look at the whole insights space, but it was only the beginning.

I know barely anyone is talking about this and much less in the research field (yes, that’s sarcasm), but I wanted to share how I’ve thought about it.

I first started playing around with the idea of AI to help with research back in 2017 and I remember the first reactions I got about how that went against everything the design fields stands for and how we could never replace the human touch.

My plan at the time was never to remove the human touch, but more about leveraging AI to empower designers and researchers. Especially when it comes to big sets of data or seeing patterns that humans might miss. As a strong companion.

An example I use often is if we need to analyse the movements of people in a train station. As a human, we can see small behaviours and interactions that can give us some interesting insights, but if we’re talking about a major train station where thousands of people pass through everyday, a single day would be an overload of information. With the help of AI, we could potentially spot bigger patterns and connect them to events. What does that actually mean? That’s where the human in the loop comes in.

Fast forward to today and I’m seeing non-research folks playing with the idea of synthetic users and AI-assisted research as an option. Potentially having AI handle the whole process and removing that work from the humans.

I’m always reminded of the number of times that I’ve designed something with confidence, put it in front of a user and they use it in ways I had never imagined. Or the number of times I explain something to an AI model and it seems very intelligent, but doesn’t seem to understand the crux of what I mean.

Removing the human isn’t the right option either. 

I was managing a team of researchers, when the AI topic started gaining traction and I love how we as a group approached the challenge and it’s become my go-to story and approach.

It was clear that the team loved conducting qualitative research and then presenting amazing new insights to the product teams they were working with. Less exciting was the organising of the research and then the synthesis. 

With that in mind and a new AI model to play with, provided company wide, we sat down to figure out how to best leverage it.

Nothing to do with AI, but the Research Ops Manager helped build out a somewhat automated recruitment process, that would give teams direct access to our users, recruit them, schedule/manage sessions and manage rewards.

Then, with AI, the researchers tested out the following aspects systematically in this order:

The results were varied, but worthwhile exploring:

Overall, the saving of time was over 50% (in some cases more), increasing the quality of the research and giving the researchers breathing room.

But we didn’t stop there. We knew that this was a limited spectrum of what was possible and we then set out to connect the AI model to our research repo.

Connected to what I mentioned above, we realised that the best way to serve the product teams was to create a solution that would give them quick access to the insights and research so that in a matter of minutes they could understand what existed, what might be missing and define whether further research was needed or whether they could make a decision based on what existed.

Many tools are now trying to provide that feature, but at the time, we needed a solution quickly, to bring real value and while there was interest from stakeholders.

We first cleaned up the research repository, organising the governance model, the flows and practices around the repository.

Then, together with the data science team owning the AI model, we connected the two and started BETA tests with product teams. The advantage now was that they could talk directly to qualitative data.

I left the project at this stage, but some of the aspects we wanted to explore next was opening up to the wider audience. Enriching it all by connecting quantitative and qualitative data for a more complete picture… there’s no limit to what we could explore.

Throughout it all, we always had one mantra in mind: We need humans double-checking what is being created and every solution has to be extensively analysed to make sure it isn’t hallucinating or mixing up concepts.

Notice how I didn’t mention the reduction of teams? That’s because when researchers are able to really do what they should be doing, the value is clear and compound. Most research teams are penalised for work that they were never really given space to do well.

With AI, we were able to enhance value and impact, delivering more, but with the exact same team. We could justify every hour and spend on each researcher. 

There are also some points around effective planning and prioritisation, and that’s just as important, but not a subject for this article.

The general concept across everything I’ve described is simpler than it might seem. Research exists to serve decisions, not to serve researchers.

Every system, every tool, every AI integration I’ve described only matters if it makes it easier for a product team to figure out what they know, what they don’t and what they need to find out. If it doesn’t do that, because the system is built around how researchers think rather than how product teams need to consume it, it will fail, regardless of how sophisticated the tooling is.

AI hasn’t changed this. It’s just made the gap between doing it well and doing it poorly more visible and harder to excuse.

The teams I’ve seen get this right didn’t start with a tool. They started with a question: Who is this for and what do they actually need it to do?

That’s still the right question to start with.