Yes, you should embed UX researchers into your design teams. Here’s why…

Researchers. What are they? What do they do? How many sides do they have?

You’ve come to the right place to get some answers. As a UX researcher, I’m going to show you why you absolutely need a someone like me in your design team, and how to best work with me to help you reach your goals.

What, exactly, is a ‘researcher’?

In this case, I’m talking about a role that is variously termed UX (User Experience) Research, Product Research, or Design Research.

At Atlassian, we tend to call ourselves UX Researchers. We work with cross-functional product teams, but we can — and do — conduct research with strategy, data science, and marketing teams. Speaking from my own experience and those of other researcher-types I talk to, this is typically the case in other organisations.

Researchers help us understand…

• Our customers (the people who use our products and pay for them)
• Our users (people who use our products but don’t pay for them)
• The people who don’t use our products…yet

…as well as how we can improve those product experiences.

Put simply: we conduct research with our customers, users, and people who aren’t our customers (yet), to understand their behaviours, needs, and problems.

As a cross-functional team, the insights gained by research help us understand what to build and how to build it, so we’re not only building the right things, but building them right. Research also helps us prioritise what problems to solve and when we should solve them, and separate what’s an essential need from what’s an added bonus.

Now, let’s talk about why you should embed a researcher in your design team.

Service model vs embedded researchers

The Research & Service Experience team at Atlassian has moved from a ‘Research as a Service’ model to an embedded model. Let’s look at this Service model first.

‘Research as a Service’ model: in and out of the swimming pool

In a ‘Research as a Service’ model, researchers all sit together in a pool, of sorts, for a larger product space. They’re allocated to projects within product teams based on demand.

It kind of looks like this:

Never ask a researcher to draw things.

This model works well when there aren’t enough researchers to go around: researchers can be allocated to projects based on business priority and the relative ambiguity of the problem space to be explored. You might also see this referred to as a ‘centralized’ model.

However, Research as a Service has its drawbacks:

• Because the researcher is jumping between projects and products, they may not have enough product knowledge, or context on the problem space, to conduct research effectively and deliver actionable insights that the product team can use.
• Because the embedded designers and product managers typically know the product better than the researcher, the researcher often ends up coaching them on how to conduct research for their product.
• Coaching designers and product managers works well up to a point. Speaking from my experiences at past organisations, most product designers struggle to conduct enough research on top of their day job, as do product managers.
• Another issue that crops up is that the research that gets done tends to be the more tactical stuff (such as validating that a particular concept solves a problem) rather than the more strategic stuff (uncovering new problems, solutions or opportunities to), simply due to the time constraints (and sometimes skill level) of the design team.

The embedded model attempts to resolve some of these issues. (As you may have guessed, I’m a big fan of the embedded model!)

Embedded Researchers: towelling off, home & dry

Wait, what does embedded mean?

In the embedded model, researchers are allocated to a product or problem space, and are treated as members of the design team, much like a product designer would be.

As with product designers and product managers, embedded researchers also retain their ‘home’ for the discipline, which focuses on things like craft sharing and the overall strategy.

When embedded, our researchers are now completely out of the swimming pool — towelled off, home and dry with their individual product teams.

Because the researchers are now embedded, we’re teammates, not consultants. This addresses the issues we looked at earlier in the ‘Research as a Service’ model, and changes the expectation of how we work with design teams:

• Because we remain in the one domain, we can develop specific domain or product expertise, and build enough context on the problem space in order to conduct research that’s really actionable.
• We can proactively contribute to business decisions, and provide understanding of users’ needs, problems, and opportunities at the right time to better inform those decisions.
• We’re able to build strong, trusted, relationships with our cross-functional partners. We partner with designers & product manager to deliver more research, more effectively (more on this later).
• We can work closer with our cross-functional partners to embed research insights into the product strategy or roadmap — the research outcomes becoming better-integrated. By being in the product team, the researcher understands deeply what insights are relevant to the roadmap and what’s feasible for the team to implement now versus later. This means product teams can actually deliver on outcomes from research!
• There’s reduced friction for the cross functional product team to participate in research, because we’re right there with you — regular involvement in sessions means we’re all building a greater understanding of our users over time, and able to make better decisions that impact those users.
• Similarly, research becomes more valuable because everyone in the team has a say in its planning, who the participants will be, and what we want to learn from them. The ownership of the research is shared, so everyone feels the need to act upon it.
• We get more strategic and tactical research done, together! This means we build better products and roadmaps that aren’t just validating what we think will work, but really getting under the hood of everything that we could solve — and all the possible solutions.

Embedded researchers and design teams: how we win together

Now that we’ve looked at the difference between centralized and embedded researchers, it’s clear that having researchers embedded provides benefits to both the researcher and the design team.

So, how can we best work together?

Make decisions together

Think of your embedded researcher as another member of your decision-making cohort. For your embedded researcher to be most effective, they need to be at the table when it comes to prioritising research, actioning that research, and deciding on the best way forward based on research insights.

You might be thinking ‘when do I bring an embedded researcher into the conversation?’ The beauty of embedded research is that it’s no longer about ‘bringing them in’ — they’re already there! Ideally, they should be present in all the meetings or discussions a product designer is in.

Big shout out to my teammates who demonstrated this understanding by inviting me to their Slack triad channels, weekly triad meetings, and ideation sessions the week I started! Having your researchers contribute in these forums means we incorporate customer insights at every decision point. In addition, because I know what’s going on, any research I conduct will be better contextualised and actionable.

Collaboration & partnership

As an embedded researcher, my philosophy is that research is a team sport. Embedded researchers work closely with their design teams in order to:

• Shape our quarterly and yearly plans
• Add a layer of insight to progress reports
• Prioritise what research needs to happen (and when)
• Shape research questions and hypotheses
• Create research approaches that will answer those questions in a valid, time-efficient way
• Get you involved in any research conducted (e.g. note-taking, facilitating, synthesis)
• Embed those insights into our product strategy/roadmap to inform where we’re going
• Develop a shared understanding of the people whose problems we’re solving.

Better solutions, stronger products, and happier teams

As I mentioned earlier, having an embedded researcher in your design team means you’ll get more research done — together, we can tackle both the longer term strategic stuff to identify new opportunities, and the shorter term tactical stuff to identify ideal solutions.

If you don’t have an embedded researcher, you’re missing out on those longer-term opportunities and problems to solve. You run the risk of having too narrow a focus into your product and organisation rather than getting the full picture of ‘what’s out there’.

Not having an embedded researcher is a bit like trying to get somewhere without a map — you might have a vague idea of how to do it, and you might be right — but its better to be sure!

But who does what research?

In the embedded model, the researcher usually takes the lead on conducting all forms of research (exploratory, strategic or evaluative). Time constraints, however, often mean that product design, product management and product marketing can, and do, conduct more tactical or smaller pieces of research with the guidance of the embedded researcher.

NB: These aren’t hard and fast rules, but generally how I’ve seen this model play out in organisations at which I’ve previously worked.

Going back to the partnership theme from earlier, I’d expect my design team to be super-involved in any research I conduct, and I’d expect any designer or PM conducting research to involve me. That involvement might include a peer review of the approach, data collection mechanism (e.g. moderation guide, survey), note-taking, or synthesis.

Partnerships = more brains = better research

In summary…

• Embedded researchers don’t swoop in, do some research, and throw it back over the fence.
• We’re with you every step of the way along the product development cycle.
• We’re with you as decisions are made, ensuring the insights we collect together play a part in shaping those decisions.
• We’re partners. And it’s going to be beautiful.