In the Summer we introduced you to the Eight Pillars of User Research. These eight pillars are the broad areas of User Research. Underneath these pillars sit groups of things that User Researchers or ‘people who do research’ (PWDR) are concerned with. Many of these things are challenges to operationalising research. By understanding these pillars, we can start to think about how to operationalise research in our organisations. We can start to think about where a Research Ops layer might come in.
Some of the things move upwards and become something we can label as ‘Research Operations’. This enables us to track these tasks and measure how long they take. By doing this we have the means to ask for more help. Perhaps these tasks are just shared across the team but it could also enable us to bring in a Research Ops specialist with a clear remit and skillset.
As we have been socialising this and the Research Ops Framework we’ve been hearing this a lot,
‘This is great but it’s a lot to think about all at once. Where do I start?’
If you’re at the start of your journey with Research Ops, having a map is great but you need to understand the route to take. Over the last few months we’ve been working on simplifying our model and providing a clear path to take.
If we dig into the pillars in a bit more detail, we can see that there are two groups within the eight.
The four pillars on the right are often where the pain is felt and can be the trigger for introducing Research Ops. This is often where you can have the most impact in the short term. But…
The four pillars on the left are where you need to start. These pillars are all about how the research gets done. By understanding the broader context of the Research organisation, you can really have an impact with Research Ops.
The pillars on the left are about how research happens and what supports it. The context and the capability. The pillars on the right are about how research can be systematised and scaled. The core of ops.
These things are in tension and you can’t really think about the things on the right, without considering the things on the left. Where do you start?
We’ve broken it down into four easy steps:
First we need to think about the pillars on the left here. By talking to people and asking some key questions we can start to get an understanding of how research happens. It’s obvious, but start with these:
- What are the challenges?
- What works well?
- What could be improved?
But then ask these to determine the environment in which research happens:
- Why does research happen?
- Who engages with research?
- What are the external and organisational constraints?
Then ask these to determine the scope and staffing levels for research
- How and when does research happen?
- What is the frequency?
- What methods are used?
- What is covered?
- Who is responsible for carrying out research?
- What are the team’s strengths and where are the gaps?
Next you need to figure out what you already have. Time to get your spreadsheet ready!
Once you start to look around you will find lots of templates and tools, consent forms and more knocking around.
You may discover lots of overlapping tools that could be rationalised or you may find only one or two logins for tools that many researchers are using.
You may also find lots of inconsistent consent forms and approaches to incentives. Defer judgement and note it all down in your spreadsheet.
Once you’ve done that, you can start to map out where the gaps are and what you need to fix. Prioritise what you want to work on first and then…
Just start. Target the low hanging fruit and then work your way up to the tougher problems.
A good starting point maybe sorting out your licenses for tools. The Research Ops community maintains an AirTable of User Research tools if you notice you have gaps. This is a work in progress, please always give credit to the “ResearchOps Community (https://researchops.github.io/www//) as its source.
A key challenge in many research teams is recruitment so another thing to start with is refining your recruitment processes.
A good research recruitment desk should provide both internal and external sources of participants, understand design and user research processes and needs, and handle the full sweep from sampling and screening, to scheduling and paying incentives, to closing the loop with respondents and participants.
This work by Ben Cubbon and Nic Price focused on the participant experience — another important Research Ops consideration.
Governance is important for Research Ops professionals to be able to provide researchers with an informed framework for conducting research that is safe, legal and very importantly, ethical. GDS have done a lot of work in this area as this post highlights.
“Too often, valuable insight and research is lost over time and the danger is that teams are destined to make the same costly mistakes over and again.”
David Mann, DXW Digital
In his post, David Mann talks about how important it is for organisations to retain existing knowledge and not repeat the same old studies. Microsoft have pioneered the Research Repository as a solution for this.
If you don’t have the scale or budget of Microsoft, the Research Ops community is doing some work on best practice in this area as part of our latest community project. As with all our projects, all our findings will be shared and open sourced online.
Research Ops is something that evolves over time. If you start with the things on the right, over time you will probably start to include more of the things on the left too. For example, a staff on-boarding programme, a Research methods playbook, a curated blog for sharing insights and so on.
Since last year, different teams have been sharing how their Research Ops practice has evolved over time.
Lucy Walsh from Spotify shared her journey from Participant Recruitment to Research Ops. She says:
It was through this exercise I’ve come to understand that the potential scope of Research Ops is vast, and therefore requires working closely with the team to understand their needs, and to develop and communicate a plan of attack that is both realistic to existing ops bandwidth, and flexible enough to evolve with the needs of an organization.
Aaron Fulmar wrote about a framework they used at Microsoft to enable the Research and Insights Team to keep an eye on the big picture whilst evolving their operations. The team tackled the most painful problems first before moving ‘upstream’.
We shifted more time and energy farther upstream, engaging in high-level conversations about topics like research curation and finance management…we are a community of specialists who elevate the research discipline by reducing the burdens on researchers — a mission we fulfil best when we engage with our partners at the highest levels of practice.
We’re looking for new contributors to share their stories on our Medium publication. We’d love to hear from companies and organisations who have been on a journey with Research Ops. What have you learned? What would you do differently? What can you share with the community? Let us know if you’d like to write for us in the comments, or tweet us @TeamReops on Twitter.