How Atlassian are meeting the increased demand for user research

What is triggering the growth in the demand for user research?

I think the growth in demand for user research is a result of a few things. Maybe some industry trends like continuous discovery, or customer centricity. Maybe it's the organisation realising that research is important, and they want to do more. Or maybe it's just UX and design and product maturing like other specialisations. Researchers are often a small team, or a team of one and they often just can't manage the demand for user insights to inform decision making.

How are you managing the increase in demand at Atlassian?

To keep up with demand, we need to upskill cross functional team members, in particular UX designers and product managers. We therefore need to ensure that the research conducted by our product teams is of high quality and answers the right questions. So the challenge is how do we maintain research rigour as well as our sanity?

I have a fair bit of experience in democratising research while maintaining research quality. The approach I use has four steps.

1. learn the signs that it's time to democratise
2. set up your UX research team for success
3. ensure you've got the right tools, processes and education in place
4. make sure they're being heard in the right places, and at the right decision points

What are the signs that it's time to democratise?

As with just about anything in UX, there's lots of definitions out there regarding what democratising research actually is. I'm going to define it like this.

Democratising UX research means enabling our cross functional team members to take part in or carry out UX research activities.

Imagine a small research team in an organisation where UX research is relatively new. This team might be a team of one or a team of a few people and it's centralised, they all kind of hang out together. When a research team is relatively new to an organisation, people with the job title UX research typically conduct all types of research across the product development lifecycle or double diamond. They might be supported by the cross functional team, mostly design product with things like note taking and synthesis, but the researcher is ultimately responsible for the whole lot. As the research team gets some runs on the board, the demand for research intensifies.

This is the point where you need to start thinking about how to democratise so that research runs smoothly for everyone, and the organisation can get quality results. Your tipping point is telling you two things:

1. you need to decide how to best utilise your dedicated researchers,
2. you need to train the designers and product folks to do some research and do it well.

How can you structure your team to enable this democratisation?

Being a UX researcher can be pretty tough. When you're a UX researcher, you're often confronted with really tight timeframes to get research work done. No one really understands what the point of view is, and your colleagues kind of get sick of you telling them that their direction or their design needs to change. It can be a lonely world being a researcher.

Researchers need a home base of sorts, fellow researchers with whom they can swap craft tips and rely on for support. Let's look at how this plays out in practice. Imagine you're working for a university, and you're working on that website. And there's five product teams; two of them work on the students side of the experience, while the other three product teams work on the university staff side of the experience. And in this example we have two researchers supporting the five teams.

Up until now in your centralised model, the two researchers been jumping between projects and product teams as demand dictated. However, things are getting really busy now. And they can't keep up with the demand. You've reached your tipping point. You've chatted with your researchers. And you all agree training the team to take on some research work will alleviate demand.

But where does that leave the research practice? This is where you create domains or product spaces for your researchers to hang out in. In our example this would correlate to Student and University staff domains.

Doing this has a few benefits. First, by sticking to a single product, space or domain, researchers can take more time to become really familiar with the product, its strategy, and its stakeholders as well as the current work. This means that the researchers ultimately deliver stronger and more actionable insights that aren't a repetition of what the product team already knows or thinks they know. The researcher has increased product knowledge which means that they can talk the talk and ensure the insights are applicable at the right time in the product life cycle. Finally, the researcher has a product team to belong to and do product team things with. If the researcher in question wants to learn more about UX techniques, or product management techniques, they can really easily do that. More importantly, they're included in stuff like interview events, in workshops, on emails, and most importantly, in any key decision making forums about that product.

What challenges can arise from having aligned researchers?

Looking at all this research that was going on, the gap that became immediately obvious to me as a dedicated researcher was exploratory research that spanned not only within a particular product, but also across multiple products, looking at the horizontal experience or journey of a customer, rather than just a product vertical, because designers were conducting research into their own products for the most part, and left a gap for exploratory future focused research, looking across products and beyond the same ecosystem.

In addition, specialist UX researchers are typically better equipped to handle the sorts of questions exploratory research asks, as well as tackle the trickier sorts of methods that you might want to utilise at this stage. And they also have more time to do it, because they're not trying to do design work or product work. On top of that, ensuring there's a partnership between UX research and product or design and executing the technical stuff also means your researchers need to keep all their research skills sharp.

Education

You need to conduct some formalised training to start people off on the right footing.  This ensures that everyone who does research has the same base level understanding of what good should look like. You can start by assessing people's understanding of UX research techniques. And then you can use that as a baseline to run some standardised training and some targeted training for specific groups.

If you're really pressed for time, train people up on facilitating user interviews and conducting basic concept testing. In my view, this is typically what designers and product managers end up doing a lot of. You can create a basic exploratory interview template for product design to use, they can then copy that and the depth of questions to their context.

Finally, encourage a culture of peer review and open sharing unfinished work. Ensure the researcher is setting the example by doing this as well so that the designers feel safe to do so too. The peer review culture ensures research quality and reduces the risk of research being invalid.  So set a guideline that no research happens without a peer review.

Processes

Once you set expectations and run some basic training to get things up and running, you need to think about enabling your designers and PMs to self service. This takes the pressure off your researchers over the long run. They can spend less time supporting the basics and more time supporting them to answer questions that are less clear cut. In addition, enabling your product teams to self service uplifts the capability even further.

Your final point is about getting research heard. How should people ensure that research is used?

Doing research is easy, getting it used is a lot harder. Lots of different types of research are happening, you need to spend some time working out where they'll have the most impact and ensuring that your research gets heard.

The first type of research is at a product team level. I would partner with product teams to embed exploratory research insight into their opportunity solution trees. For example, at Kohl's we worked with the group product manager to embed opportunities from research into their planning for each quarter.

The other type of research that researchers are responsible for is less clear. It's often exploratory and future focused. It's hard to understand how this impacts the products directly. And sometimes there might even be opportunities to explore new products, stuff your organisation doesn't even do yet. Its impact is longer term. And it's therefore less obvious.

This type of research influences the future product or problem spaces for the business to then investigate so we need to breathe life into it beyond the artefact to ensure it gets used in the right places. Once you've figured out the research artefacts in which your researchers work lives, you then need to get that work in front of the right people instead of influencing what the product team works on in the here and now. “Research it and they will come” is not going to work. People are busy and you need to help them draw conclusions.

Get really friendly with your stakeholders and get them to share these artefacts with you or better yet, run some co-creation sessions so you both have ownership over this.

What value have you seen from all of this effort?

The effect is that you get invited to more and more important meetings where those decisions are taking place.  After that, both the research work the product teams do and the research work the researchers do will have a place in your company's product roadmaps and ultimately in the products that ship.