We had a chance to sit down with Hana Nagel, Lead UX Researcher at SAP, to discuss her views on user experience and how she sees the discipline evolving in the future. Hana is one of the thought leaders at the forefront of Research Operations, a new discipline aimed at operationalizing research within an organization. We asked Hana how ResearchOps can help User Experience teams work more efficiently, among other topics. Let’s dive in:
Sofia: In a recent blog post that you wrote, you mention wanting to work towards increasing research consumption throughout the entire design and development process. What do you think is stopping that consumption today?
Hana: I think one of the biggest challenges around that is having the main consumers of research understand that research does not need to slow down or impede their work. Some folks will push back because they think that research slows down the process. Other folks will push back because they simply don't see the value of research as opposed to their own knowledge of the consumer.
A starting point in increasing overall consumption is to empathize with your colleagues’ end goal. So, if you're thinking of your peers as your end users and empathizing with them, what are their main work concerns? Is it saving time in terms of development time, saving development cost, delivering the product on time, etc., and then aligning that with how your research will help them to complete the task. You're not just doing research to check a box - you're doing research because it will save time on development, because they won't have to redo a feature when they find out it's not delivering the value that they needed.
Increasing consumption of research is simply a matter of engagement. How many times do people even ask you for research? Not where you inserted yourself into the process, but rather having people come to you to say, "I'm working on this thing and I want the confidence that I'm making the right decision."
Sofia: How do you begin to course correct and get people excited about and engaged with research?
Hana: As with most good UX questions, the answer is it depends. I think there's a couple points to consider. One, I think, is the complexity of the end product being delivered. When you have something that's more straightforward, maybe it's a B2C product that has one or two user stories - when you're that close to the consumer, I think it can be easier for other colleagues to understand the value of research because the flow is not complex. If you're working on an ecommerce website, then we'll know that one of your main goals is to sell the thing. And it's easy to understand.
When you're working on something that's more complex, with multiple touchpoints and stakeholders, then it starts to be a little bit more convoluted in terms of surfacing who the users are and what they're trying to accomplish and what their journey is through the product. So, it's no longer testing check-out button A versus check-out button B. It's thinking about their work environment, how many other colleagues your end users work with, what other systems they are using. When it's more complex like that, I think it's harder for people to see the value in research, which sounds counterintuitive, but people like to feel confident in their own work, so when they're faced with something that they might not understand, it's a natural human response to resist. On one hand, you have a little bit of soft education. It's kind of like marketing where you're trying to surface who the users are and why it helps your own work to engage with them, and encouraging this open attitude so that people won't be threatened by what they don't know. That, I think, is a really base step if you were a researcher at a medium size company.
Let's say there are 500 people at your company and you're the only researcher. I think the first round of activities, the first hurdle that you really wanna get past, is simply awareness raising. Very basic, “What is UX”. What kinds of steps do we take to find out more about our users? What kind of deliverables do you make with those insights? And then how do you use those insights at different points in product development?
And then I think the next step is building engagement metrics. In the education phase, you're doing lunch talks, you're having people do small workshops with you to learn more about different research methods. And then the next step is the engagement or exposure — having people participate in usability sessions with you, pulling in people from different teams to watch user research presentations. And in those two steps, you're able to identify the people who are going to become advocates for the value of user research for you.
At the same time, you're trying to show the value to the executives, because you want to influence change from both bottom-up and top-down. Finding out what the organizational goals are is another way to increase engagement - maybe there's a sales metric they're trying to hit, maybe there's a new consumer base that they're trying to market to; showing how your research plan is going to get the C-level executives to where they need to go is key.
At the end of the day, we all care the most about our own thing. We talk a lot about empathy in UX, but I think we don't talk enough about what you do with that empathy. So, if you're going to operationalize empathy, it means that you are learning insights about whoever your users are internally or externally. And then you're taking some sort of action on that insight. So, empathy for C level means that you understand the task that they have to deliver on and then you help them get there. And you do the same for your end users externally. I think a lot of it is understanding what people need and then positioning yourself as the one who can play a role in helping them to get there.
Sofia: Let’s say you’re not in an official ResearchOps role, but just another UX team member. How can you take on this challenge to optimize the overall process, and at the same time do the research itself?
Hana: The scariest thing is always taking that first step and just starting anywhere you can. I think there are always organizational roadblocks - do you want to do something, but there's no money? Do you want to do something, but need someone's approval to do it? Figure out what resources you can finagle. If you can't get $2,000 for a license for usability testing software, can you get $20 for Starbucks gift cards? If you can't call end users directly, can you make a database of your own employees and find people who match certain profiles? How close can you get to the thing you're trying to do? Even if it's not that close, if you can show the value of doing a step that's kind of parallel or similar to the end goal, then you start having these use cases to be like, "Remember when I did this thing that was small and cheap and it was effective? Imagine if we did it 500 times bigger and better and faster, how much more impactful it will be.”
I think the other thing that can hold people back is simply being shy. You know, it's hard to talk to people that you don't know. I think a lot of this requires you just going into new spaces and being like, "Hello. I'm trying to do this thing. How can we do it?" And I think there's no cure for that part of it. You just have to jump in there.
The good news is that people are very willing to help, I find, even if they don't know you, even if they outrank you on the org chart. If you succinctly explain to them what you're trying to do, I find that people almost always reply and help me. Demonstrate that you have an agenda, clearly communicate the outcome that you want, and you'll start to build trust. I think a lot of this is simply about building trusting relationships both externally and internally.
Sofia: We mentioned the blog post you wrote earlier in the interview. How have things changed since you wrote that blog post?
Hana: At the time I wrote the blog post, I was working with some colleagues to bring in four new research tools. And in an enterprise setting, that’s really complicated. There's a lot of paperwork and it's really complex to manage because you have to figure out things like how to set up internal orders and work with different teams’ budgets. There were sometimes when I didn't know if we were going to be able to do it, you know? It seems so easy initially. Like, oh, just get a license. It was taking so long, there was a lot of paperwork involved with onboarding new vendors, having their respective legal teams review the documentation, trying to figure out how it would be rolled out, who gets the first license, how training works. We brought in three of those tools. One is currently in the process of being onboarded, and we started the Slack community for people to talk to each other, of course. And now colleagues are bringing in new tools of their own volition. That was really encouraging to see. People kept telling me, just be patient. And once it happened, people would be like, "Oh, it's been like this all along?" I had to be really strategic and really stick to it. But now that it's really starting to come together and there's already solid success stories in place, people are able to go forward on their own.
I think that is really encouraging for other people who might be trying to do something similar, who might feel like in the beginning, they’re doing it all alone. But the more that you're able to create those user research advocates and focus on building that one success story that you can grow, once you get past that hurdle, then it really is something that becomes a self-sustaining model where other people take up the torch and keep growing it.
Sofia: If you were going to start a new job in a business that is completely lacking ResearchOps, how would you go about it?
Hana: I think it goes back to the impact of research. Find out what needs to be delivered on or what people care about internally. Do they struggle with projects being completed on time or being completed on budget? Are they struggling with some sort of voice of the customer program or NPS survey? Is that something that's challenging for them?
One of the reasons that DevOps has become so prominent is because we invest quite a bit in software engineers and we need to maximize those resources. We need to maximize that budget. We invest less in our designers and our researchers, but in the flow of things, design feeds into development. So, if you don't invest in design, if you don't invest in research, that ends up wasting the budget you've given to developers.
We want to make things well, but we also want to manage our overall costs. And that's something that's easy to align on. If you have a researcher that is doing everything manually, she has no way to manage insights, has no way to schedule participants, that can result in a 400% increase in time. You're wasting tens of thousands of dollars, which in turn slows down and impacts the end product that you're delivering.
Start talking to people, talking to product owners, and ask them what their experience has been like, how often they have to rework something. Put those anonymized insights together and bring that to the higher ups to say, "Here's some feedback internally that's impacting the way our whole organization is operating." You're making it not about you - you're making it about other people and your coalition. And then bring it together to say, "There's a better way to do this. We can do this faster, more streamlined, at actually less cost if you invest in ResearchOps."