This is about how my team formed our research ops strategy, but it starts with a retro. In February 2018, I was a UX researcher at Zaplabs on a product team that loved to do frequent retrospectives. After one such retro, my fellow researcher Sanjana and I found ourselves taking on the nebulous task of “improving UXR project management”. To be honest: I wasn’t actually sure what that meant. 

I fell back on my natural instincts and proposed starting by talking to each member of the research team about their project management process and pain points. Typical researcher move. 

That’s how we got started with Researching Researchers: A Meta Research project. Sanjana and I made a list of questions to ask all the other members of the research team and our leadership.

Here are the questions we asked them:

• How do you currently organize & plan your research projects?

  • In planning, what’s the first step? Do you always follow the same processes?

• How do you determine your timeline for working on projects?

  • Are there obstacles you face around this?

• What tools do you use?

  • To manage your time?

  • To schedule?

  • For logistics?

• Do you have any bottlenecks or disruptions in your workflow?

• What are the things you dislike most about running research projects?

• Are there any workflows or tools that you think have improved your productivity or project management?

We started scheduling time with each member of our team and had some great conversations. They quickly went beyond what’s normally thought of as project management. 

Examples of some things that came up were:

• We had so many small, tactical research projects eating up our time that we couldn’t focus on the projects that we thought really mattered. It was also forcing us to context switch a lot and made it difficult for researchers to focus.

• Our recruiting and scheduling process was frustrating and a time burden. The process was entirely manual and up to each researcher to figure out for each study on their own.

• We had inflexible documentation practices and difficulty accessing previous research

• Meetings and regularly occurring events were a major disruptor in researcher’s workflow

I put all of this into a nice little Airtable base that helped us see issues across multiple researchers. 

Our Findings

So, we’d done our research and gotten a lot of qualitative data. The next thing was to analyze it. We used Airtable to tag and categorize specific ideas we’d heard from our team into several themes and came out with 5 main findings, each with several sub-points, all tied to the original direct evidence. 

Here is the list of the problems we were facing and how we viewed the different aspects of them:

1. Lots of researcher time is spent on logistical tasks (recruiting, scheduling, transcription) and supporting designers with usability tests.

   1. Recruiting

   2. Scheduling

   3. Transcription

   4. Supporting usability testing

2. Documenting is a pain point for researchers because our current process is both inflexible and time-consuming.

   1. Often insights are not best consumed in report structure

   2. Current report template not flexible for devices/different kinds of research

   3. Redundancy/overlap of different types of documentation

   4. No solution for documenting “nuggets” that are potentially insightful but aren’t essential to a particular study

3. Being on too many pods/projects is having a negative impact on researcher time management.

   1. Lack of focus

   2. Context switching

   3. Difficult to predict timeline on individual study or task

   4. Ongoing design research needs without infrastructure to support

   5. Requests to pull prior research for pod topics, takes time to find and distill

4. The wiki is not meeting our needs as a research repository.

   1. Researchers need to look at past research for two reasons:

      1. To inform background of research they’re going to do

      2. Someone has asked for research we have on something

   2. Confluence wiki not working well for disseminating or accessing research

      1. Not easily searchable, no standard naming convention

      2. Pod based research is siloed

   3. We have no solution for documenting research at a level more granular than reports.

      1. As we scale, need a way to document research nuggets and make them searchable and accessible for people to look through.

5. Meetings and recurring events are a major disruptor in research workflow.

   1. Amount of time spent in meetings

   2. Distribution of meetings across free time

   3. Recurring events (like our monthly report) disrupted workflow too.

Tying it into Research Ops

For context, this all happened around the same time as the wonderful ResearchOps community started growing. So while we were summarizing all the different problems our fellow researchers were having with “project management”, I was also on the new ReOps slack community reading about how research teams all over the world were facing and approaching the same problems, which collectively had a name: research operations. 

What is research ops?

This couldn’t have been better timing. The emergence of ReOps gave me a lens through which to process and understand the problems we had. For example, our difficulty accessing previous research wasn’t just because of outdated reports, but a symptom of the need for a cohesive system for organizing and maintaining research insights over time. It also helped us frame our proposed solutions as part of a larger research operations strategy, which gave it more legitimacy for buy-in with leadership. 

So, what happened next? 

We did end up getting traction with leadership to start working on a few of our most pressing needs according to our meta-research: 1) a toolkit for designers and PMs to do tactical research, and 2) a research repository. The details of those initiatives are too long to share in this post, but looking back on it later, I’m happy to count them as some early ResearchOps successes. 

I think our success in this process is due in large part to the meta-research Sanjana and I conducted at the beginning. Grounding our initial research ops work in the actual needs of our team makes sense —as UX folk, that’s what we’d do when building a product or service for our users—  but it wasn’t obvious to us at the beginning how useful it would be to conduct UX research with our team. I’d highly encourage anyone dipping their toes into ReOps to do the same: research your team. 

Thanks to the lovely people on the Zaplabs UX Research team who were willing to share your processes and frustrations with your work, and especially to Sanjana Surkund for helping me conduct the meta-research project. Also, we’re very much indebted to the researchops leadership team and the many wonderful people in the community. 

Are you dealing with similar issues? I’d love to hear about it!