Building an Organisational User Research Culture

Hi everyone. My name is Caylie and I'm a UX researcher at Atlassian. I'm speaking to you today from the lands, the ....... people of the Kulin nation. Now Atlassian is a pretty cool place to work as a researcher, our tools and processes are pretty well established, and we have decent researcher coverage across our products. However, that's not always the case in other organisations, as researchers were often in the small team, or a team of one. And to keep up with demand, we need to upskill a cross functional team members, in particular UX designers and product managers. We therefore need to ensure that this research conducted by our product teams is of high quality and answers the right questions. In each organisation have worked researchers just can't keep up with the demand for those juicy insights to inform decision making. And this creates a need for democratising research.

So we have a fair bit of experience in democratising research while maintaining research quality. In this talk, I'll share with you how to go about democratisation in your organisation, while maintaining research rigour as well as your sanity. But first, a little bit about me. I've never really known what I wanted to do. I suggested to my career's counsellor in school that I go on to study anthropology, because I've always had an interest in humans. And he replied, well, what will you do for a real job? We got along well, so this is actually quite funny. So instead, I chose to study Japanese Mandarin and linguistics way back when, because I apparently like a challenge. At the time, I wanted to be an interpreter, and I changed my mind. I then studied a master of banking and finance thinking that the combination of money stuff and Asian language stuff would be useful to someone somewhere. And luckily for me, this has proved pretty correct. And I landed a graduate position at National Australia Bank, which is one of Australia's largest banks. I was unlucky enough to rotate through the experience design team, and I was hooked. It may just so much sense to me to conduct research with the people you're actually building products for.

So I remained at NAB for a few more years as a UX researcher, and then I jumped across to seek one of Australia's largest job platforms. I spent the past year establishing the design research practice at Kohl's one of Australia's largest supermarkets. And I've recently landed a gig at Atlassian, a tech giant and Australia's most mature research practice.

So with that out of the way, what's the recipe for building an organisational research culture, our method for the recipe has four steps. First, you need to learn the signs that it's time to democratise too early in your organisation's journey. And you won't get any takers, too late and will be happening without you, potentially in risky ways. Next, you need to set up your UX research team for success. When you democratise, their roles and ways of working will be changing a little and you need to prepare for them. The next step is ensuring you've got the right tools, processes and education in place. So people are empowered to conduct research well. Finally, once you're getting all those juicy insights. Finally, once you're getting all those juicy insights, you need to make sure they're being heard in the right places, and at the right decision points. And we will say now that I've written this talk, assuming that there is at least one UX research person in your organisation, if you don't have a UX researcher, that's okay, I'll point out where in this talk, you can take parts of the talk and adapt it to your context. Cool.

So let's dive into the first step. Recognising the need to democratize. Democratisation of research is so hot right now, as many of us may be feeling, for whatever reason, I think demand for research grows, and UX researchers and the job market just can't keep up with that demand. That demand could come about as 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. To keep up with this demand, many research teams tend to democratising their research processes. And as with just about anything in UX, there's lots of definitions out there regarding what democratising research actually is. For the purposes of this talk, I'm going to define it like this.

So democratising UX research means enabling our cross functional team members to take part in or carry out UX research activities. So let's look at how a research team that reaches this point. So you can recognise it in your own organisation. And what I'm going to go through is based on my experiences at NAB, seek, and Kohl's. So one of that talk through art by any means hard and fast rules. This is a generalisation of what I've seen and experienced working in a few different places.

So I'd like you to 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 demand could also coincide with industry trends, as I mentioned earlier, and this is your tipping point. This is the point where you need to start thinking about how to democratize. So research ran smoothly for everyone, and you're the organisation are getting quality results. Your tipping point is telling you two things. A, you need to decide how to best utilise your dedicated researchers, and B you need to train the designers and product folks to do some research and do it well.

So now you know when to democratize. Let's look at how we make that successful. These other parts in the diagram I'll touch on a little bit later. So we're up to the second step now, structuring your team for success. 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 understanding 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, and researchers just need to feel the love, they want to feel loved.

We touched on embedding researchers in a previous slide. But that needs to be balanced with researchers having a home base of sorts, fellow researchers with whom they can swap craft tips and rely on for support. We are humans at the end of the day, and humans need other humans to empathise with their experiences. So 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, Product Team red, blue, purple, green, and orange. Product teams red and blue work on the students side of the experience, while the other product teams work on the university staff side of the experience. So in this example, we've got our team of some researchers over here. And we've got the product team, as I mentioned earlier, there's five of them.

And say in this team of some you have two researchers, these little folks in yellow. Up until now in your centralised model, they've 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 with 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. Let's look at what that's like. Here's one. And here's the other.

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 research has increased product knowledge means that they can talk the talk and ensure the insights are applicable at the right time in the product lifecycle. And finally, the researcher has a product team to belong to to 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.

So that diagram from earlier, the one with the different team types. You're now at the midpoint of that diagram, we are starting to have your researchers partner with product teams, and there's more researchers. So let's look at the next steps to make that partnership a success. So we've allocated our researchers to product domains, so they have a defined focus and they can deepen their relationships with those stakeholders. Next, you want to define what research work the researchers do, and what research work the designers or the product for it can do. New the role can do all of it. And we're not expecting non researchers to become researchers overnight. It's a specialist skill after all.

Ensure you turn this as a partnership between UX research and design a product Using this terminology sets the expectation that designers and product managers seek guidance from UX research on executing any tactical work. And it's therefore of a high quality and reduces the risk of findings being valid. If we think about the Double Diamond as it pertains to research, there's two broad categories here, research to build the right thing, and research to build the thing, right. The model I established at my past organisations sake mirror this, I came into the practice at a time where designers were beginning their foray into UX research for tactical pieces of work, just focusing on their product, at the same time, continue to discover it was being implemented in the product space.

So 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 sake ecosystem.

In addition, specialists 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 keep all their research skills sharp.

So summarising that, you need to give your researchers the place to exist and a purpose if there's other people in the organisation conducting the research to. This enables the researchers to do their best work and enables you to retain them also benefits the business by providing it with a wide range of data from which they can build great products. So we've covered when to recognise the need to democratize and how to structure your team for success. So let's look at how we build the right infrastructure to support that. So infrastructure in my view, comprises education processes and tools, I'm going to talk in detail about education and processes. Education comprises setting expectations and running some formalised training sessions. First you need to set the expectation with a broader design and product function around what the UX research practice will do. Outline the structure of the UX research team, and what types of research they lead compared with what types of product and design folk can conduct. All in partnership with their embedded researcher of course.

Make sure to include a point around the research has been available for coaching and support, that's essential to making democratise research work. Do this as part of an existing ritual or meeting so people have to listen to you and followed up with an email or a blog post people can refer back to. So they don't forget. Once you've set those expectations, you need to conduct some formalised training, just a little bit to set them start people off.

This ensures that everyone who does research has the same base level understanding of what code 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. For example, let's say I ran some broad training for product managers around Research Fundamentals, and some basic note taking training for one particular scholar who wanted to upskill in that area. 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 facilitating user interviews, 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 sharing open unfinished work should ensure the researcher is setting the example by doing this as well. So designers feel safe to do so to that peer review culture, again ensures research quality and reduces the risk of research being a valid set of guidelines, but no research happens without it being peer reviewed. And I've got here some examples of some education idea to my past organisations. This is expanding types of research seek, and this one's from looking in to training people how to ask good research questions, or sorry, good interview questions. So it's education out of the way, let's talk about 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 on 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.

First, we need to create some How to Guides. This is a great activity for that we're timing between Christmas and New Year's, we're not really sure what time means it's also great for Friday afternoons. Let's see, I created some basic how tos for note taking usability testing, writing an interview guide, choosing the right research method, and the process for storing and sharing research, as well as ethics and privacy. Sharing and storing research is pretty important. One of the risks around democratisation is that research kind of just ends up anywhere, and you can't find it again, that ultimately cost you time and money. Think about a low barrier way to share and store research so you can use it again, it needs to be low barrier.

So the people in your org who aren't researchers actually follow the process. For example, at seeking calls, I created a research report template in confluence that acted as the source of truth for the research, the report template only took a few minutes to fill out, which meant that people actually did it.

Another important point is ensuring there's some ethics place around the collection and usage of research data. This will look different depending on what country you're in. So I suggest chatting to your legal team and asking them how to go about storing participant personal information. And once you've done that, while it up something, once you've got some How to Guides sorted, tell people about them, and keep reminding them that they're there. So you're creating less work for yourself. Next need to create some templates, your designers and product folk will likely spend the bulk of their time conducting user interviews and concept tests, like I said, so start off with those. You can also have some basic survey templates to because surveys are the tricky things to get by including each template, some basic types of questions that users can then adapt for their context. Now, if you don't have a UX researcher handy, that's okay.

There are plenty of resources out there. But still going there. Yeah, there are plenty of resources out there to help you build out some of these things. And personally, I've used the Nielsen Norman Group website a lot. Regarding tools, not going to go into massive amounts of data, like I said, but I would encourage you to have some kind of intranet to house or your How to Guides, some way to store research, so you can find it again. And some kind of survey tool just to start you off. The rest, you can get done on a shoestring.

Alright, so we've covered the first three steps in our recipe, and we're up to the last step in our recipe, which is embedding the work in the right places. By this point, your researchers, designers and product folks are will happily partnering up and conducting awesome research. Now you need to figure out how to best embed that research.

So your organisation is making customer that decisions. This gets you the successful roadmaps outlined in the description of this talk. So this is the hardest part of the job. Doing research is easy, getting used is a lot harder. Now that 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 research gets heard. Here's a double diagram again. So now that the designers and product folks are conducting research to build the thing, right? It's pretty straightforward. This research ends up things like ship designs, ship products, or journey maps for a particular product. That's easy. The type of research that you researchers are responsible for is less clear. Because 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. The artefacts in which this type of research lives include things like product roadmaps for a journey. Sorry, let me say that, again, include product roadmaps, Australia documentation, or even some journey maps relating to experiences across a particular organisation rather than just one product.

Get really friendly with your stakeholders and get them to share these artefacts with you or better yet, run some procreation sessions and make them to get them so you both have ownership over this. I'd say I would partner with product teams to embed exploratory research insight into their opportunity solution trays, for example, at Kohl's and work with the group product manager to embed opportunities from research into their for planning for each quarter, get really in people's faces and find where those documents take place. However, it's not just artefacts we need to worry about. This research has a long lifespan, and we need to breathe life into it beyond the artefact to ensure it gets used in the right places. So 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. This type of research influences the future product or problem spaces for the business to then investigate. Research it and they will come as a Vive is not going to work. People are busy and you need to help them draw conclusions you need to put that research in front of them and really spell it out what it means.

So that doesn't work anymore. Bring those decision making stake holders along the journey with you and link the insights to the business context. To demonstrate that by incorporating research data, we're increasing the certainty that our strategies and roadmaps are correct. Doing this means that those decision making stakeholders will trust that you know what you're doing. The phone and affection this is that you get invited to more and more important meetings where those decisions are taking place. Or you can set that expectation way back when you're educating a team. Keep being persistent. It's really hard. But don't give up. Keep asking, keep showing your work keep proving why it's valuable. Keep explaining how it fits in and the invites will come. Keep an eye and an ear open for meeting titles like quarterly planning, jobs to be done. Journey mapping vision or strategy.

That's likely a place where your research will have value get into those meetings. 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 also with ship products. It's about finding the artefact and getting time with the people who own those artefacts. Few so thanks for coming on that journey with me. Wrapping up what we learned today we talked about recognising the need to democratize and looking at looking for that tipping point. We talked about ensuring your researchers have a home and a purpose. We talked about ensuring there's the right infrastructure in place, education and processes. And we talked about embedding your great work in the right places for maximum impact. And lastly, start kicking goals. Thanks for listening.