How to Draw a Research Ops Owl: Part 1
A year and a half ago I joined my team as the first user researcher. There wasn’t a research operations framework or tools to support usability testing. So — I started to set up the research ops from scratch.
I mapped out workflows and personas, and analyzed the most suitable user research tools for different use cases. This led to a meeting with our Chief Design Officer to present my solution. After mobilizing 30+ teams from Palo Alto to Mumbai, I am now partnering with our Global Design Team to work towards a global rollout plan for research ops.
I’m lucky to have been mentored by some very smart people. I asked a lot of questions, I took a lot of notes, and I put them together here so that maybe it will help someone else.
This is how I drew the research ops owl.
Step 1. Draw two circles
Circle One: Refining the research plan
What are the pain points of the current research context? How widespread or far-reaching are these pain points? Who shares these challenges?
To answer these questions, I started by documenting my own context of work, mapping out my workflow for conducting usability tests and user interviews and noting the tools used at each step. I also wrote an epic and user stories to represent the key user needs of researchers.
I sent this deck to UX directors across the company, asking them to validate the research deliverables and share their experiences.
Then I conducted user interviews with as many roles as I could, in as many lines of business. From product owners to Chief Product Officers, designers to UX Directors, I asked colleagues to tell me about their experiences with integrating user insights into the product development cycle.
Here are some of the questions I asked:
- What is your development cadence — waterfall, agile, wave?
- What tools are you currently using to prototype designs? What do you like about these tools? What is frustrating about these tools?
- When you have a question about users, what resources do you use? What roles (which people) do you interact with to connect with users?
- Is your team in the same location, or do you have a distributed team?
- Is there a time when the developers and designers get together to look at wireframes or mockups together? How often do you do this?
- Can you tell me about a time when you had a user/usability question, and you were successful in getting an answer ? What about that process worked well for you?
- Can you tell me about a time when you had a user/usability question, and you were unsuccessful in getting an answer? What about that process was frustrating for you?
Circle Two: Defining the Outcome
Heeding my colleague Rana Chakrabarti’s excellent advice on scaling design thinking in enterprise, I framed research ops as a systems problem. I defined the outcome as targeting tools and frameworks that could be optimized.
The goal is not merely ‘more user research’, since this goal isolates research and does not take into consideration how the insights are consumed by other roles.
We want to work towards increasing research consumption throughout the entire design and development process.
UX roles can gather user insights by leveraging research tools and methods in a time-frame that suits their work context in order to make the right thing.
Non-UX roles can draw from fundamental UX research methods to validate user requirements in order to make the thing right.
Metrics should be specific to each team. Some examples include:
- Cost — reducing time to recruit and schedule participants
- Engagement — increasing the volume of research requests
🔑 Engagement is one of the metrics I’ve found effective. I like the gov.uk’s knowledge kanban board template to track and manage user research requests.
Just do it.
Getting started can be scary and overwhelming. I knew I needed to connect with other UX roles in order to get going. But SAP has 90,000 employees in offices in 130 countries. I barely knew anyone, I didn’t have access to internal distribution lists, and I didn’t know any other user researchers.
So I started with what I did know — our corporate portal includes a comprehensive employee directory. I searched for the term ‘UX’ and emailed every single person with that term anywhere in their profile. Yes, this took forever. Yes, I had to copy and paste the email copy countless times. But I got over a hundred replies, and was able to get things started quickly.
Don’t let your imposter syndrome hold you back. You got this! You are a professional problem solver, and all problems can — and should — be broken down into bite-size chunks. That’s why you start by drawing the owl’s outline.
Ask lots of questions.
Do your research. Create a framework for analysis. Analyze what you’ve found out. Then find people who are smart and experienced and ask them your questions. Refine your framework, updated with this new information, then ask more questions. Rinse, repeat.
Give people scones.
You can leverage the power of reciprocity with whatever you’ve got, but honestly scones are a truly versatile baked good. They pair nicely with coffee, tea, or even a beer (preferably a stout or cream ale), you can eat them as a meal or as a snack, they can be sweet or savory, you can make dozens at once, and they are easy to pack up and take to the office.
So, when you need a favor — for example, you want all products in an LoB hosted on a particular server in order to conduct usability testing — come armed with scones.
The next steps are solution scoping, solution scaling, and getting stakeholder buy-in. You can check out how I did it in Part 2!
PS. Here are some Medium posts that I found helpful, written by designers wiser and more experienced than I. Give them a read, and if they help you, give them a 👏 (or hold that button down and give them 50 👏, you do you.)
Who bridges the gap between the design systems and the engineering team? I call these enablers: “Design Systems Ops”medium.com