Interview: ResearchOps with Amir Ansari

The field of user research has changed dramatically in recent years. In many organizations across the globe, research has grown from the remit of a lone, under-resourced designer or product manager to a fully-fledged practice with multiple researchers sitting in different teams and with radically different targets. Of course, this isn’t true of every organization, but more people are starting to understand the value of research, especially the competitive advantage that it can deliver.

Enter ResearchOps. Like its cousin DesignOps, this new practice has grown out of a need to operationalize and socialize the user research. It’s certainly the right time. With research growing, industry-wide processes, templates and best-practices can ensure that organizations are running research operations correctly. If you haven’t already, we recommend you read our ResearchOps 101 guide here.

To get some more perspective on this new initiative, we reached out to longtime Optimal Workshop collaborator Amir Ansari. For the initiated, Amir is the Director of UX at a digital consultancy called Transpire in Melbourne, Australia. No two days are the same for Amir — his work typically requires him to work across operations, sales and delivery. He could be supporting his design team in the morning, helping to bring in work for Transpire over lunch and then working with the leadership team in the afternoon to develop Transpire’s business strategy and growth plans.

For these reasons, he’s really one of the best people to talk to about ResearchOps. Let’s get started.

Can you give us an overview of what ResearchOps is?

Amir: It’s about streamlining processes, skills, artifacts, templates, people and capability. My hypothesis is that ResearchOps has come about because researchers are under a lot of pressure to manage all aspects of the research process, usually within very short time frames. This is especially true when we talk about the digital space and methodologies like AGILE and SCRUM — basically when things need to be done in a lean fashion. So, my impression is that the research community and research practitioners are under a lot of pressure to deliver a lot of processes — recruitment, documentation, consent forms etc. — quickly. And for this reason, researchers are having to find ways to streamline and do things faster.

I think ResearchOps is a natural evolution of anything we can do to help improve the way we do things, both in terms of speed and efficiency without sacrificing quality. That’s important.

“The research community and research practitioners are under a lot of pressure to deliver quickly.”

So what’s your relationship to ResearchOps?

Transpire is a consultancy, a vendor and a service provider, and we conduct research for our clients all the time. We have our research toolkit (hosted on our wiki), and in our wiki we’ve got all our templates on how to recruit, how to incentivize, how to get people to provide informed consent and so on. We have templates on our discussion guides. We have templates on our final deliverables. We have a methodology we use to speed up our synthesis and analysis. All of these documented resources can be used whenever we onboard a new user experience practitioner. But I never thought of going, “Well you know what? A lof of that content could be classified as being part of ResearchOps” when in effect it is. Probably the difference is, at a larger enterprise organization they’ve got a dedicated research function. They’ve probably gone, “Right. Let’s give it a title. Let’s give it a name and let’s have a practitioner or someone or a team own that space while everybody goes and conducts the research.”

We never thought of calling it anything, as we’ve never formalised it. I can’t afford to dedicate one of our designers to be full time on it. But every time we find a new way of doing things or we need to update a template, whoever is between gigs or is on the bench gets asked: “Can you go and update that consent form?” or “Can you go and update the way we do our recruitment because we’ve just found a new recruitment providers.”

Is ResearchOps understood at Transpire? What about the companies you work with?

It’s fairly well understood here. But in terms of our clients, not so much. The most knowledgeable group are banks. They’ve got dedicated research teams, dedicated user experience strategists and dedicated UI designers. It’s definitely the large organizations that are more mature. Once you start getting to the smaller enterprise organizations, or ones that are not digitally mature or don’t have bigger research teams, often it’s less known or formalised. I doubt that they would be looking to have a ResearchOps function.

“ I’m only going to assume as more communities get built up, potentially this notion or a concept will get to a point where maybe there’ll be some standards or guidelines that everybody can follow. “

I’m only hypothesizing but I feel government agencies and academia may have an appreciation of ResearchOps, partly due to the fact that they have to follow processes and document everything.

In general, I haven’t seen a ResearchOps function within our clients but some of them are starting to talk about it. And I’m only going to assume as more communities get built up, potentially this notion or a concept will get to a point where maybe there’ll be some standards or guidelines that everybody can follow.

How do you see ResearchOps evolving in the coming years?

I think the evolution of ResearchOps is probably something that will grow to the point that you go, “This is the best way to recruit. This is the best way to synthesize and analyze. This is the best way to have artifacts across certain things”. Some really strong guidelines will come about, especially around ethical research practices and rights of research participants.

Similar to DesignOps, as you start to put operational processes in place, you’re removing certain things that a designer has to do. Will that allow them to then spend time being more creative, or is it going to get to the point that the designers go, “Well, 90 percent of what I used to do has become automated or operationalized within an Ops function, so what is there left for me to do?”.

Who do you think is responsible for driving ResearchOps adoption in organizations?

I’m all about democratizing processes as much as possible so everyone can lend a helping hand, especially for smaller teams (like mine). It also ensures the responsibility doesn’t fall on a single person or a small team to ensure processes are documented and followed, while the rest of the team members say “I’ll continue to do it one way until someone tells me I need to change my process.”

People may just get lazy and become less accountable. Having said that, when you’ve got a large organization with a research team of 30 or more, getting all of them to have a ResearchOps role simply won’t work. So it all comes down to the size of the team.

How does that work at Transpire?

As mentioned earlier, I have a reasonably small team. Everybody has some visibility of all the projects we work on. Obviously I have the most visibility and where possible do ensure cross collaboration and pollination across projects. For example, I often say “Hey Designer X, Designer Y on project Z is trialling a new [insert process here], you should go and have a chat with them”. And when someone starts at Transpire, one of my seniors or I will take them through our toolkit as part of their induction. But do I own it? No, I help facilitate the process. But every one of my practitioners is accountable.

If they find something new or trial a new process, the onus is on them to let the entire team know. That’s where our weekly team huddle comes into play.

People like to talk about the components of ResearchOps — can you speak to these at all?

Yeah, I think the best way to explain these components is if I break down what we do when we’re conducting research at Transpire.

To start off, we work with our client to unpack the goals for the research project — what are we trying to find out? What hypotheses are we trying to validate or disprove? That then gets documented in what we call a reverse brief or a research brief. That’s one component. Then we put a recruitment brief together. We ask who are the users or the customers that we want to speak with? Cohort, customer profile, segmentation, and so forth. That’s a recruitment brief — another component.

Typically we’ll then work with our market research recruitment partners and give them the recruitment brief. This is where the idea of the participant screener comes into play. So, what’s a screener? A screener ensures that when we are going out to find these participants, we’re finding the right people. You can argue that’s another component.

Then we need to put together what we call a discussion guide. What are the questions that we’re going to ask? In what order are we going to ask them? Are there open ended questions? Are there closed questions? And what’s the purpose of that question? So, that’s the discussion guide. That’s four components.

“ You can argue that the transcription of those [research] interviews is another component.”

Next, we come to the research. What does that involve? That involves getting the participant to come to our offices or go to their place of work or environment — if it’s a contextual inquiry. To follow good research practices, we need to make sure that they are aware of their rights, role and responsibility, as well as our role and responsibility. We call this a plain language statement, which we give participants beforehand. That’s the fifth component. Then there’s a consent form that we get them to sign on the day, agreeing to what we will capture and record, and that they can stop at any time if they are uncomfortable. That’s another one — six.

You can argue that the transcription of those interviews is another component. So, that’s seven. Then there’s a synthesis and analysis that happens either offline, physically through UX’s favorite tool which is sticky notes, or via a tool like Trello. You start to unpack themes and categories for insights. You can argue the way you manage those themes and categories is a component in the research space. At the end, we finally bring it all together in some form of report either based on a research canvas that has a hypothesis, research approach and outcomes, or is just a findings and recommendations report. That’s a component.

Then there’s the finer details of research. For example, when putting together a survey, all the generic standard questions (for example, age, household income etc.), could be seen as components that get reused every time a researcher wants to conduct a survey.

So you could get quite granular.

There are a couple of challenges however, Firstly, time! The more processes and components are created, the more time it takes to document them but also to keep them up to date. Secondly, if everything is documented, there’s a risk that researchers may stop exploring new ways of doing things, and simply continue to rely on their ResearchOps practice to notify them of new techniques, updated components and processes.

What would your advice be for those researchers without any sort of ‘Ops’ function?

I would always recommend that as a practitioner, as a researcher, or even as a designer, you should be helping to drive the craft forward regardless of what your title is or what your role is. As a researcher, it’s your duty that if you come across a new way of doing things or; a new way of running a piece of research, you communicate that back to whoever would benefit from it. I don’t think people need to necessarily go, “Hey, I want to own the title of ResearchOps”. I don’t think the title is lucrative enough yet, unless someone is very analytical. It’s all process driven, not about actually conducting the research.

My recommendation is to always look for ways to improve, through efficiency, quality and consistency, and document any chance you get. Oh, and always communicate and share it so that then there’s visibility from other practices, other areas of the organization.

Because that’s the other risk. If people are working in their own little silos or bubbles, and they’ve managed to solve a particular problem, they’re not really helping their team and their fellow colleagues to do things more effectively. So, my advice would be to constantly read and learn, see how someone’s doing things, see how they’re doing it differently. Capture it, document it, and pass it forward.

Again, across Australia and New Zealand there are huge variations in terms of the digital maturity of organizations. There are banks with 70 designers and startups with no designers where the CEO is acting as a designer. There’s a huge opportunity for the community to learn from each other.

“There are huge variations in terms of the digital maturity of organizations. “

Another benefit of formalizing ResearchOps could be that it helps drive a community, and with it conversations across organisations and practitioners. We can all help pass it forward!

Any closing remarks?

I’m keeping an eye on this space. I would love to see new ways to help improve conducting research. At Transpire we’ve been at the forefront of how we’ve been using Trello. We’re not a reseller of Trello by any shape or form, but we’ve been using Trello to streamline how we transcribe and capture research and interviews, how we synthesize and analyze and look for themes and patterns. We have literally saved 50 percent of that time doing those three things, which means that we can spend more time doing the actual deeper analysis and reporting. And I’ve presented talks and demonstrated this at clients as well as conferences to help others gain the benefits we’ve been seeing. Read our last interview with Amir on the future of the UX industry here. He’s also a coach, mentor and speaker. You can connect with him on LinkedIn.

Originally published at https://blog.optimalworkshop.com on June 29, 2020.