Engaging stakeholders in UX research: internal discovery, transparency and the flywheel

Henrik Mattsson · 00:09
Hi and welcome again to the UX Research Rundown podcast. My name is Henrik Mattsson. I am the CEO of Lookback and your host for this show. In this podcast series, we are talking about what I think is one of the most important and interesting challenges that we’re facing in our industry and community. And that is: how do we get the people who are building the experiences that we are researching to engage and participate in our research work, and leverage all of the wonderful insights that we surface to actually build better experiences?

We have been talking, and we will be talking, with a lot of interesting researchers from different parts of the industry. And today we have with us Vanessa Wiegel. I’m Swedish-German, I hope I pronounce that correctly. You can correct me if you want, but thank you so much for being here.

Vanessa Wiegel · 01:11
Thank you so much for having me. That is the correct German pronunciation. I also go by Vanessa Wiegel, the more Americanized version. And, yeah, I’m thrilled to be here on the podcast.

Vanessa Wiegel’s path from documentary film to human factors

Henrik Mattsson · 01:23
Awesome. What I think is super cool is that you have an interesting, a little bit different background from some of the other leaders we’re talking with on this podcast. You’re working in hardware. You’re currently the senior director of UX and Human Factors Research at Motional, doing self-driving taxis. And before that, you were at iRobot, building or researching vacuum cleaner robots and things like that, right? And before that, you have a super interesting step where you were at PBS, in educational programming and things like that.

So a super interesting mix. We’d love to hear more about that. So I’d love to start, as I always do, with getting your origin story, because I think it’s super important as a background to understanding where all of these interesting things that I’m sure you’re going to share with us came from. The point of a podcast like this is to spread knowledge that is there in the industry but perhaps not accessible to everyone. We’re a young field, and I think it’s so important to put that into the context of where those insights came from, because it’s rarely a straight path.

So could you start by sharing how you got into UX research? When did you realize, oh, I’m a UX researcher, and things like that?

Vanessa Wiegel · 02:54
Absolutely. Yeah, it definitely was a circuitous route. For the formative years, I think some helpful context is that my grandfather was a toy inventor in his free time, and he worked full time on the space shuttle and for GE on Gemini and such. I think he had a big influence on me in terms of working in technology, and invention, and creating new tools that don’t exist. And toys. And when I was a kid, I would also see problems that existed, and try and iterate and brainstorm solutions to them.

I didn’t realize this until I took this job recently at Motional, but, for instance, I grew up in New England. There’s a lot of snow, and I had an experience as a child riding in the car with my mom, and we fishtailed off the road in the snow. And so I set about prototyping a device for dispensing sand over tires to try and get traction, because it was kind of a scary experience. I was like, how can I help? And then also, I don’t know what that says about my mom’s driving, she backed into another car.

This was before backup cameras existed, so I went about trying to figure out how to hook up a VHS camera to reflect what was behind her. So I think those were all early experiences that I had. But I actually moved away from that in school and thought I was going to be a doctor. I started as pre-med in my undergrad program, and I was pursuing that. And midway through undergrad, I took what I thought was going to be a blow-off video production course, and I fell in love with storytelling and documentary film, and actually ended up getting my degree in communications out of undergrad.

From there I went to work on a documentary series for the History Channel, and very shortly thereafter moved to PBS, which you had mentioned, working on educational television and websites, and later mobile apps. I was working on one of the PBS shows, Arthur, on an educational website to help parents and children with a variety of health issues: asthma, peanut allergies, et cetera. And I was talking to a graphic designer at the company, and she introduced me to the concept of thinking about user needs. How should we be thinking about the needs of a parent coming to this website?

I started doing some research on what sounded like a really interesting field. I discovered Bentley University’s Human Factors program, sat in on the foundational Human Factors course, and I was like, oh my gosh, this is so interesting. It’s leveraging an understanding of the brain and human behavior to design better products and services. This feels like the perfect fit. So I started getting my degree while I was still working at PBS, and introducing user research and UX design to the organization. And then from there, I joined iRobot to found and then build up their design research practice, and then moved most recently to Motional, where I am now.

Understanding problems versus building solutions

Henrik Mattsson · 06:14
Wow, that’s quite a story. I love that. So do you identify with this as almost an inventor, or is it more… I hear two things here. One is that you fall in love with problems. You see the problem and you’re like, how can we solve this? But you also have this side of actually building the solution, hacking together cameras and stuff like that for the backup. Is it still a mix in you? Or have you really landed in understanding the problem and helping others solve it, if I put it like that?

Vanessa Wiegel · 06:55
Yeah, I think what I most enjoy, and what my skill set is most linked to right now, is really understanding problems, understanding the needs, and working with designers to brainstorm and develop concepts. In terms of the actual execution of that, I haven’t leaned into that for a while. And I think there are more skilled designers and prototypers out there than what I can offer. But I love that process of finding those design opportunities and exploring different ways to address those needs.

Storytelling and getting stakeholders engaged

Henrik Mattsson · 07:31
Interesting. I was talking to Matt Gallivan from Slack yesterday. I don’t know if you know him, but he said this interesting thing, because I was fishing for what are some of the characteristics and skills that we need as research leaders. And he mentioned that you need to know what you’re good at, but you also need to know what you should leave to others. So there seems to be this increased specialization. Super interesting. Okay, cool. So I’m going to shift over to the main theme of the podcast, which is: how do we get people involved?

There was something in what you said, I don’t know if the audience also got that feeling, but I really got this feeling that you have a fascination with problems. I don’t know if you recognize yourself in this, but it’s almost pre-professional. It wasn’t your job to put sand in front of the wheels. You’re just interested in the problem. And it made me think about how often, when we’re getting engagement, what we’re doing is helping other people fall in love with the problems that we have fallen in love with.

Would you agree with that? And with the storytelling that you have in your experience, telling great stories and everything, what has been your journey as a storyteller, trying to lift problems and help other people get involved in them?

Vanessa Wiegel · 09:10
Yeah, I think I’ve had the good luck and fortune that, with the companies I worked for, I’ve naturally found a lot of people who love the problem, but who need help in figuring out how to solve it. So I don’t always have to develop passion for solving the problem, but passion for why user research is the avenue or the platform through which to answer that and solve that problem. The storytelling component, and leveraging that background in film and documentary, has been very helpful in terms of evangelizing research, bringing case studies to life to show, this is the impact we can have, but also really just making the data come alive.

Because I think, as we know, you don’t just do one readout and expect that that’s going to get acted on, or that that’s the best way to socialize insights with an organization. So we think about not only what happens in that readout in a long-form format, but then how we disseminate insights in shorter-form content. And I think a lot of what we did to get our stakeholders engaged at iRobot was connected to that. But where I always start with engagement of stakeholders, when I get to a new workplace or when I have a researcher joining the company, is really to encourage them to start by applying your research practices to your stakeholders.

Understand what their driving motivations are. What are the problems keeping them up at night? Really seek to understand their anxieties, their level of understanding of our processes, and what sort of biases or assumptions they might have around that. Really thoughtfully choose that first project that you’re going to tackle with them. And it might actually be more tactical than strategic at first, because you want to show some immediate value. Get them engaged in doing a brainstorm of research questions. We have a process of doing this on a quarterly basis, where we come together: the researcher, the product manager, the engineers, the designers, and if relevant, we try and pull in the data scientist.

And in my case at iRobot, where it was interdisciplinary, the market researcher. And we’re jointly, all together, brainstorming: what are the questions we need to answer? What are the challenges we have with the product right now? We’re mapping that out by the type of research that it merits. Is it more discovery, exploratory, definition research, or validation research? And then we’re choosing that first study, and the researcher is bringing them aboard: this is my proposal, getting feedback, here’s the people I’m thinking about recruiting and here’s why, and talking through that.

Depending upon the method, if it’s interviews, engaging them. We do a lot of ethnographic work, a lot of contextual inquiry, diary studies. So finding ways to engage them in the process of the data collection and analysis, sometimes doing joint analysis sessions with them when we’ve had a little time to initially process it. And then after that, of course, there’s the readout. And after that readout, thinking about other ways to go beyond that: workshops that we plan around the implementation of the recommendations, and making sure that we’re drumming home what the insight is and what the recommendation is.

I think sometimes these get misinterpreted, or you can’t rely on one readout for people to fully understand. And of course, it helps when they’ve been there the whole journey and they more deeply understand it. And then figuring out fun ways to engage not only that group, but the broader organization in the research process. So we’ve tried a variety of different paths for that, from the typical lunch and learns, to AMAs, ask me anythings, on Slack, to a Family Feud game show with facts about user research.

We had interdisciplinary teams, and everyone competed on their knowledge of our users. So I think that’s maybe where the storytelling and the film have helped and played out in my own strategy for being effective as a researcher.

In Lookback Share insights in short form: put clips from several sessions into a reel that anyone with the link can play. Learn more

Starting with an internal discovery

Henrik Mattsson · 13:32
Wow. So it sounds like transparency is really key. Am I getting that right? And involving everyone from the get-go, basically, even before you’re starting. Because it sounded to me, if I understood you correctly, that what you’re doing is an internal discovery first. It’s not like your team goes out in the world and tries to find what’s wrong with the product. You start internally in the team.

Vanessa Wiegel · 14:00
Yeah. So we start with: what is our existing knowledge? Actually separating knowledge from assumptions, and then figuring out what we need to learn. I always like to begin with any sort of secondary research that we might be able to leverage. And then that’s the foundation for going out and conducting primary research. We don’t want to duplicate efforts that have already happened. We want to leverage the knowledge of our stakeholders. And at minimum, we want to understand what their hypotheses and assumptions are, and then how we leverage that knowledge in any research that we undertake.

In Lookback Record stakeholders' hypotheses and assumptions in a stakeholder interview, and Lookback turns them into research goals. Learn more

How teams react to early stakeholder involvement

Henrik Mattsson · 14:34
I love this. I have so many questions. Because here’s what I hear. Based on everything else that I’ve been hearing from other people who have really had success with getting engagement, I think what you’re doing is you’re attacking this directly. Attacking is the wrong word, but you’re really approaching this from building trust, building engagement, building relationships from day one. That’s a common thread with other research leaders too, that this is a big part of the job. But it’s so interesting that you start right away with that, rather than doing research and then trying to do this as a parallel process.

It sounds to me like your research process almost starts with this. So that’s super interesting. What does that look like in the first, I don’t know what the timeline is, a week or two? What are some of the challenges that you may meet? How do people react to this? Is it: oh, I’ve never been treated like this by a research team before? Or is it: oh, this is great? Or: oh, I don’t understand, I have to be in these meetings? What’s the reaction of the team?

How is this received?

Vanessa Wiegel · 15:49
Yeah, that’s a great question. I think it depends on the team. It depends on the organization. To be clear, we don’t, on day one, get on the calendar and say, here’s what it is, let me understand your needs. But my approach when I enter a new organization is to leverage my key partners, whether it’s in UX design or product management or what have you, to understand the relative maturity of the organization for research. Who are the key people that I need to understand and influence?

Where can we add the most value? And get a sense of the lay of the land, and then utilize that knowledge in whatever strategy I take with those individual stakeholders. But it is jumping into that and beginning the trust building pretty early. I find that when we’ve tried the opposite route, of let’s do some research, try and build credibility that way, and then build a relationship, it’s not as effective as understanding what their needs and anxieties are from the get-go and taking that into account in that first project.

I find that’s more effective. And then they see that value, versus, maybe I would have executed that first study differently had I had a deeper understanding of those hypotheses and assumptions. So I found that to work better. But it is getting the lay of the land, then engaging with those stakeholders and really trying to understand them, and then undertaking that first project.

Why transparency builds trust in research

Henrik Mattsson · 17:27
Interesting. So to me this makes perfect sense, given what I’ve seen in my life. And I could guess a little bit about why this works better. But I’d love for you… You already mentioned that the quality of your first study is improved by actually having done this work first, right? But could you deep dive into some of the other reasons, for people that are just trying this out? Why do you think that this is a better approach? Why do you think it works? What are some of the drivers behind that?

Vanessa Wiegel · 17:59
Yeah. So I think the alternate approach is for you to go out, based on your own knowledge, without working closely with stakeholders, and say, this is a need, let me go about executing this study. And then you’re bringing that data back to them. And I think the challenge is, maybe that would work in your organization if your stakeholders have worked with researchers in the past and have a certain level of familiarity with the process. But I’ve found that there are oftentimes more questions, like: why was this your choice of methodology?

How do we know these are the right people? Because they weren’t part of the process, it’s kind of like this black box of how you got to these insights at the end. And I’ve worked with researchers, and every researcher is a little bit different. Your approach is a little bit different. So I feel like when you start with that relationship building, and you start with that transparency into the process, it builds more trust. Because otherwise people make assumptions about how you came to it, or what that looks like, or how much confidence they can have in the data.

But when you’re engaging them, not only are they seeing that and they have that transparency, but you’re eliciting feedback, so you can be responsive to any concerns along the way and address those. And it really starts to feel like a partnership, versus, let me toss a bunch of data over the fence to you and hope that you receive it with open arms.

When the way work is organized gets in the way

Henrik Mattsson · 19:27
Very wise, I think. Okay. When I’ve talked to other people about the trust building exercise, there are two challenges that people talk about. One is the one that you’re solving with this approach, which is the almost personal trust. This team member works with that team member, trust is built, and a good working relationship for future work is established. That’s one part. The other part is: yes, everyone loves this and that happens, but then the incentive structure of the whole organization and the way that work is organized get in the way of it really blooming out into what it could be.

Have you experienced those kinds of obstacles, and if so, what have you done to overcome them?

Vanessa Wiegel · 20:25
Can you say a little bit more about what you mean when you say work getting in the way of those relationships? Is there an example that you’re thinking of?

Henrik Mattsson · 20:32
Right. Yeah. So you have this approach that starts very early. Let’s say you’re working with developers, or, this depends on how the thing is organized, obviously, but say developers. And they sit in their processes, which are managed by perhaps a product manager or engineering manager or something like that, and they have their sprints or whatever. And then your process comes in, and it’s actually appreciated by the developers on the team, but it doesn’t fit. They don’t have time to go to those meetings, or they’re busy doing something else, or they need to ship.

So sometimes the way that work is organized can get in the way of things that everyone agrees is a better way to work. It’s just not the way it works. So I was just curious if you’ve seen that and what you’ve done about it.

Vanessa Wiegel · 21:21
I’ve definitely seen and experienced that. There have certainly been times where, whether it’s developers or engineers, and the way that the engineering organization is structured, you don’t actually have embedded resources working on product teams. And so there can be that tension of them being pulled in a number of different directions priority-wise. They’re interested in the work, but they just have limited bandwidth. One of the approaches that has worked there is that you take a little bit of a bespoke approach to that first opportunity, or that first study you try and undertake with that partner, and get them bought into the process.

And then they’re the ones who end up advocating to their manager or whoever: we should be working more closely. Is there a way for us to… And I’ve had this happen: how can I carve out more of my time to be focused on this problem, versus supporting generalized needs? I mean, the ultimate solution, and this has again happened, is when we show how effective we can be when we work on product teams and have embedded resources from design and engineering. We’re working together, we are all familiar with the problem, and we just move so much faster.

That oftentimes motivates structural changes within the organization that then pay off. It also depends on the origin story of your organization. When I was at iRobot, my group actually started in the engineering org, so we naturally had a lot of strong connections and understanding there. Product management was a separate organization, and then we were pulled out into a separate product org. But because we had those relationships with engineering, it made it actually quite easy to continue that goodwill and that level of partnership. Versus when you’re in an organization where product has always been separate from engineering, it requires a bit more legwork to understand: what value can product bring?

How do we understand the challenges that our engineering counterparts are facing? And how do we be attentive to that in the way we approach research?

UX research on robotaxis at Motional

Henrik Mattsson · 23:50
So, I have so many questions, I need to prioritize. This is so interesting. You’ve recently moved from iRobot to Motional. And to the extent that you’re free to share and comfortable sharing, it seems like you’ve had a lot of good experiences at iRobot, and I’m assuming that you’re trying to bring this method of working into your new workplace. How is that going? Are you facing the same challenges, or is it something else? Please, if you can share some of that.

Vanessa Wiegel · 24:35
Yeah, yeah. I think there are a lot of similarities between the organizations, in terms of: we’re working in robotics, with strong R&D capabilities, and it’s nascent technology. We’re trying to get it to work technically, but also factor in the human-computer interaction, human-machine interaction components. I think iRobot went on a journey, and it started before I got there, and I was there for part of that as well, of shifting into being more consumer and user focused. And I think Motional is very much on that journey right now.

It’s exciting to be a part of that, and to be able to leverage some prior experience of how to work most effectively with our partners in engineering, for instance, in our current work here at Motional. Not every strategy that worked at iRobot will work at Motional. There’s a uniqueness to the work, and a higher level of complexity, in the fact that we’re working on robotaxis. And the nature of our product development process is even more complex when we factor in that we work with partners like Lyft and Uber, who control, say, the ride hailing app component of that.

We’re designing all of the HMI and technology within the vehicle itself. And then we’re a joint venture with Hyundai, so Hyundai is working to develop the actual vehicle itself and the hardware there. So we have multiple partners that we need to work through. The complexity of our product development process and the level of collaboration is definitely different, and so there are its own challenges and strategies. We’re figuring out how to best work together, how to communicate, how to align on our roadmap together most effectively.

But a lot of the core strategies and things that have worked in the past certainly apply in this context as well.

Henrik Mattsson · 26:42
Yeah. Well, as you’re saying that, it seems pretty clear to me that because every place is different, this approach of starting with an internal discovery is just the right starting step, because these places are different. So you can’t just start with the research and then do…

Vanessa Wiegel · 27:08
It takes a little while to assess where you can add the most value. And there’s so much opportunity. We see so much opportunity to conduct research and inform our processes, and to pull in different types of data: behavioral, attitudinal, et cetera. So you need to give yourself a little bit of leg room, or time, to establish that foundation, to then actually make smart, strategic decisions about where you invest your energy. What are the projects you go after? I mean, some problems are pretty consistently articulated by stakeholders when you join an organization.

But sometimes you just have to experience them for yourself, and you might see different things than they do, coming in with an outsider’s perspective.

Advice for new research leaders: a learning plan and the flywheel

Henrik Mattsson · 27:58
Right. So, unfortunately, we have to start rounding this discussion off. But one last question I have. Could you say something for the people who haven’t experienced this journey yet, but think that this sounds lovely and want to achieve this as research leaders in their places? Can you say something about the time perspectives, and how you manage your, almost, sanity, but how you manage your focus in all of this work that needs to be done? Because this sounds like a journey that’s going to take some time.

There are going to be some ups and downs. You have to do the work, but you also have to do the relationship building. Any advice to people who are just starting this journey? Things to look out for, what it would look like from the inside, and different management strategies there?

Vanessa Wiegel · 28:54
Yeah, I think as researchers we are so eager to show the value, to demonstrate value, that we just want to jump right in. And depending upon the organization, there’s a lot of complexity, a lot of data points to gather and to process. So it definitely is a journey. I’m six months into my new role at Motional, and there are still things that I’m learning every day, whether it’s about the product or the organization. So I think the most important thing is to establish a realistic plan, whether it’s your first 90 days or your first six months, a learning plan.

And just be kind to yourself about what it is you have accomplished. I think it’s good to hold yourself accountable to say: these are my one or two priorities, high-level strategic priorities, this month, and I’m going to focus on them. I mean, I’ve struggled through this myself. There’s so much you want to do, and when you’re just trying to kick the can down the road a little bit on too many things, nothing comes to fruition. So I think it’s been a lot of both discipline and empathy for myself and what I can accomplish.

Just trying to focus efforts, and knowing that it’s a continuing journey. But the good news, and what I’ve seen, is it’s a flywheel. There’s a lot of start. And then you get a bunch of irons in the fire, and it just gets easier and easier and you build up more and more momentum. And you’re building up that trust and the credibility all the way. So the amount of time you need to spend evangelizing or influencing, or trying to articulate why this is the right approach, diminishes over time, which is good.

Henrik Mattsson · 30:53
Awesome. Well, what a perfect place to end: realistic hope. You will get the flywheel going. It’s worth it.

Vanessa Wiegel · 31:03
Yeah, you will get there. Just celebrate the small wins you have along the way and along that journey. And I think few people would claim, I perfected this, there are no issues, it’s perfectly seamless, everything’s working flawlessly. And if you get to that point, then go on to the next opportunity.

Henrik Mattsson · 31:22
Yeah. If it were easy, everyone would do it. Very good, very good. Thank you so much for sharing all of these incredible insights. I’m sure the audience got a lot of value from this. So thank you so much.

Vanessa Wiegel · 31:36
Thank you so much for having me. It’s a pleasure.

Henrik Mattsson · 31:38
Awesome. And for everyone who’s listening and likes this kind of stuff, this is just one of many episodes with interesting research leaders in our industry. There’s also a newsletter, the UX Research Rundown newsletter, that you can subscribe to for more content like this. So until next time, happy researching. And be kind to yourself. As we heard in this podcast, it’s very important. You’ll get there. Take care. Bye bye.