User research operations (ReOps) teams, which support user researchers / UX researchers to do their best work, are increasingly common. If you are considering setting one up, you probably want to learn from those who have trod the path before. I certainly did, when I established research operations at the Government Digital Service (GDS) in March-September 2022, joined in late July 2022 by the brilliant Uzma Razaq who runs it to this day. I learned a lot from Dr Salma Patel's blog about setting up research operations at NHS Test and Trace, Emma Boulton's work on pillars of user research, and resources from the global ResearchOps Community. This blog post summarises, in turn, my key lessons from what went well, and what did not, setting up research operations at GDS.
1. Benchmark your starting point
It’s important to know whether you’re making things better and be able to show this to others.
On day one of research operations at GDS, I asked its user researchers to complete a short benchmarking survey. Questions were derived from prior reflective work by the GDS user research community and should probably vary by organisation. I asked:
-
- To what extent did they agree that… (1-5 scale):
- They could straightforwardly recruit the necessary research participants.
- They could find and use prior user research conducted at GDS.
- GDS user research guidance and processes around consent and data protection were clear and appropriate.
- GDS user research guidance and processes were clear, findable and up-to-date.
- They had access to the right tools and templates to conduct their work.
- Any further comments on these five areas.
- What the greatest challenges were in conducting their role.
- What three words they would use to describe:
- the current state of research operations at GDS
- their ideal state of research operations at GDS.
- To what extent did they agree that… (1-5 scale):
Average scores from the rating questions and word clouds of the ‘three words’ responses powerfully communicated how researchers initially felt about research operations. I repeated the survey five months later, and could show all ratings improving, and the most common words shifting from “siloed” and “inconsistent” to “helpful” and “visible”.
If I had my time again, as well as measuring the sentiments of researchers I’d also try to benchmark the time and costs that research incurred.
2. Be user-centred
Research operations functions should be focused on the needs of their users (user researchers), while considering the needs of their organisation and constraints like regulatory compliance.
At GDS, the benchmarking survey gave an initial sense of problem areas. However, to get a richer understanding of how our user researchers operated and the pain points they encountered, I ran a workshop at a community event. In small groups, I had researchers map the stages in a typical research project, record the pain points they encounter in each, and then vote on those that have the greatest effect on their impact. I later sorted these issues into the eight pillars of user research, and affinity mapped them within these. Arranging these by number of votes gave me a prioritised list of problems and problem areas.
3. Be clear about what research operations does and does not do
Research operations is very broad, and there are many models of how it can operate. Researchers need clarity on what you’re there for, and what you’re not, so they know how to work with you and you can avoid spreading yourself too thin.
After the survey, workshop, and other engagement with user researchers at GDS, I worked with GDS’s lead user researchers to set out on one slide what our user research operations function was for. It described our initial purpose, central missions, and our first steps to achieving them. If I had requests that sat outside it, it allowed me to explain why I couldn’t currently support them, what I was prioritising instead, and why. That said, we were clear it would respond to the changing needs of our research community.
I presented this to all GDS user researchers when it was produced and sought feedback. I could have referred to it more frequently afterwards to maintain researchers’ understanding of our purpose.
4. Get some quick wins under your belt
Some areas of research operations, like knowledge management, are long games. To get buy-in from your researchers and other stakeholders, get some quick wins under your belt in the first few weeks.
At GDS this included sorting out permissions issues on research shared drives and collating details of all tooling in one place. In your organisation, it will likely be something different.
5. Don't go it alone
Research operations functions can only achieve so much by beavering away themselves. Ask for support from researchers, leads, and other relevant functions in your organisation such as data protection, and do what you can to help them help you.
For the initial few months, GDS’s ‘research operations team’ was just me, supporting 50-60 user researchers. Going it alone wasn’t an option. I worked with other parts of the organisation such as the highly supportive Privacy Office and Information Management teams. I organised community activities such as a (thrilling) ‘research data spring clean’ to get support in sorting out our shared drives. And for some research operations activities, especially those successfully being conducted by others already, I was explicit about only performing a coordination role.
Coordinating work being done by others, especially informally by user research communities, is hard. I had a go at implementing a “user research community contributions” model, with a big Trello board, activities linked to researchers’ performance objectives, and drop-ins with the ReOps team. It was overcomplicated and needed a bit of a rethink.
6. Be visible
Engaging with user researchers shouldn’t be done initially and never again. To build trust and be proactive rather than reactive, be as visible as you can.
At GDS this meant attending and running sessions in user research community workshops and show and tells, putting in intro chats with new joiners, attending meetings of each directorate’s user researchers, meeting fortnightly with our lead user researchers, and many a Slack message.
7. Be pragmatic
Research operations professionals tend to like order, processes, guidance, and documentation. We don’t want chaos and non-compliance. Equally, don’t go overboard. With the best will in the world, if your guidance for new starters is 80 pages long, it probably won’t be read, and it almost certainly won’t be well understood.
I tried to keep this in mind. When I revised our guidance on managing user research data, I resolved ambiguities raised by researchers while making it two-thirds the length, and it was well-used. But I also spent time re-working wiki pages that the analytics later showed nobody much visited, and which conversations suggested few knew existed.
8. Keep collaborating with and learning from others
There are so many brilliant research operations people out there. There are communities of them, such as the global ResearchOps Community, and that in UK central government (find them on UK Government Digital Slack). All those I’ve met to date are a supportive, helpful bunch.
The approach I took at GDS, and indeed the lessons in this post, draw heavily on the conversations I had with some of them. A huge thanks to those I spoke to at the Department for Education, Defra, HMRC, the Home Office and Hackney Council, among others.
So reach out, learn, and contribute. Maybe even write a blog post once you’re some ways in. Good luck!