Kicking off Research Ops in large organisations
So, kicking off Research Operations when no such thing exists within your (large) company — 500+ employees. Good question. I was in the same position a year ago and this is what I did to try and get it started. Spoiler alert, it worked! We managed to get exec buy-in to build out Research Ops including a Data Insights team — a total win: Frankly I didn’t expect it - so this sharing session is mainly practical points around setting up some research guidelines and best practices for all teams. It is not about powerpointing to execs for resources.
Let’s get started.
Phase 1: Process
There are two sides to design: Building the right thing and building it right.
And, for me, “Research Operations” aligns nicely: “Research” is about building the right thing; “Operations” is about doing it right - the process of setting up good guidelines and documentation so that (research) is a standard quality process, and easily assimilated and socialised.
How does research fit into the whole design thinking and delivery process? I like the Design Council’s Double Diamond approach:
And this is the model I used for the guidelines. Now, how to get these into practice? Well, we were using the standard enterprise-ware dynamic duo of Jira + Confluence so I set about replicating this model, with details, in both places — linked and aligned:
- A Research Epic with subtasks
- Confluence pages for detail
Phase 2: Documentation
I broked the first diamond down into more detailed research practices gleaned from around interwebs into Confluence sections. Best process, practices & templates: here the Confluence structure:
And, here is a nifty diagram if the same provided by my colleague who was even more of a documentation nut that I am:
Now, to facilitate the Epic task (see what I did there) of stepping through this process, I replicated it in Jira as a template that people could duplicate:
With these tasks:
Alright! 4 steps that correspond to the first diamond. A process is born. Detailed guidelines behind each of these steps are in the confluence docs linked to Jira: eg. Setting Goals: Goal templates and best practices.
Phase 3: Tooling
Page one of research is the results together into one place: the Research Repo. After considering Confluence I began searching for a better tool which could serve research needs more closely, and - longer story short -found Dovetail. There are others. Dovetail was relatively new, but it looked perfect for our needs and the UX was good. Yes, I make purchase choices based on UX. I made the pitch for it, and we eventually bought our licenses. Then eventually expanded from the design team to the product org.
Before socialising to Design or Product, however, we needed some guidelines and guardrails here also to ensure everyone is on some kind of track from day one:
a) Research Templates aligned with the Confluence documentation to get “Researchers” up and running quickly.
b) A data taxonomy: Dovetail works by “tagging” interesting snippets from User Interviews (more on this later), which can then be sorted and filtered. Here is an example of some tagging
If many people are tagging texts without some coordination the tags will soon spiral out of control with duplication, and also result in too fine a semantic granularity: we need a standard set, to be able to sort and filter our research coherently. Hence a data taxonomy draft and proposal was made and “finalised”.
We have meta-level taxonomy, and interview-level taxonomy in groups. They are available as a global set of tags for all users:
I’m not going to go into the details of how Dovetail works here, but basically the goal is to store and tag all interview material so that we can pick through it and pull out the insights: three features of Dovetail here are particular useful and the main reason why Confluence wasn’t an alternative:
(1) Charting: the ability to visualise tags in many ways. This is as useful as your tagging taxonomy is intelligent.
(2) Search, Sort and Filter research across the board: (all projects, everywhere)
(3) Pulling out Insights: Dovetail facilitates the work of tagging interviews, grouping by theme and pulling out Insight groups, which can then be presented easily.
One of the most beautiful things about Dovetail and kin is that for each tagged highlight we can drill-down back into the interview itself and pull out the user’s direct quote in context, with video and transcription (a lifesaver).
This tool covers the final 2 steps of the process: Organise & Analyse, and Present Findings — and these correspond to the second half of the first diamond.
Phase 4: Socialisation
Phase 4 of this rollout consisted of sharing this tool and these guidelines, first within my Product team, then within our Design group, then out to Product. I can tell you from experience that showing this Tagging and Insights process to Product is an instant sell. They were on-board from day one and loving it.
Phase 5: Systematic Action
Well this is where I drop off because by this time we had enough executive buy -in from our actions that we hired our first researcher, imported our Data Insights team into the Design group and merged them together. Now we are on the way to hiring our second researcher.
And here I say goodbye. I’m a little sad to see my baby grow up and leave home *sniff*, but at the same time so proud.
Hope this was helpful. This was my experience of getting researched kicked off in a large organisation. Of course, company culture was also very receptive to this idea for which I am grateful: I’d like to thank my manager Amber Rucker, and the Design & Exec Org of CloudBees for the support, and Sam Radjkumar the research director from my previous “large company”, Oracle, for the inspiration.
Feel free to comment if you have questions, insights.
