Building a Research Repo when you don’t know how

Research as part of the process, has finally started growing in popularity in recent years and we begin to see more teams with people dedicated specifically to research. With more people contributing to research, there is more research to sift through and synthesise. Research Repos/Libraries have an important part to play in taking control of that research and getting the most out of it.

In this article, I will share what I went through recently in trying to build a Research Repo, in the hopes that it will help those looking to do the same.

Introduction

In my previous work in UX, I used to work with clients on various different projects, so research was handled on a project by project basis. That meant I never felt any need to organise research beyond the basics (File system and some reports).

In 2018, I joined a small startup that was a product and I was heading up research efforts and some of the issues that continuously popped up were:

• Haven’t we spoken to this client before?
• We did some research on something like this a few months back, but where is it?
• The person who did the research left the building, how do we know where it is?
• We’ve done the research, but how do we make the most of it?
• How do we know if the research is still valid?
• Etc.

This coincided with me discovering and joining the ReOps community, where I was reminded about the interesting concept of Research Repos. Something I had heard about disparately, but never gave much importance.

Research

I started doing research into tools, methodologies to try and understand both how we would store the data as well as the best process to break it down, analyse it and then extract insights from all the data.

I also needed to present the idea to internal stakeholders and be able to justify the logic of taking all the time needed to tackle something of this depth. After some back and forth, I managed to convince stakeholders that it was something we desperately needed. Actually not that hard, because luckily everyone clearly identified with a lot of the issues we were facing in terms of research.

Deciding on a solution

I researched and tested as many of the tools related to Repos or Research management that I could find, and in some occasions went through product demos.

During this time, I discovered Tomer Sharon’s Polaris approach to research repos. I’ll admit that it seemed interesting, but I was having difficulty grasping the actual working concept.

I started building something more concrete in Notion and Dovetail as a test, but wasn’t convinced, then once again Polaris came into my radar. I also found out that Tomer had build a functionable database on Airtable.

So I took a leap and decided that we were going to use Airtable, with the Polaris Framework. It was also great because we had various departments (Sales, Customer Success etc.) receiving input from users and the concept that Tomer presented of democratising research was a great fit for us.

Building the repo

Although the original example database built by Tomer was great, I felt that it didn’t fit exactly into our reality, especially considering that we needed a clearer picture of who we had spoken to and when.

So I built a database from the ground up, based on Tomer’s database. This way I would understand the workings of every single inch of his database and adapt my database whenever it made sense.

It took me a while, but after a few weeks, I was happy with the results. Some of the main changes I made:

• Instead of provocations, which didn’t seem clear enough for most, I changed it to Hypothesis, forcing us to think about how we might test our assumptions.
• I added a customer section where I could easily have information about the customer, their location, company and position (Also made it easier to associate personas to those users)
• I also added a vector for emotions, as I felt that would be important in synthesis

New challenges

I was really happy with initial results and the synthesis of the data was much more concise and objective, but I started to run into some issues that would hinder the scalability of the solution implemented:

Takes too long — As I started using the solution on a day to day basis, I found that although having all the data together was great, I was taking way too long to introduce it, as Airtable is a pretty manual solution. Great for a few entries, but a real headache when you want all your observations and inputs recorded.

Building insights — What wasn’t clear to me at the time was how does a nugget, move to an insight and then to a provocation. I created a small formula in-house, where if we had 3 or more nuggets with the same tag, then we create an insight from that. Insights would also be tagged and depending on their recurring tags, we would create Hypothesis from those, but once again, only if the insight had a strong impact on the user’s experience or the business strategy.

No integrations to our existing tools — Probably the biggest issue I ran into (after a few months of introducing all our research into Airtable) was that when I wanted to get input from the other departments coming into Airtable, I didn’t have a way of making it viable for them. The thing was that they were already using Productboard, which meant that moving them over to Airtable would disrupt a habit that had already taken work to get implemented.

I searched for integrations that would bring content from Productboard to Airtable, but the integration is horrible and doesn’t bring anything of value. I was really disappointed in myself that I hadn’t remembered this point earlier in the process of looking for a solution.

Back to the drawing board

Not one to give up, and knowing the value the research repo would bring, I tested out and analysed the full extent of Productboard.

With a few tweaks and adapting the logic of Polaris to the options available in Productboard, I was able to structure things so that all inputs and research conducted, would go into Productboard:

1. The inbox became the nuggets section
2. Nuggets were analysed by only one department (to keep consistency) and insights created from that.
3. Themes from those insights were our provocations/hypothesis

Some of the main advantages of moving to Productboard:

1. Most customer info didn’t need to be introduced, because it was coming in from Intercom.
2. We could introduce write-ups or full conversations into the product and then select and tag the nuggets by themes, which made things easier.

It wasn’t the best tool for the job, but it was a start and solved the problem while still democratising the input of research.

Main learnings for me personally:

A few of the key learnings I took away from the experience, that I’ve suggested a few times to others who are starting this journey:

1. Establish your approach/framework well, so that indifferent of the tool, the logic is well thought out and you know how you plan on synthesising the data. Once I had gotten to grips with Polaris and had adapted it to our needs, the core concepts could easily work in almost any solution because the basis was solid.
2. Be sure you know how other departments are or will contribute. If you can get them contributing without changing their habits, much better. Better to figure this out earlier than later. Learn from my mistake.
3. Build a repo that can adapt, because you’re learning new things everyday. Sometimes you discover you need a new vector in your analysis.
4. Be sure to have a framework and formula that helps you be objective when you need. It’s hard to admit, but even qualitative data based on varying emotions and interactions can be handled objectively. We can easily get lost in the “what ifs…”, so being able to get quickly past the smaller issues easily and freeing up more time for the more complex problems, is incredibly satisfying.
5. Make sure that you can easily search, filter or synthesise the data. (Single entry nuggets at a time killed me in terms of motivation.) There are a few tools out there doing this well, and being able to highlight, tag and categorise data, when done well, can be very helpful and efficient.
6. Try and implement a research repo as soon as possible. Every single project or team I work with now has to hear me discuss how important it is to plan a way of taking care of research in the early stages, when it’s still easy to change directions a few times and test various approaches. But the value is incredible.
7. Everyone can contribute and feel like they have an impact on the strategy. With everyone contributing in some way, you don’t have to bother clients as often and if something you thought was solved, still keeps coming up, it’s easier to identify the problem areas. It also helps newcomers in understanding why certain things evolved in a certain way and what future development should focus on.

References

• Democratising User Research by Tomer Sharon
• Polaris template on Airtable
• Comprehensive list of research tools compiled by the ReOps community

Special Thanks:

• Brigette Metzler for being a mentor during my learning process
• Tomer Sharon for always being available to answer my questions and doubts