Adapt Your Messaging and Get Buy-In To Create Better Products

Inês Louro, Nadine Piecha, Lorenzo Guadalupi at UXDX Community: Europe South. Video: https://youtu.be/Wna3DFh3ZaU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introductions

[00:00:00] Noemi: Moderated by our co-founder Rory Madden, in this panel we will talk through how, aside from using data and logic, our speakers instigated changes and how they ensured buy-in within their own roles, ultimately also ensuring delivery of their products. So welcome Nadine, Lorenzo and Inês.

[00:00:23] Rory: Thank you Noemi, and welcome everybody. Let's do a very quick run around the group here and do a quick introduction. Hopefully everybody will have seen the amazing talks that our panelists have given. I've seen a lot of activity in the Ask the Speakers channel, and one thing I will flag, because you've probably noticed, the chat box unfortunately isn't working, we're having some technical difficulties on the website. But the Ask the Speakers channel in Slack is available, so if you do ask any questions in there we will read them through to the speakers. So apologies for that, and that's what you get for doing a last minute upgrade of your website yesterday without testing the chat function. So apologies for that.

[00:01:10] Rory: But aside from that, let's get into our topic today, which is about adapting your message to get buy-in. And this is really important to me because so many times people are always saying that they've got some great ideas for either their product or ways of working and things like that, but they really struggle to get either their team or managers or other stakeholders to buy in and adopt those new ideas. So let's introduce our panel. Inês, can you introduce yourself please?

[00:01:38] Inês: Sure. I hope you can hear me. Hi everyone, I'm Inês, I'm based in Lisbon, Portugal. I'm a design lead at Pipedrive, which is a CRM focused on salespeople and sales processes. And I think that's it for me.

[00:02:03] Nadine: Hello everyone. Yeah, my name is Nadine and I'm based in Barcelona in Spain at the moment, working for a company that's actually operating in South America called Beat. And before that I've been working in B2B, in B2C, different sizes of companies, and always as a UX researcher.

[00:02:25] Rory: Excellent. And last but not least, Lorenzo.

[00:02:28] Lorenzo: Hello, I'm Lorenzo, nice to meet you. I'm an interaction designer, I'm currently working in Rome for a company called Sketchin, which is a design studio, so we have many different clients. And in my experience I work with different stakeholders, with different kinds of clients, that help me in a way to build my own way through design, interaction design especially.

Who are you trying to get buy-in from?

[00:02:51] Rory: Excellent, so that's a great segue into my first question. Lorenzo, I'll direct it at you. When I say getting buy-in, who are you trying to get buy-in from? Who are you trying to sell different things to?

[00:03:06] Lorenzo: Yeah, being in a design studio we work with stakeholders which are outside of my company mostly, and therefore what we want to do is to convince clients in these cases, to convince them firstly that we are the right persons for them, that we are the persons and the designers they want for their projects, to solve their issues. So essentially they mostly come to us having a certain problem and we have to show somehow that we are better than the others to solve that problem. So we really have to focus on our strengths and to point them out according to the client, to the stakeholders. We have to adapt in these situations. But that's also the everyday process that happens also during the project itself, so it's not just in the beginning but also during the project, because you have to, let's say, convince them that while you are working with them you are bringing value to them.

[00:04:01] Rory: Great, and is there any difference really there between, like, you said adapt, but is there anything that you would do differently? Because I guess up front, if you're trying to convince a client, you don't have the methodology and all your steps along the way. So what would you do differently?

[00:04:19] Lorenzo: Yeah, first of all you have to have a base, which is your own way, because that's what makes you in a way special. So if you have your methodology you have to push that and show how that can help them. So if you work in a certain way with, I don't know, streams, or how you would work with the stakeholder and all these things, you have to push on that, because you show your methodology, how they can benefit from that. And depending on the client, you may have worked with similar clients, so you show maybe a showcase of projects you did, similar, or to solve similar situations. So you say, hey, I actually had this problem before with another client or with someone else and we solved it and we helped him to reach this. So in a way you show how you brought someone from a point, from A to B to C, which is very good because they can relate, they can think, oh great, that's what I need, that's where I want to go. Of course in the very beginning you have not all the cards, you didn't do research, so you don't know much about the problem, about what they told you, so you are just guessing. But that's what they expect from you, I guess.

[00:05:29] Rory: And how is that different from when you're convincing them while working on the project?

[00:05:34] Lorenzo: That's much more specific. In the very beginning you can stay broad, you can even not be super realistic in what you say, you just have to show what's your focus direction or what's your aim. But during the daily reviews in this kind of situation you really have to be to the ground and very specific to the problem. So you have to show them why designing that screen or that part in that way is better than the other, and maybe you can prove it to them by doing both of them, or trying a couple of solutions, so they can actually see with their eyes that it is actually a better one than the other. As an interaction designer you always use prototypes to do these things, because they help storytelling and to tell your story essentially.

[00:06:26] Rory: Brilliant. I'll dig into a little bit more detail on those, but I just want to ask the same question, so just to recap it: who are you trying to get buy-in from? And I'll ask Inês.

[00:06:36] Inês: Sure, okay. It's a great question. I think we can approach the two sides here. We can start with, first, the users. Of course we have our users, when we're building a product we want to get their buy-in, we want to give them a voice and to feel valued, and we want to make sure that we're building a good experience, which is going to cause all sorts of positive things, but definitely not the frustration. And it's going to be trust in the product. But we also have internal stakeholders, right? We have our team. So as designers, a lot of times we have to discuss and sell our ideas as designers to others. So the team you work closely with, like engineering, the product managers.

[00:07:38] Rory: Excellent. Great, so we've got already a different kind of more client selling, and stakeholders, and more of the team and the users. So Nadine, which way do you lean in here, who are you trying to get buy-in from?

[00:07:51] Nadine: Probably mostly the team. I would add maybe management, to get buy-in for more resources or for more tooling or those things, but how I get this buy-in actually is by getting buy-in from the teams. Similarly to what Inês just mentioned, buy-in from designers, buy-in from POs, to spend time, to spend effort to listen to customers and build solutions that will actually add value to your users ultimately.

[00:08:18] Rory: Right, so just to clarify, because you're coming from the UX research side of things, where does UX research, are you in that team that you're trying to convince, or where do you sit?

[00:08:29] Nadine: Yeah, good question. In my case I'm not part of one team. Most likely I'm one of the first researchers joining, that has been my past experience, and then I'm kind of in charge of all the product teams that are there. So I'm very closely in contact with the PMs, with designers, with engineers of various different teams, and trying to help them solve their problems or their needs with involving users. So I'm kind of outside of that team, trying to involve them in user research or convince them of listening to users and taking user needs into account when building products.

[00:09:13] Rory: Great, so it's kind of UX as a service or something, to the teams?

[00:09:21] Nadine: You could say it as a service. I don't really see myself as a service. It's not that they request, I do on my own and then I come back and say, here's the service I delivered for you. But I really see them as partners, as colleagues, and I really want to do things together and closely collaborate with teams. The challenge is, as you frame it, the challenge is that I work with several teams and I'm like a central resource in many instances, until the research team starts growing and we might have in the future an opportunity to have researchers more closely collaborating with the specific teams, or even researchers integrated into every team.

The challenges: research takes time and resources

[00:09:59] Rory: Great, so we've kind of touched on there who different people are getting buy-in from, and there's actually a broad range there, which is great. I'm going to touch on your challenges now. So you mentioned there, as you were going through it, that it's kind of convincing the team to invest the time, invest the effort. How does that go, what challenges do you face?

[00:10:21] Nadine: Yeah, the challenges that we have to overcome are mostly related to, research takes time, and research takes resources, it's expensive. So those are like the headwinds you might face when you start implementing more research processes. So those are the discussions I have. Research takes time, it's true, good research, intensive research takes time, and to find out all the details takes time.

[00:10:48] Nadine: If I come across that situation that stakeholders have their objections regarding time, I try to find quick and dirty approaches. There's, to almost everything, there's like the perfect solution and there's a quick and dirty approach, and you can get some insights in a very fast way. I'll try to tell them, don't wait for me, don't stop anything that's already ongoing or that you're working on, there's no need to pause and wait until I come back with research results. But there's a lot more than what most people would expect that you can do in one, two, three days of research. And once they see what I bring back in one, two, three days of research, and once they see the insights, they realize like, okay, actually it is useful, and it might change, and it might help us save time and save resources or save money of developing something that in the end wouldn't work.

[00:11:40] Rory: Great, I like that, the kind of guerrilla research type: just get something out there, demonstrate, and grow from there. Well, that's nice. Inês, you also mentioned kind of convincing the team from a design perspective. Is there any other challenges or differences there that you see?

[00:11:58] Inês: Yes, of course there's always a challenging environment, or you know it should be somewhat. But some of the challenges in getting that buy-in from the team, so more specifically the process with the product managers and the engineers, is if we don't share the same understanding of what the problem is and therefore what the solution could be. So in this specific, or even if you don't bring research or data to support your decision. So these are aspects that we could be working on as designers.

[00:12:40] Inês: And even when it comes to involving more roles, more of your colleagues, into the decisions and ideation, that really helps, because if you're lucky enough to work with an engineering team who's also very keen on getting a good UX in the product, they will have answers, they will question things, and that's good. So a challenge could be that you have one or two team members that, if they don't understand why we're doing it the way we are, that could become a challenge.

[00:13:19] Rory: Okay, so you mentioned kind of involving people. Do you get pushback on that, like do you ever get people saying, look, just leave me out of it, tell me what you want me to do?

[00:13:33] Inês: Actually I think this can vary of course from person to person. In my closest radius that doesn't tend to happen. Actually it's the opposite. So other teams, like engineering, they're very interested in watching a recording of a usability test for example, or participating in design sprints. They really like that, working as a team and being part of even the sketching. So they're not afraid of it, they embrace that. So that's nice. But I can understand that it's not all the individuals of the organizations.

[00:14:18] Rory: Okay, that sounds fantastic, I'm loving that. But one question I have is just around, because you mentioned alignment there, or shared understanding is what you said. Even if there's kind of people coming in and out of different kinds of research, even just biases and backgrounds, people will end up with a slightly different understanding of the same thing. How do you manage that?

[00:14:45] Inês: Okay, that's a good question. It's something that has kind of been part of our tribe, so to say, we call it tribe here in Lisbon, in our mission process, our project process. At the start we make sure that there is, could be a design sprint, could be a workshop, but we are going to focus on that alignment. So all together again, design, PM, engineering, we put the deck together, we present the facts, the research we have, qualitative, quantitative, and everyone hears it and has a chance to ask questions the same way.

Overcoming challenges with clients

[00:15:27] Rory: Great, that sounds fantastic. So we'll move on to Lorenzo. So you mentioned, I guess if you're convincing somebody on the sales side of things you either get the gig or you don't, so I'm more interested probably in, once you're working with the clients, what happens when challenges arise, and how do you overcome those challenges around getting buy-in?

[00:15:52] Lorenzo: Yeah, they always arise, like there is no way, you can limit those challenges. So you can try to have some boundaries, because at the very beginning it's important that you have a solid base of the research. That's really helpful to, you say, to trace a common direction. So that's the very first part, so you know where your team is going, also the clients of course, and that helps in further discussion. But they will always arise. And depending on the people you are talking to, there may be some, I also like when there is a debate, because it means that people are really engaged in these things and they really care, that's a nice thing.

[00:16:34] Lorenzo: And of course, when you have some cards in your deck that you can play, which one is the research you have done before, like the opinion of the user. So if you are convinced that the solution you need is good, but not because you think it's good but because you have solid bases to prove that it's good, then you have to present it as good as you can by adding the whole research part that you did. So it's very difficult as a designer to not have a favorite idea that you designed, that you made or something. It's very difficult to detach from your personal opinion, let's say. But it's kind of the role of designers to be as detached as we can. So we have to make the research our main card.

[00:17:25] Lorenzo: So everything that the other speakers said about the whole qualitative and quantitative, the user testing, the interviews you may have done, and all these things, they are gonna be your cards whenever you have a discussion with the client. So whenever there is a rebuttal[?] or something, a debate about something, you can use those things to say, you know, this is actually in the direction we were saying before, so maybe this is the good way or the right way. Because there is not just one right way, that's the other problem, there is not one way to do things, there are thousands probably, but it's more about being coherent and being all together working in the same direction.

[00:18:07] Lorenzo: And when you come up with a stakeholder who says, I hear you that you want this way, I want this way, the last word usually is on the client. What you can do is to push it as far as you can. You can even run A/B testing in some cases, if you're really convinced that your idea, which is not your idea because it's yours but because it's your idea that you built on the research, on all the parts that you did before, is a good one. You can say, okay, you know what, we're gonna go with this way but we're also trying to show you how we think is actually the best solution. It depends also on if you have time, how much energy you can spend on the particular person, it really depends on the project. But it's nice when you do the A/B testing and eventually that proves that you were right, that's quite a satisfaction.

[00:18:58] Rory: Always the risk of being wrong as well.

[00:19:00] Lorenzo: Yes.

Audience question: who becomes your UX champion?

[00:19:02] Rory: I've just seen a question coming from the audience. Gary asks, in terms of selling the ROI of UX, is there someone who is usually a starting point in your relationship building? Are there any signals that indicate this person is going to be a UX champion?

[00:19:16] Lorenzo: The client? So the client is going to be, or so, like someone, one of the stakeholders is going to be a UX champion?

[00:19:26] Rory: So the question is about, where do you start when you're trying to sell the value of UX? So who do you try to seek out, and what are your chances that they'll actually, because you might tell somebody and they have no interest?

[00:19:41] Lorenzo: Yes, sure, that's a very good question, and it's very important to show the value of what you're doing, not just the designing part but also the whole process. So like by saying, you know, I'm gonna run interviews, you have to show the value of these things, because you may have to convince them that interviews are good. And so it's not just convincing them that your design is good, but also that the methodology, the approach and the different kinds of tools you are going to use, they are beneficial for them, and what kind of benefits they can bring to them. And that works. Usually what we do is trying to bring examples, cases, or past projects where something worked out very well and that thing really was helpful in some way.

[00:20:28] Rory: That answered the question, but I might actually ping it to Nadine, because you mentioned you're usually the UX of one as you enter a company, so you have to convince people of the ROI of UX and why they should invest in it. So you've kind of touched on before the doing the quick and dirty, but is there a particular person or people that you seek out to help champion UX with you?

[00:20:56] Nadine: Yeah, I touch on that also in the talk that is shared. I think it's very important for me as a researcher, not just waiting for requests for research to come in but actually proactively pick a project where I believe I can show the impact of UX research. And one of the things to take into account is choosing a project where I can collaborate with the champion, as the audience said in the question. So I'm trying to figure out who already knows a little bit about research or who really wants research. If a company hires me it means there's someone that believes in it, so it's probably a good bet to collaborate with those people that already know the impact that research can have, because then my chances are better that with whatever I find, people act on the insights and we can ultimately show the good A/B test results that Lorenzo just mentioned. Whereas if I work with someone that doesn't believe in research, I'll have a hard time convincing them, changing something or building a product that an A/B test will go well.

[00:22:03] Rory: Inês, do you have anything to add on that, or has it been covered?

[00:22:10] Inês: Yeah, everything's covered. I mean, the cost, I think it's very logical that the cost of not doing this could be quite high. So yeah, I think what other speakers have said, I support that.

Making sure you're listening, not just pushing your own agenda

[00:22:25] Rory: So I'm just going to touch on what Lorenzo said there a second ago. It can be very difficult to detach yourself from your ideas and your design. We all say that, oh, I'm basing this on the research, but we're all biased ourselves, so we're going to pick a solution that is kind of more appealing to us. So how do you make sure, when we're talking about getting buy-in, that you're actually listening to others, to make sure that you're not just pushing your own agenda but you're trying to get the best outcome? And Inês, I might continue with you since you're still here.

[00:23:02] Inês: Sure, sure. So Rory, was the question, how do we make sure that we're listening?

[00:23:08] Rory: Yeah, so it's not just, we talk about getting buy-in, it's not just all about I need to get my way the whole time, right? So how do you make sure you're listening, to make sure, because you might be wrong?

[00:23:18] Inês: This is a good question. Actually, one of our competencies as designers is adapting to change. So it is expected to have this competency, to incorporate changes into our work. So no one expects to have a brilliant idea from day one. Actually that sounds scary even, right? Probably we're not doing it right.

[00:23:46] Inês: So again, there's two sides here. So from the users, we can make sure that we do hear them by analyzing the different fronts that they use, or that we use, to be in touch. So it could come from customer support, so we can work with our customer support teams, with sales, and of course we can create more exploratory interviews, so make sure we're listening to the users.

[00:24:21] Inês: And when it comes to teams, we also have to make space for this to happen. So in my talk I talked about the critique, so that's one way to hear more perspectives, more ideas, hear other facts. Because what ends up happening sometimes is that we're focused on one part of the product for quite a long time, so it's quite important to hear from, the same users are using other parts, so again, involve more people. Make sure for example with engineering teams, don't wait too long. So if you're working on a project, asking their opinion. Like me personally, when we have dailies, I like to be the last one to present, because I know I might have something to show I'd like feedback on, so I make sure that we hear it. Yeah, I think that's how it goes.

[00:25:19] Rory: And how do you deal with it when somebody has some crazy feedback, where it's kind of, don't like this at all, I think we need to go the complete opposite direction? How do you make sure that, because there's a natural reaction to be defensive of your work, so how do you deal with something like that?

[00:25:40] Inês: There's a lot of discussion normally. It's good having a discussion, justifying why you did what you did, and the other person, you know, but I don't think so because, you know, it happens, it should happen. So I don't take it personally, so I don't think we should take it personally. Again, we should keep the goal in mind of what we're doing, and the user, and always try to fundament with reason, basically using reasoning.

[00:26:10] Inês: But I would say that one thing that we should be paying attention to is when we're not making a decision, because a discussion can last a very long time. So I would say in that situation it's important that, if it's a design decision, it's a product decision, of course we're going to take everything into account, including technical constraints or other ways of doing it, but eventually we're going to have to make a decision, and we can test it and put it out there, test with users, and we're going to get more insights.

[00:26:49] Rory: Great, excellent. I'll give the same question to Nadine, about making sure that you're listening to others so you're not just pushing your own agenda.

[00:27:00] Nadine: Yeah, a good question. About pushing my own agenda, I'd be lying if I'd say I'm not an opinionated person when it comes to copy or design, and all the designers and UX writers that work with me would confirm. But in theory it's not my job to have an opinion on solutions, on how we should approach things, or to make decisions. It's my job to pass on the opinions, the feelings, the thinking from users, right? So my job is done when I achieve that everyone else feels empathy for the users and can take the users' opinion and thinking into account when making their decisions.

[00:27:37] Nadine: And by that, maybe one more important thing to mention, by that I don't mean that we take the users' opinions or the users' suggested solutions and build them. Obviously the user opinions or the user thinking and user input is just one aspect of the decision making, and then, just as Inês just mentioned, it's technology that we need to take into account, it's business needs that we need to take into account. And then usually it's someone else that has to take the decision, and I'll deliver some input from the user perspective to that.

How have you adapted over your career?

[00:28:13] Rory: Excellent, that's a great way of thinking about it, kind of being the voice. And on that, I'm just going to ask people to share how you've adapted over time, because this is something that I know personally I have changed in my approach to how I've sought to get buy-in. So Lorenzo, I might ask you first: how have you adapted in your approach to getting buy-in over your career?

[00:28:38] Lorenzo: Yeah, well, thank you for the question, because it's an interesting thing to think back and see how you changed. I think what I noticed is how I was a bit, I say in a way messy, like I was trying to hurry, trying to reach the final result as soon as possible. So I wanted that thing and I was skipping steps, and sometimes it was parts of the research, sometimes it was something else, and I was trying to, so I started with something in mind and I was trying to continue with that idea straight until I reached it. So trying to be in a way frenetic to reach the very goal.

[00:29:22] Lorenzo: By the time I learned that actually that process just makes it longer, because you reach a point where you have to go back, because it took you little time to get there but it may be wrong on certain aspects, you may be thinking something wrong, so you have to go back. So what I changed is essentially the methodologies. I like now to give time to specific milestones in approaches. You cannot skip them, you have to have them, and it's very important that they have to be there.

[00:29:50] Rory: Excellent, a bit more rigor and structure. Inês, what are your thoughts on the same question of how have you adapted over time?

[00:29:58] Inês: Yes, it's a good question again. I would have to go with, as a designer, especially in the beginning we are a bit, I'm not sure if it's scared, but I definitely learned to show things early. And I think that helps with the buy-in as well, definitely, because the team is not evaluating the pixel perfect or the final designs, as I thought, like that was proving my work, I'm proving myself here. Not really, not at all. So what the team, the stakeholders value is definitely the process and why we're doing what we're doing and how we're doing it, and it's the whole thinking behind it. So yeah, definitely I don't wait not even a minute more to show something to the team.

[00:30:52] Rory: Yeah, right, yeah, it's always daunting when you have something that you know isn't right and doesn't work right yet, but trying to show it off is definitely useful in my opinion as well. And Nadine, same question to you, how have you adapted over time and in your career of trying to get buy-in?

[00:31:13] Nadine: Yeah, thinking backwards, I feel like I had to learn that there's no one size fits all. After my first years and in the first job, at the end I felt like, now I know how UX research works and how it's done and how it should be structured in an organization. And every time I moved to a new company I had to realize, like, no, it is completely different and what they need is completely different and I had to adjust. And then yet again I moved to a new company that is way bigger, or that is way smaller, or that already has researchers there that are just not UX researchers but focusing on other areas. So there's really not that one solution and you cannot go by the book, but you have to adjust to the situation that you're finding. And that's how you also earn trust and get buy-in.

[00:32:00] Nadine: And the other thing is, pick your battles. The younger myself would have tried to choose every battle and try to be involved in every project and help wherever I can, and now I'd say, like, let's find the project where I think I will really make a difference, I will have an impact, I will see outcomes or results at the end, and focus on those ones and not on every project.

[00:32:22] Rory: Excellent. Now, that's some fantastic advice from everybody. We're out of time. I would love to keep chatting, because there's just so much there on the different types, when we say getting buy-in it was clients, senior stakeholders, teams, users, and just kind of everybody around the organization. So there's so many different people and different strategies then that we talked about of how to get buy-in. And I like the way to finish off: don't get too invested in everything, pick the right battles and figure out which ones you need to work on and convince. So with that, I'd like to thank Lorenzo, Inês and Nadine for their time, and I will hand back to Noemi.