Building and Scaling a Research Operations Practice
The InnoWell Research team was growing and moving fast to deliver multiple research projects with competing priorities. There was no one managing the operations of the 12 person research team. Researchers were spending significant time on operations activities rather than actual research with mounting 'research debt'. The Director of Research recognised that the team needed documentation, processes and tools to reduce inefficiencies and support the researchers in delivering and scaling the research's impact across the company. To support this function, I took on the role of UX Research Program Manager.
Team
2
I worked independently to design the research operations practice whilst checking in with and bouncing ideas off the Research Director. The team provided valuable feedback on all documentation and processes.
Being a 'team' of one, meant to deliver the various elements of research operations, I would need to:
-
establish where my work started, and it was critical to have clear guardrails of where it stopped.
-
cultivate the practice of self-service
Scope
The Re+Ops Community's Pillars of User Research served as a guide to assess the researchers' needs and the company's business needs.
To build the research operations practice, I started with creating a framework of what the research practice can and will accomplish. I initially focused on three areas based on the team's known organisational needs:
-
Guides and Templates - How to ensure researchers methods and deliverables meet the right standard.
-
Asset and Knowledge Management - How to: manage and store data; make research knowledge actionable, relevant and understandable; communicate research to create impact.
-
Internal Communication - How to communicate internally with peers and stakeholders what the research team is working on.
Approach
Designing a research operations practice is akin to service design; it requires a systems-based perspective, as everything is interconnected.
Design thinking was integral - the focus was on the user researchers first and foremost, seeking to understand their needs and develop effective solutions to meet those needs. A firm believer in the best work comes when bringing others into our process; communication and collaboration were vital. I continuously sought feedback to ensure that solutions would meet needs. Importantly, so the team could get value from the practice right from the start, delivery needed to be agile - incremental and iterative, focusing on the most pressing issues first.
Discover
To better understand what support the researchers needed, I had 1:1 meetings with the research group and the Product, Engineering and Lived Experience leads and reviewed all processes and documentation.
In the 1:1 meetings with the user researchers, I wanted to understand how each person fits within the team and get a sense of their research, understand their challenges and pain points and build a picture of connection points within the research team and other groups.
​
In the 1:1 meetings with the cross-function team leads (Product, Engineering and Lived Experience), I wanted to build a picture of connection points with the research team and understand what was and wasn't working well when collaborating and communicating with the research team. I also wanted to know where there were opportunities to improve coordination.
​
I reviewed all processes and documentation related to the three focus areas: Guides and Templates, Asset and Knowledge Management and Internal Communication. I aimed to understand how the team was currently operating, including:
-
research planning and execution
-
consistency and quality of research outputs
-
how research data and insights are captured, analysed, standardised, archived and shared
-
how the team communicates what they're working on and socialise their research findings
Organising all of the input
I used Trello to organise the issues that surfaced, which allowed me to track progress easily. I created a card for each issue I wanted to tackle and added it to the 'Backlog' list. Issues were structured as an actionable problem statement, focusing on the person, what they need and why to support solution generation later. I then sorted all of the cards by work area into one of three lists - 'Guides and Templates', 'Asset and Knowledge Management' or 'Internal Communication'. Any issues that fell under other work areas were labelled with the work area type and kept in the 'Backlog' for me to revisit when the work area became a priority.
Define
It was not possible to cover every single thing that needed to be addressed all at once. For that reason, I needed to figure out the most pressing issues for each area of work to bring value to the team right from the start.
I prioritised the backlog using the MoSCoW method. Considering the feedback from the Research Director, research team and cross-function team leads, each issue card was assigned a colour-coded label: 'must have'/red, 'should have'/orange, 'could have'/yellow and 'won't have time now'/blue. Over time as new issues surfaced, the issues were added to the backlog and prioritised.
Develop
I created processes and documentation to solve the most pressing issues.
I developed processes and documentation to help the researchers be more effective and improve how they do research.
Deliver
I aimed to get all processes and documents to the team as soon as possible, get feedback and improve rather than wait for a final version. Key initiatives included:
To build the research operations practice, I focused on delivering solutions that enabled the team to more easily serve themselves.
Research Playbook including methods, guides and templates
(Guides and Templates)
Researchers needed one go-to place of templates (anything they would otherwise copy from previous studies) and guidance on troubleshooting common problems to make it easier to get a new study off the ground. New team members needed a centralised place to access methods, practices, and templates to understand the context in which the team conducts research. Junior researchers needed a teaching tool to get clarity on research methods that they haven't yet been exposed to, so they can expand their skills. The whole team needed a baseline for the quality of their research activities and deliverables to consistently deliver high-quality research and deliverables.
Research Repository
(Asset and Knowledge Management)
Product, Engineering and Communications teams needed open access to user research insights to make better decisions. The research team needed one central, secure place to store research data that they could easily retrieve.
Automation of Study Status Updates
Using Google Sheet with macros, researchers only needed to update one sheet with study details, which triggered the update of a public sheet without participants' personal data. Teams could then access the public sheet for updates, as needed.
(Internal Communication)
Researchers wanted to reduce the time and effort spent on notifying multiple teams (with different levels of data permissions) of study changes (recruitment and participation). The Research Director and I wanted to view all studies' progress in real-time in one document, giving us access to the most up-to-date information and saving time by not checking in with each researcher. Program Management and Communications wanted access to real-time study data for government reporting and marketing purposes without waiting on a request to be actioned by Research. Product and Engineering wanted co-design workshop details as soon as they became available (the focus of workshops, address, etc.) to make staff plans to attend workshops.
Impact
The documentation and processes developed as part of the Researchers Playbook eliminated inefficiencies with research activities and ensured efficient, consistent, and high-quality research.
​
At the time, the research repository was only in development but showed promise to democratise research so that teams could make better decisions.
​
The automation of study status updates increased collaboration and communication within the research team and across cross-function groups while saving the researchers' time and increasing the company's productivity.
What I Learnt
The scope of Research Operations is extensive. It's vital to develop and communicate a plan of attack that is both realistic to the existing operations bandwidth and flexible enough to evolve with the company's needs.