Building stakeholder trust in UX research: your first study, first allies and what not to research

Henrik Mattsson · 00:09
Hi everyone, and welcome to another episode of the UX Research Rundown. My name is Henrik Mattsson. I am the CEO of Lookback and I’m also the host for this show. With me today, I have Josh Williams, who is the Director of UX Research at Indeed. And he also has an interesting background in a bunch of different companies. So I’m sure we’re going to have another great conversation about engagement, stakeholder engagement with research, and how to bring people along on the journey. But as always, as per ancient tradition here in season two, we will start by getting Josh’s background and origin story, so that we know a little bit about where all of this is coming from, and another story of how to get into research leadership.

So, welcome to the show, and thanks for being with us.

Josh Williams · 01:02
Yeah, thanks for having me. Super excited to be here.

Josh Williams’s path from cognitive neuroscience to UX research

Henrik Mattsson · 01:03
Cool. So, could you start by giving us your version of how you got into research? When did you find out that you were a researcher, and how did you lead up to the point where you are today?

Josh Williams · 01:22
Yeah, definitely. I’d have to go back many, many moons ago, but really, I’ve always been a curious person, always interested in how humans in particular think and perceive the world. I started out wanting to be a physician, and I happened to do research in undergrad that really made me veer off the MD path to the PhD path. I got my PhD in cognitive neuroscience. And towards the end I realized I maybe didn’t want to be in academia. I think a lot of folks that come from academia into industry follow that same path: they wanted to have more tangible impact and those types of things.

So as I was leaving academia, I was actually really interested in data science. That really fit well with what I was doing. From a linguistic standpoint, I could work with AI and do language processing and that type of thing. But I realized that I was going to miss the human experience a little bit. And so I actually happened upon UX research by accident. I knew about this company, Bose, because every Christmas or holiday I would visit my husband’s family, and we would always pass by this big company on a mountain.

And I was like, I’m going to just see what jobs they have there. I actually Googled research audiologist, or researcher, because it fit really well with my background. And a user researcher job popped up too, and I read the job description. I was like, I can totally do that. And I applied, and somehow I got that job. And that’s the history. I started at Bose as a senior researcher, worked my way up as a lead researcher on their innovation line, and have subsequently moved from there, and now I’m director of UX research.

And it fits so well with what I love to do. I love teaching folks how to do research, and just bringing people along and grounding them in user experiences. I’m sure we’ll talk about it, but I always see researchers as connectors and as shepherds, and that’s what I love to do, to bring people along that path. And I think it even connects to me being really in love with being a teacher as an academic as well.

How research culture differs at Bose and Indeed

Henrik Mattsson · 03:40
Oh, interesting. A lot of that resonates with me. I also have a background in academia and then wanted to do something else. And I love teaching too, so I know exactly what you’re talking about. Super interesting. Well, I’m just going to jump straight in. What I’m interested in, in this podcast, and it seems like we can just do an endless amount of episodes, because everyone is bringing something to the table and this is a big, big problem, whether it’s teaching or making connections or whatever it is, is this whole challenge of bringing stakeholders along on the journey.

And perhaps stakeholders is not the right word, but there are a lot of people that would benefit from engaging with research, whether it’s an insight after the fact or live observation or whatever it is. But when I speak to researchers, which I do a lot because we have a research tool, right? So we research researchers. It’s pretty clear to me that the experiences are very different in different companies. It depends on what culture the company has. It depends on the maturity level of the research team, et cetera, and how everyone works together.

So from your perspective, if I say that’s what we’re interested in, what comes to mind? What are some of the challenges? What are some of your experiences that you found interesting or difficult?

Josh Williams · 05:07
Yeah, I think that’s absolutely true. Every company I’ve been at has had a very different research culture. When I think about when I was at Bose, most people don’t know this, but Bose is owned by MIT. So there’s a lot of PhDs. And generally they see themselves as a research company that sells audio equipment to pay for research. And so that culture was quite different, where folks might not join sessions, but they’re very engaged once the data does come out. And that changes the way that you think about your deliverables, because you can be maybe in the weeds or pretty scientific, because folks are going to take the time to engage with that.

On the other hand, I’ve been at companies, even like Indeed, where folks really want to be connected with the user and ground themselves in the user, but they’re also really busy and they want to get that higher level feedback. So you have to think about: what is the ROI on this deliverable or on that insight I can provide, so that I can effect change without requiring a lot of time or effort? I’ve seen it change from time to time because of those cultural differences. But one of the things that I think is always important is the engagement of any stakeholder team with the research team.

If you don’t have that foundation of trust or respect, it doesn’t matter how you want to share insights or what the form of that deliverable is, it’s not going to resonate at all. And so I think part of bringing folks along on the research journey is building and earning trust as well. And knowing that we are here to enable decisions, not to tell you whether you’re right or wrong, or the more territorial aspects of being a researcher. And I think that has really served us well.

So I really train researchers, and have us all think about: how can we be shepherds, or be folks that guide but don’t dictate? How can we still be advocates but not dictators? And I think that’s been really helpful in getting that foundation. And then there’s lots of different ways that we might implement bringing stakeholders along.

Earning stakeholder trust by learning the business first

Henrik Mattsson · 07:23
Interesting. So how is that received? Do people immediately get it and like it, or what’s your experience there?

Josh Williams · 07:36
Yeah. For the most part. I think Indeed is quite an exception. It’s such a great place and so user centric. But I would say in most places it’s not immediately seen. A lot of times folks, and rightly so, we all own the user experience. And so oftentimes folks will say, well, I already know this data, or I know this, why do I need this research, or why do I need a research team or a researcher? Particularly in organizations where there’s just one researcher supporting. What I’ve seen be really effective is calling out inconsistencies or knowledge gaps without being on the nose about it.

Asking questions that really challenge the perceptions, or maybe the misconceptions, that team members have, and being ready to back it up with some data or with a solution. And if you do this in the right way, and there’s a little bit of politicking, a little bit of cultural things you have to take into consideration, you open the eyes of stakeholders to see the value of what you do. And that is the first step in earning trust, before you even do any deliverables: knowing that you’re knowledgeable about the product space and about the business, and why we should care about what we care about, and how the user journey dovetails into what they care about.

Right? PMs often care about moving business metrics. They’re incentivized to be more focused on business metrics than necessarily user experience. They should be correlated at the end of the day, but they’re not necessarily incentivized to care about the user experience at a particular level. And so if you can speak their language, you can move them in that direction. And so for researchers in particular, if you’re new to the company or if research is new to the company, generally not trying to rush to do a study, but taking time to do almost an ethnography of your business and the people within the business is going to pay dividends.

Because you’re going to know how to speak their language, you’re going to know what they care about, and then you can approach them in ways that build bridges.

Making your first study count

Henrik Mattsson · 09:44
Yeah. That’s so interesting. When I speak to research leaders, I hear this trade-off constantly. You have a job to do. You need to produce studies. You need to produce these results. But you also need to do all of this trust building, and you need to slow down, especially if, perhaps, you’re the first researcher there, or if you’re just building out the practice. It does take time. And that’s so interesting to me, because I’ve seen that in my own experience too, and how this gradually happens.

When you go through that journey, it’s so obvious that this is the way to do it. But when you’re at the beginning of that journey, it can be so stressful. I don’t have time, I need to produce things right now, et cetera. And I always feel a little bit reluctant to give that advice: just trust that you know what’s going to work. What’s been your experience in building that up gradually? And what’s some advice for people who are starting to doubt the process, or starting to want to rush it a bit?

Josh Williams · 11:00
Yeah. One of the things I try to remind researchers of, typically more junior researchers, is that the unit of measure for a researcher is not a study. I just don’t believe that our job is to just do studies and conduct research. It’s just fundamentally not how I perceive what researchers are. As I mentioned, we connect dots, we triangulate. Sometimes you don’t need to do any research in order to help unlock a decision that is still user centric. There’s plenty of data that might already exist.

And so I don’t think that we should encourage just producing studies for the sake of doing it. For those new researchers, I would argue that you should not aim to do a perfect study. That’s kind of a misnomer. But your first study should be quite impactful. And if it takes a little bit of time to do that, fine. It is challenging if you are in an environment where you don’t have research leadership. I can advocate for my team and say, listen, that person’s not doing that study, I don’t think it has the right ROI, I’m going to have them focus on this, and that gives them some runway.

But if you have a 30, 60, 90 day plan, and in the first 90 days you’re supposed to deliver a study and you’re not doing that, that can be a challenge. And so if you have to do a study right away, think about what is going to be the most impactful, or at least what is going to be the most buttoned-up, bulletproof study that you can do. Because if no one can poke a lot of holes in things, it also builds trust in that other way.

Because what everyone is going to do on your first study is try to discredit you, if there’s not a huge UX maturity. And so you have to do a study that’s going to prevent that. And in that way, going back to the theme of this conversation, bring them along, to show what it takes to recruit, or what it takes to do certain aspects of the study, why it takes the time that it takes, so that they have that visibility. And then when you deliver the final result, it’s not a surprise.

That’s the other thing about building trust: you don’t want to surprise folks with the results. Particularly if you’re in a more adversarial or a low UX maturity environment, you want to bring them along the way, so that they know what you’re going to say by the time you give them a deliverable. And even better, if you can get them to think about the solution or the answer before you say it to them, they feel like they own the output or the outcome. And that also gives you some more leverage or trust as well.

Sharing research before it’s finished

Henrik Mattsson · 13:42
No, I totally, I’ve seen that also. And it’s interesting, because when I’ve been researching how stakeholders observe research, the obvious thing that jumps out is that they get to see the user struggle with the product or something like that. And that’s a very strong experience. It leaves its mark. It’s hard to walk away from that and be unaffected. But one thing that I hear from researchers also sometimes is, I’m glad that they can watch me work, because they understand what’s involved, and that this is a real thing that is actually hard, and that I’m actually doing a good job at it.

So it’s interesting that you say to bring them along on how hard it is to do the study and everything. I think that’s very wise. But what you say about how to share is interesting. Another thing that researchers tell me is that there’s this reluctance to share information along the way, because they’re worried that a designer will just go, oh, the research is done, I’m going to take this insight and I’m going to go build this thing. And I’m like, no, no, no, wait, that’s not done, we have more stuff.

But you seem to be saying the opposite, and I think you’re right. I was wondering if you could expand a little bit on that: the effect that has on the trust building, and how to take that leap. Because I think a lot of people are holding back. They think to impress someone, it needs to be finished work. It needs to be a conclusion that you can underpin. So there’s a contradiction there.

Josh Williams · 15:22
Yeah, I think there’s a couple of things with this. One is that allowing designers to ideate throughout the research cycle is a good thing, because they might generate more questions that you can quickly iterate on in your own research design, and get them answers. And so you might ultimately get more insights than you had expected throughout that process. But also, to take the designer example, the world that they live in and the thing that they’re trying to produce is a tangible design. If they’re doing that while you’re conducting research or delivering insights, they’re inherently feeling more connected to the data.

They’re not an observer anymore, they’re an active participant, because the way that they do their job is to design. And so they’re doing that while you’re doing research, and that helps ground that a lot more. I also think that decisions rarely are irreversible. Amazon called them one-way doors. There’s rarely a one-way door situation. And therefore, if a decision is made during your research sessions, and you come to find a little bit more nuance or something along the way, it’s fine to say: you saw that, but look, here’s some additional data that we came across, and how might we change that decision to be a little bit more aligned with the data?

And I don’t think that conversation is going to be that difficult, because you’ve already gotten them bought into there being value in your data, right? They’ve taken an action on your data, so they’ve already bought into it. Now when you provide additional data, they should be open to making that change. And if not, the whole name of the game is iterate. So if we need to iterate, fine. That’s part of it, and that’s going to make it better. Because the next time we approach this topic, we’re probably going to get better insights and have better output as well.

Tying research to OKRs and what keeps stakeholders up at night

Henrik Mattsson · 17:27
Yeah. Interesting, interesting. So you started by saying it’s important to make, should I call it, a good first impression of research, rather than producing a bunch of studies. Not the perfect study, but a good first impression. So this seems to be one part of it. Are there any other things? What does setting up your first study for success mean? What are some other things to think about there?

Josh Williams · 17:57
Yeah, well, I think it goes back to this idea: if you’re just producing for the sake of producing, no one’s going to care anyway. It’s like an empty promise. And so when I say setting yourself up for success, it’s really tying whatever you do to something that’s meaningful to whatever stakeholder that you’re creating for. It’s really easy, as a good starting place, to look at OKRs or KPIs or big strategic initiatives, which most companies have. If you can start there, it’s already, by definition, prioritized, right?

And folks should, by definition, care about that thing, because they’re being measured against it as well. And so whatever it is, you need to try to connect the research you’re doing to a meaningful thing. And particularly if you can find out what that thing is for your stakeholders, that’s going to be really important. Otherwise, even if you could execute six studies, do evaluative research and move a whole bunch of designs forward, it’s going to have just a low impact and a low ROI. And it doesn’t have to be months to do a full ethnography.

It should be pretty salient. You can always ask your manager in your first one-on-one, what does the business care about right now? What are you working on with the PM? And ask the PM, what do you care about? What business metric are you trying to move? And really think: what knowledge gaps might there be? What are they missing? What are their blind spots? And how can I elucidate that and fill in that picture for them a little bit more? After a couple of conversations, particularly with your whole product team, you should be able to find what that is.

So I don’t know if that’s super tangible for what you’re looking for, but I think that’s really the common theme. Find what people care about and what keeps them up at night. I hear that a lot: ask them in your first one-on-one, what’s keeping you up at night? That might be a good starting point, to say, if I could solve that problem, I could make them sleep a little bit easier tonight. That’s going to get a lot of buy-in and move the needle a little bit.

In Lookback Ask stakeholders what they need to know in a stakeholder interview, and Lookback turns the answers into research goals. Learn more

Finding your first allies: UX peers, PMs and data scientists

Henrik Mattsson · 20:12
I think it’s tangible. Over the course of this podcast series, I’ve learned so much about all the different ways that people do this. But there are also some common themes, and you jump into some of them here. One is to start early with almost discovery. You start early with your stakeholders and ask them, what do you care about? And you bring them along. You don’t wait until the work is finished. You don’t show up later with a big, statistically significant report and go, look. You involve them.

But I got some feedback from someone who just got into the field: that sounds lovely, I want all of that, but how does it work in practice? And I think what you’re saying there adds a lot of meat to it. Another thing that I’d like to explore a little bit is this. Let’s say we’re in the situation now: you’ve just started, perhaps the research maturity is a bit low, they haven’t really done this before with building this trust and everything. In your experience, are there particular functions or personality types that you should try to target?

Are there some first allies that are easier than others?

Josh Williams · 21:42
Yeah, I think generally your closest UX peers, whether that’s content or design, are probably always going to be your biggest supporters. They get it, they’re already bought into it. And particularly if you have a designer or someone that has a really good relationship with their PM or their science partner or their engineering partner, even start there. If you’re in a low maturity organization, you’re probably one of the few researchers, which means you probably support a large scope. Find the team in your broad scope that is going to be your biggest advocate, or at least the most open.

Don’t start with the hardest problem. Don’t start with that team, because the others are going to get jealous. Once you start focusing your time on a particular team that’s getting good results, people are going to start asking for your support as well. And so go where the water flows freely first. Use your UX partners as advocates. I think that’s really helpful. Oftentimes I find that the PMs that are focused on business metrics, or that have a really good relationship with their data science or product science partners, are also most likely going to be open.

And then you probably have to sell how qualitative and quantitative data matter in building a full story. I have a pretty common saying: iterate and triangulate. When all else fails, iterate and triangulate. And you can lean in on the triangulation piece and say: you really care about product metrics and all this, let me show you how the qualitative data can tell you the how and the why, because you have a really good understanding of the what and the when. And if you can do that, then most likely that’s your first advocate, because now they’re already a data-driven individual that can then advocate for the importance of qual.

You have to be careful. There are some folks that discount qual so heavily, because they’re like, well, quantitative data is ecologically valid, it is the thing that matters, and I don’t care about the qual. You’re not going to want to try to ingratiate yourself with that person to start with. Because while they’re data driven, they already have a bias against qual data, and that’s a roadblock or a barrier for you.

Henrik Mattsson · 24:01
Right. So what do you do in those situations?

Josh Williams · 24:09
I mean, if that’s the only person you can work with, I think, like I said, triangulate, and say: let me then work with the data scientists to understand that space. How can I then bring qual feedback and round out the picture? Oftentimes the data scientists will be pretty forthcoming and say, I don’t know why this is, but we’re seeing this pattern. And you’re like, I could probably figure out why that is. And if you can figure out why something’s happening, you’ve already shown immediate value.

And again, if you even just present that to the data science person, they now become an advocate, to say, oh, we need qual to round out the edges here, let’s bring in user research. If you have design and science coming at it from both ends, the PM kind of has to accept it to a certain point.

Prioritizing research by risk and knowledge gaps

Henrik Mattsson · 24:59
No, this is good advice. One thing I’ve seen: I was talking to one of my designers the other day. We’ve worked together for a long time, and in the beginning, when you don’t know so much and we didn’t really have a research team, we were pretty comfortable guessing what we were going to do. Well, okay, we’ll have to bet on this. And the other day we were having a conversation, and I was like, so do we do this? What do we do here? He’s like, I don’t know, I haven’t had time to review the research yet.

And I was like, okay, that’s the end of the advocacy journey. No one else is in the room. No one’s looking. The research isn’t there. It’s just him and me. And he won’t give me an answer because he hasn’t seen the research yet. And that’s so powerful. But it starts with this patient work that you’re talking about. So everyone going into research, listen to Josh. This is very good. Okay, let’s move forward a little. And if you have other things that are more interesting to say than whatever my questions are trying to pull out of you, please interrupt me at any point.

But if we move forward a little bit in this journey: you’ve arrived, you’ve found your first advocates that you’re starting to work with, you’ve done a first research study, and people are starting to appreciate this, and they trust you and all of that stuff. What are the next challenges that you encounter as you move along on this journey?

Josh Williams · 26:27
Yeah, a couple. I think one is prioritization. And I think this even goes back to building advocates: don’t try to do everything. We’ve talked about not doing a whole bunch of research. Be mindful about the research that you do. Oftentimes now the demand is, like I said, jealousy: this team over here wants you and this one wants you. It’s about prioritization, and that’s going to be your biggest challenge. What frameworks, or how do you think about what’s going to be the most impactful? Because at the end of the day, there will always be infinite questions.

It doesn’t matter how well you think you know your users or your product, there will always be infinite questions. And so it is up to the researcher to help guide folks, to say: I hear you, I hear that this is what you want, but I’m listening to the business, and I am thinking that this is probably a more important use of our time. Because there are times where I think we shouldn’t be doing research. Use your subject matter expertise. You will be 80%, 90% right.

It’s totally fine. What are those 10% of times, or those areas, where the risk is really high if we don’t have high certainty? Or where is the knowledge gap so big that we can’t make a decision in the absence of research? And if we can use that kind of framework of risk versus unknown, we can then help prioritize. And then you will also see that inherently that means you’re doing the highest impact work. And you can continue to sustain that, even if you’re turning away certain teams or certain projects.

Scaling research by enabling teams to find their own insights

Henrik Mattsson · 27:54
Right. This brings me to something I’ve been thinking about lately. I used to think that from the tooling perspective, our job was to help teams find insights. And you can imagine that research leadership is also about that. But I started thinking about it differently. And when you were talking now, it struck me that it doesn’t really scale very well. Research leadership is more about building. I think about it from my perspective, with tooling. But research leadership is also about creating a culture and a way of working together that will help people generate their own insights from research.

What do you think about that idea? And is that a potential solution to scaling yourself as a leader?

Josh Williams · 28:45
That was a very neat thing. I mean, I think yes, I think so. It kind of verges on the topic of democratization, which I don’t know if I want to go down that path. But I think in general it is about a culture of curiosity, and knowing when you need the tools that you need. If you’re a product person: when do I need to pull a research lever? When do I need to pull a data science lever? When do I want to make my own decisions?

Thinking about it that way is really important, because we can’t answer all those questions. And so I try to say, like I mentioned, we’re enabling decisions. How do you best use us to enable those decisions? We don’t expect you as a PM to know everything there is to know about your product, because oftentimes that doesn’t scale. The bigger your scope is, or the bigger your product is, you can’t know all of it. It’s: when do you lean on the experts around you in order to make those decisions or to uncover those insights?

And how can we enable that self-discovery, whether it is through a great repository, or deliverables that are pretty evergreen, that are easy to access and consume, whatever that looks like? How do we enable those folks to do it, even if they’re not conducting the research themselves?

In Lookback Share a single finding with a public link, including with people outside your Lookback organization. Learn more

Henrik Mattsson · 30:00
Yeah, yeah. It’s interesting. If you get this right, everything that you’ve been talking about, then this goes to the core of the theme of the podcast, with the engagement. Every research leader I’ve talked to where I feel like, okay, they got it right, they described this situation where you very quickly become a scarce resource that has to say no a lot. And that’s a big scale problem. And as a research leader, thinking about teaching individual contributors, or other researchers coming in as you start scaling, because you hire people because you want to do more research: do you teach them to deliver insights, or do you teach them to build engagement?

Because the building of the engagement will, you know what I mean. What is the future of research? Because it’s a real problem for our field. It’s great that the demand for research is growing, but we can only educate people that fast. There aren’t enough researchers. So what will the future look like here?

Josh Williams · 31:14
Right. Yeah. I think the enablement piece is a big piece. If I’m being completely honest, I don’t staff my researchers as high as the demand. Even if you gave me an endless talent pool, I would probably create scarcity. I want that to happen. And I don’t want researchers to feel really empowered to answer every question that comes across their table. It’s just not a good use of our time. And so I don’t even staff that way. And because of that, I think it’s about enablement: being a thought partner, allowing folks to discover insights themselves and making sure we empower that, and letting experts make expert decisions on the things that are not risky and don’t matter.

There’s a lot of places that have a rapid research team. That’s one solution to this problem: let’s have a rapid research team, where they can come in and do some quick studies. And even that can sometimes have, I think, downstream detrimental effects, because then we want to evaluate and test the smallest little bits of our experience. And if we’re empowering designers to make really good decisions based on standard practices, we don’t always have to test everything. And so it’s about enabling access to insights, bringing them along the journey, and finding the right stakeholders, the right partners, to help unlock that, and making sure that everyone’s aware of that and can be advocates for this.

We see that here. I don’t even know what the number is, like hundreds of reports a month or something added. We have like 160 researchers here. And it’s about not having to come to research to find the data, but being able to ask a random other PM, and they’ll know about it. Making sure that there is connectivity, a web of information, across everyone at the company.

Researchers as strategists, not evaluators

Henrik Mattsson · 33:14
I love it. Well, we’ve reached that point where we’re running out of time. I think this could have kept going a long time here. It’s so important, I think: how to build this up and how to trust this process, because it’s not an intuitive process. When I hear research leaders talking about that, it makes so much sense after the fact. But if you’re starting out and you don’t know these things, I would have been scared. So, as a final question: where do you think engagement is going with research?

You’ve been in this industry for a while now, and I’m sure you’ve seen these trends come and go, and a lot of things changing. What is the place of research in 2023 or 2024? What’s keeping you up at night as a research leader? What are you thinking about?

Josh Williams · 34:18
Yeah, I think there’s a couple of things that worry me, or that I think about. One of the things is the rapid growth, and it’s not necessarily a bad thing, but the inconsistency of how UX research is implemented across companies, which means that everyone’s perception of what research means is vastly different. Because we don’t have a standard or consistent experience, particularly as people change jobs, that sometimes creates a lot of friction. And so how might we come to a point where, not a standardized one, I don’t really want it to go in that direction, but where we have a pretty consistent experience, and fewer researchers trying to figure it out on their own?

Because that creates its own environment, its own kind of expectations. And the other part that I think about is: how do we uplevel research? I’ve said this in lots of other places: I think of researchers as strategists. And at a lot of companies, researchers always start out as evaluators. They do a lot of evaluative design research. And I want us to be at the point where we have the clout, the buy-in, to work with the business and use data in support of that. How do we become advisors?

That’s where I would love to see research go. Those are the two things that I think would unlock a lot of the potential of data and research expertise: consistency, and being a more strategic partner.

Henrik Mattsson · 36:00
I know I said that was the last question, but this was so interesting, so I’m going to ask a follow-up. Are those related, or are they just two things that you see as important? Do you think we need, not standardization, but to up the game there in order to take that last step?

Josh Williams · 36:15
I think so. I think so, because if you’re stuck in just doing evaluative design research, or whatever it is, you can’t level up. The pinnacle, as I see it now, the last step of a really good and effective research team, has to be product strategists. You can’t get there if you’re stuck with the expectation that every design that comes across your table, you’re going to do a usability study on it. And that shift from evaluative to generative even then needs an additional shift. I think oftentimes we make those dichotomies or separations based on method.

And we have to elevate ourselves: methods are tools, not a way of working. I think we get stuck in what we do, these certain kinds of methods, and think that’s what our job is. Our job is to answer questions and unlock decisions. Which tools are we going to use to do that? And so they are really strongly connected. As your UX maturity grows, you move in that direction, but you can still get stuck in that local maximum, being a really good research team that hasn’t made it to the strategy yet.

Henrik Mattsson · 37:31
Right. Well, love it. Thank you so much for coming on the show and sharing all of this stuff. I wish we had more time, but c’est la vie. Have a good time, and hope to see you around. And for everyone who’s listening, thanks for following the podcast, and happy researching.