Emma is a design and user research consultant who will be speaking at the upcoming UXinsight conference in Utrecht, The Netherlands. She was kind enough to chat with us about her past experience working on user experience projects, her learnings about operationalizing research, and advice for researchers seeking better internal engagement and collaboration. Let's dive in:
Sofia: Can you tell us a bit about yourself and your background?
Emma: I have been working in research, both market and user, for close to 20 years now. I have spent two-thirds of my time working in-house. I didn’t think about ResearchOps until last year, when Kate started the Slack community. It was just something I did – it was part of my role as a researcher. Talking with people when I first joined the community made me realize the importance of naming the hidden work that goes on.
At the moment, I'm a freelancer/consultant, working with different clients, mostly as a lead researcher doing discovery research. I’m also doing coaching and training with people who haven't got research capability in-house and who need to do research either internally or for their own clients but can't take on a full-time researcher. So I act as a mentor for those people, helping them with the craft of research. I've been quite involved in the ResearchOps community since it started and I'm part of the centralized board.
I left Monotype last year, but for four years I was their research director. I was the first user researcher or market researcher that the company took on. What I ended up doing there was to establish the research conversation in the organization. At the time, they did research in a more academic way. There were some white papers, with MIT, on font legibility by the font designers. But there wasn't an established customer feedback loop at all. There were informal pockets of work going on with designers doing user research, product managers talking to customers, sales teams talking to customers, but there wasn't a joined-up approach.
So what I did there was to establish this conversation, and create more of a culture of research working alongside other people. I was probably doing ops-y things without really knowing it was called ops, because it wasn't a thing then. But that's how I've always approached research, having done it for about 19 years now, having done it in all its various forms. At Monotype, instead of doing all the research, I empowered other people to do research: I set up systems for people to help with research, best practices, and a blog.
So I did lots of different things; I wasn’t just one person doing research. In general, I tried to think in a more systemized way so that if and when they scaled, the foundational work had been done.
Sofia: What do you advise to teams that say they cannot systemize or operationalize research because they just don't have the time?
Emma: I think the biggest challenge is that you can take the time to set up a system, but you still need a gatekeeper, or a gardener. You need someone who's tending that garden, who's responsible even if they’re not a full-time researcher. You need someone who's responsible for that pipeline, because it's really like a content architecture job particularly with the insight repository.
You have to make sure that when things come in, they go in the right places but also the insights are surfaced properly. It’s about telling people that those insights are there, surfacing content and telling research stories, so it involves thinking about it in an editorial way. People don't seem to think about it in that way. I think content strategists and content people and people with that editorial mindset really get that research repository and research library side of things.
It really is a library, so you need to think carefully about knowledge management. Any company could do that, if they've got someone who thinks in that way, and it could be even a small part of their role. It doesn't have to be a ResearchOps person or a researcher doing it. It could be a content strategist, an editor or someone else who would take it on as part of their role. You just need to think about the skills and who's the best match.
Within a product team, for example, you may have a product marketing person or just a general marketing person, or your content people: they're the people that could fulfill this role, rather than thinking it has to be a researcher all the time. I think marketing people are often closest to the customer and often they’re very close to the product as well. They often think very similarly to user researchers. They're just applying what they're thinking in a different way.
Sofia: When it comes to building the foundations of your ResearchOps, do you think about it from the perspective of using the team you already have and finding ways to share the work so it is more collaborative?
Emma: Exactly. When I was at Monotype, we were really working together very closely. We had a product marketing person, the product manager, a designer, and an analytics person. Dev was slightly separate, but they worked very closely with them still, and then me. What I did was facilitate conversations around customer feedback and research. I just got people talking about what we were trying to understand. Things like, what problems are we trying to understand this month? I did a regular meeting around that. We had a Trello board, and we would all get together and get everything out on our backlog and prioritize the most important problems we needed to figure out. We didn't have a huge budget, and there weren't many of us. We were all quite senior – we didn't have many people – so we just figured it out as best we could between us. Who's going to tackle that problem? Who's going to work on that one? It was my job to facilitate that conversation, but I didn't do all that work.
My colleague who led analytics would say, "I'll spin up a quick experiment. And we'll do some A/B testing on that thing. And I'll work with the product manager directly on that.”
Some of the problems that emerge come out of the division between the UX team over here, the product team over there, particularly in more traditional companies where there's been that traditional division. I don’t see startups having this issue. I've been talking a lot to research leaders recently, people in huge startups, and it sounds like they've set it up for success from the beginning. Their structure has allowed them to just naturally include this in there.
People like Spotify, people like Airbnb – some of those people are part of our ResearchOps community as well, and they've got it sorted. They're built for success in the first place. I see more of a struggle in companies that have an older and longer legacy, and have perhaps grown organically. Maybe they've been more in physical products and now they're doing software, like financial services. In those types of companies where they're very long-standing companies, I think the transformation is most painful for people. It’s on a completely different scale.
Sofia: What are the small things that product teams can do to start building that foundation?
Emma: I think templates are an obvious place to start...that's what I did. I gathered templates for discussion guides, for example, screeners, recruitment, even copy, things like standardizing how you talk to people in your emails. Have that all somewhere so it can be reused. When I'm organizing research projects and I'm emailing, say, 30 people, I'll have it saved somewhere on a clipboard and then copy and paste to speed things up. It's about reusing that content and thinking, can I use that same content next time?
A small thing like that may sound obvious, but you don't always need to start from zero when you're doing a research project. And then make sure that you're talking to the other product manager, who may be doing the same thing. Have a regular forum where you talk about research as a group of product managers or marketing people, because even if it isn't one person's job to organize that, there is still going to be one person who's more inclined towards being the leader for research, say, or insight. Get some agreement around who that person is, so that you're not arguing. Taking the lead is great, but that person also needs the buy-in of their colleagues that they’re going to take this on actually as a small part of their role. It might also be an objective set by that person’s boss so that everyone knows it’s their role. Maybe someone else takes control of another aspect of it, say analytics. So carving up the researcher's job, and having a bit of it done by each person on the team may help everyone think about research in a more joined-up way rather than it being just on one person's shoulders – that can make things really, really tough.
Particularly if it isn't your area of specialization, you need forums where you can say, "You know, I'm really struggling with XYZ” or “I'm thinking about a diary study." A product manager may not have time for a diary study, but they’re probably open to helping if you say "Has anyone done this? Let's figure it out together." As someone who's worked both in a research team with lots of researchers and research teams of one, I’ve always built on the power of the whole team. You can get so much more done when you come together.
Just thinking about your information architecture is a huge thing you can do to build your research foundation. And thinking about not just shoving things into a system and hoping that something good will come out of it. By taking some time to understand who the key personas are and then perhaps storing your insights by persona or by segment or whatever it is that works for your company is important. Taking the time to do that foundational work as a group and then agree on a way forward will go a long way to making the system more efficient and smooth.
I created the research funnel to try to understand where I could add value and where people should be doing their own research. It was primarily about thinking from an operational standpoint and then through tactical, up to strategic, and then all the way up to exploratory research. It was helpful to have that conversation with teams across the business so that they would know when to ask me or my colleague on the research team, or when to talk to the director of analytics, when to talk to the researchers that came on board. The research funnel helped us define who should do what.
Another approach a company can take is to think of research or insight as a continual thing. You may have come across Teresa Torres’s work. I love how she talks about continuous discovery. I think this is where I was coming from when I came up with the funnel. It's thinking about where best in the process to fit pulling insights. It’s thinking about how the different types of activities are just getting you closer to the truth or closer to the solution rather than this very process-driven approach where you have to spend a week doing this and then you have to spend another week doing that. It's almost a guerrilla way to do it.
So, for instance, in those meetings that I talked about, we’d be saying, What are the things we're trying to understand this month? What are our 90-day goals for the product? OK, we need to keep that momentum going. But what can we do to help refine it, maybe with some operational data gathering from the analytics team? OK, what are the small things we can do so that we're not impacting on that speed and that cadence? What other tactical things can we do, maybe some quick user research on something that's almost ready to go? Dev have done some work on it, but it needs refining. What are some quick usability things we could do there? I'm thinking at the funnel now.
Then, thinking in a more strategic way, What are we looking ahead to for six months and what are we not sure we know to then be able to design those experiences? OK, let's do some slightly more strategic work (which is the stuff that takes the time and exploratory). Are there any fundamental things we don't know about our target customers? Do we need to maybe include some of those blue sky things in our strategic piece of work? That was really how we used to think about it. I used to actually note the level from the funnel in that Trello board.
If the issue was more strategic, I would take that on. I’d work in the background managing that work alongside the more tactical and operational research that we would keep trickling into the project. Product managers were always speaking to customers anyway, and so we would always try and drip-feed in any insights from that. But we tried to position that work as separate because, of course, it's more related to functional requirements and relationship management, than proper research. But we tried to cover the whole range of things that we were doing, and we found it to be quite effective, actually.
Sofia: Can you give us a sneak peek at what you will be talking about at the UXinsight conference in April?
Emma: I'm going to talk through the work that the ResearchOps community has done and other things that the ResearchOps community are working on now. At the moment there's a skills framework group who are doing some really great work and there will probably be some other things by April, as well.
I'll be highlighting some of the great work going on across the community, maybe bringing in a bit of my own experience. It will be quite a different talk for me because it will be really acting as a mouthpiece for the community rather than talking directly about ops, because I don't have all the experience yet. I'll be shining a light on some of that great work going on across different organizations.