Q&A transcript

Name: Live Q&A: Reading the room: Strategic research for designers
Start: 2025-11-19T12:00:00.000Z
End: 2025-11-19T12:00:00.000Z
Location: Online

Question

Q&A transcript

Accepted Answer

There we go. Let's see. Hello everybody. I think we got eight people here. Welcome. Hopefully you can hear us, see us, see my screen. I'm Joe, we got Frankie up there, at least on my screen. Frankie's up there. Welcome everybody.

Let's get started. I'm Joe. I'm going to be the host today. My bio doesn't really matter, but I'm the design advocate here at Lyssna and for these Q and A sessions, I bring on and prepare some questions and some topics with people like Frankie, who have some great stories, experience, and things to share today. All about reading the room, research, and, the communication aspects. So this series, our Q and A is at Lyssna, they're all about hearing from practitioners.

Frankie is definitely a practitioner of a lot of different areas of UX design and research and with a lot of experience in each of those areas, and depending on what the topic is or who we're bringing on. It's about hearing about the day-to-day work, team structure, things that they're doing in their day-to-day work, career journeys, lessons learned.

I think we got a couple of those today. Definitely some that I'll chime in with and, real stories and insights from real projects to get a little glimpse and pull some insights of your own from the stuff Frankie's working on.

Also to give you some takeaways to bring into your own work. And this is something that we want to focus on a little more today, and I'll give you some of those at the end.

In addition to all the interesting stuff that Frankie's going to share. want to make sure you guys leave here with some tangible takeaways, some action items, some things that you can apply. To the stuff that you're working on based on everything that we'll go through. So we are going to take questions in a little bit.

We're going to go through a few intros and a couple questions I had prepped, but you can ask a question at any time in the chat. So if one comes up for you or if you have a follow-up question to something that we're discussing, drop it in there. And after we go through our couple questions, I'll check those ones out that are already in the chat and I'll give you guys another couple minutes to write some questions in for Frankie to answer live.

So anytime you have a question, don't lose it. Drop it in the chat, even if it's a quick shorthand note reminder and we'll make sure we get to it. Alright, so Frankie, let me turn it over to you. Welcome.

Thanks, Joe. Super excited to be here. Honestly, can't wait to get into this convo. But yeah, sure. So a quick background on myself. Can see it from my bio, but I'll save you from reading. I'm a UX designer, a senior UX designer and a content creator, specifically educational content for the UX product design space. So no TikTok videos, sorry to disappoint. But basically I've been in the industry for a, many years now it feels like. But I love it. Just doing a mix of product design, UX design. We can kinda get into some of that as well. But yeah, that's my short spiel, just short and sweet. Love to share tips and tricks and help all of you break into the industry and share what I know.

Cool. So Frankie, let's start out with reading the room. That's the the title for our Q and A here. So just give us a little context before we get into some of the more specific questions about what you mean by that and how it relates to the stuff you're doing as a product designer researcher.

Sure, totally. I think it's a great question and I want to define ready the room in two ways. So I'm going to break this down separately in two sections of this. As many of as practitioners yourselves, I'm assuming there's kinda two pieces to being inside the kind of design discussions.

There's the part about the prep for the design meetings, thinking about how do you really share out your insights, understanding how do your stakeholders best resonate with your information. Are they visual? Are they data centered? What is it? Because we're all, we all lean a certain way, so understanding how they're going to react the best so that you can come prepped with that in mind.

So that basically, even though you're not in the room at that moment, you're still reading the room by reading how your stakeholders will react and preparing for that. The other side of it is more physically being in the room. Even if you're like me and you're virtual most of the time you're still physically in that room.

And that's more around thinking through what you're actually hearing them say. So you're probably all used to this. Someone will say, make it pop. The dreaded term we all hate. What the hell does that mean? Excuse my language, but what does that mean? And it's one of the things where it's thinking through how do you break that down to truly understand what they're actually telling you so that you can actually under say okay, even though they say this.

What they really want is this, and this. And you can make it more tangible and then turn that, those insights and that feedback into your designs and the research that you explained to them. So that's really what it comes down to, is just a, being prepared in a better way and b, really just deciphering what you're being told.

Awesome. That's I'm glad you broke it down in the two parter like that. 'cause a lot of times, I mean we, I spend so much time I get a lot of questions about re presenting research and design to stakeholders, to teams, how to tailor it all the stuff you mentioned, I guess in part one of that.

But that also involves a part that I think I probably gloss over too much when I'm talking about it, which is like tuning into how they want it, not just about recrafting research findings from a usability study you did. Or a bad term, but dumbing it down for a different audience, but not just simplifying it or making it more complex, but actually understanding like what resonates with them, how they learn, how, what has an impact with the people that you're working with that's go and how it's presented.

That's going to turn it into. Something that gains some steam and actually works its way into your project. I like it. I'll steal that.

Thanks. Go for it.

Awesome. So next one, pushing back on stakeholder requests. Good lead in from the last one. With stakeholders in terms of whether it's a design decision or some other kind of from left field request, we get maybe things that are handed to us, or asked of us to create as a product designer. And as you, Frankie, and probably many others here, know, sometimes that doesn't line up with what we're seeing in research or our priorities. So I guess when you have that research or some kind of evidence to back it up and you're getting, you have that conflict where there's a stakeholder telling you to build this thing or prioritize this and it doesn't really align that can be a tough situation and can be a place where you want to maybe push back a little bit. Tell a little bit about that. How do you decide if it's worth the pushback? What does that look like and how do you make, how do you do it effectively, let's say?

Totally. No, it's a huge question and it's something that I personally don't think you can just learn by reading a book or going to a program. You just have to learn on the job. But I think for me, short answer. I always push back. That's just who I am as a person. And what I've learned over my career is I, as myself would rather, like for me, I would rather know that I pushed back in a respectful manner.

And I'll get into that in a second. But I would rather know that like I actually did my due diligence and I did my job of pushing back and standing up for the end users because that's what we do if we really think about it. And I would rather know that I did that than just walk away and just let the battle disappear.

But I think to your point, sorry. There is a big piece of like, when do you really go to the hill and stand on it and crack down on it? When do you figure out of this is worth really pushing back on, or when is it you say your piece once and you back off instantly? For me, it's taken practice, it's taken experience to understand like what are those instances.

But I think it really comes down to the scope and the how large of it a of piece it is that really is going to come what you're pushing back for. For example, if it's something like they want to make the button bright pink, I don't know, random. Yeah. It's not going to fit your design system, it won't fit your brand guides, but at the end of the day, is it really going to hurt the experience?

Probably not. Whereas something else where you're, it's more around increasing in, or de, sorry, breaking up the flow and actually hurting the experience there. So if they decide, you know what? I want to add in this fun loader spinner that every time you click a button you get a crazy animation that's not a great experience.

More often than not, every scenario is different. But if it gets to a point where you're actually going to hurt your end goal, then what's the point? And for me, that's the time where I'm like, you know what? Let's push back and explain through research, not my own opinion through research, through other things I can find online to say, Hey, maybe we don't do this.

And explain from the user's standpoint as like as to why this won't be a good idea. So for me, it's really thinking through how big of an impact it's going to make as to if I stand up and really hold my ground to push back in that case.

Do you have any tips for. That's great. I know that for me, and just by the way you're describing it, like earlier in my career when I would have those moments where I was like, I know this isn't like I've tested this and that's not aligned, but I'm getting asked to do it.

I would feel like, hesitant or not confident enough really to push back with that and, or I feel like it was like, oh, I could just go along with it and I have that conflict. If anyone else here has felt like that, I'm sure let me know in the chat because it took, it definitely took me a while to like gain that confidence. I have one or two things I'd mention, but do you have any tips for okay, so you have the evidence, you are saying, we tested this and it's pointing us in this direction. You have a stakeholder saying we want to do this instead. Just for actually like having that conversation or presenting that.

I don't know. Any things that have helped you do that or make it land, more, more effectively with them?

Yeah, there's a couple of things. I think number one, the biggest is like. Make sure when you're giving that evidence and when you're explaining a reason for why this isn't going to work, okay, giving the pushback, make sure it's not coming from oh, but I think this, but I that because ultimately you're going to lose it doesn't matter what you say after the word I. Yeah. That, because then it's just opinion versus opinion, and that's useless at that point. So as long as you can come back from and saying, you know what, from the research.

From the end users, from whoever it is that you're talking about to make it not come from you. I do find that helps. It's not perfect. It doesn't go always. Like it doesn't win always, but it does get you a lot further. That's number one. Sorry. No, go for it. Number two is kinda what I was saying before about reading the room is thinking about how is it to, in order to figure out how to resonate with them the best, think about what is, how does their brain work?

Are they visual, are they not? And I don't mean to repeat, but it's coming back to that of how do you give them something on front and center and say, here you go, this is what I'm presenting, knowing it's going to stick with them. So again, like it goes back to if they're super visual and you know they're going to ask a lot of questions about it, try and mock up the three versions that you think they're going to ask.

That way you say, oh, you asked me, here you go. It provides confidence for you in the meeting, number one and number two. It also shows that you're listening to them and that it's going to create a better relationship at the end of the day with them. Sounds kinda repetitive to number one, like I said, but I generally think those two things are like huge impact.

Yeah, said. I think the fir, the first part of that, that, that was like a switch for me when I was like, if I take myself out. Stephanie said it in the chat where I remember having one conversation like this where I was like, I don't care whose idea it like, and it lowered the, I remember it was a kind of project where there was always like something in these meetings. And like taking myself out and being like, we're all pulling in the same direction. It's actually a relief where it's like you take out the, my idea versus your idea and set a standard of we're, we all have to come to the table with evidence, we have a standard now, if we do that, we're going to be in these meetings as probably every single one of us has here for hours without any decisions being made. So like taking yourself completely out of it and being like, I don't care. Or phrasing it like that users feel instead of, I think and in terms of tailoring the way that you're present or like knowing how their brain works on that same project, I won't share much more about it, but it was a long time ago. But on that same project I remember sharing things about an onboarding flow and we had all of these all this research that said we, it wasn't right. But I had a couple video clips of users testing it out and they just like the face they made the things that they said, or were like, wait, what?

I clipped those and shared those with the client was like, they can't finish. Like they can't, they're onboarding, they just downloaded this app and they can't get here and that for whatever reason. Was more impactful than like any other, results that I could show them. Which I think for me too.

Sorry, I didn't mean to cut you off there, but I think it comes also back to the game of telephone sometimes.

Yeah. It sounds so simple, but if we bring in Henry again, we think about these like games we played as a kid. Telephone is, I don't know about all of you. I played that a bunch, but you go through the game of you say one thing and it gets passed down more and more. And the more it gets passed down, no one knows what's being said anymore.

It becomes a completely different thing. And I think that's the other thing here is if people can hear it directly from wherever you're getting the research from, for example, depending on who your users are, then I think that helps and goes a long way as well. Because then it's again, not the I voice, it's the, I heard it directly from whoever the user is.

Totally. Let's let's go to our next question here. By the way, just a reminder for everyone. I will give you guys some time to drop some questions in the chat. We're going to get, we got two more I think, but then we'll get to those. But if you have questions on the way, put 'em in the chat. I'll throw 'em in the Q and A tab and we'll sort through those and answer 'em in a little bit.

Okay, next question. This is this is a thing that has. I think always been like top of the list in advice for how do I get buy-in for research? How do I get my team, my company, my stakeholders, more like. Bought into the impact of research and the value of it. At the top of that list, you're always seeing stuff like get get your, get a crew bought in, right?

Find some other people maybe in different departments and bring them into the process. And this is something I've heard even more lately, like getting allies, for research and kind of building, not in a formal way, but those people who are now brought into the process and seeing it go from, research into like actual product improvements and good design decisions.

So let's talk a little bit about that, Frankie, what who do you bring in to the research process and I don't know if you can share some examples of how you've done it or how you've got the ball rolling on getting that, a team of people bought into research around you.

Sure. No, I agree with you.

I think this is such an important question and. I feel like I keep repeating myself, so I apologize, but there's such a big theme here and like we'll see it as I get into this question, but it all comes down to exactly, it's like making sure you have the right people at the right time and the lack of, again, of telephone.

But to answer your actual question of who do you bring in and when, I think the more people you can bring in, the better. Short and sweet that if you could have your full product team more involved from the beginning side of the research, I think it goes a much longer way, because then again, it's the, it's not the I versus.

Like me versus them. It's the, here's the research, this is, I'm just repeating it to you. They're hearing it directly. I also think that it gives a better idea of what's at play and what could be in scope and like any other ideas that we could add in that they can hear as well directly from them.

So again, we're hearing more, not just what we're looking for, we've all probably done research. If not, I'm sure a lot of us have, and you get the answers you want, but you also get a lot more you can hear a lot of new insights. And so I think also even more so that's great to have your product team there so that they could also be like, Ooh, that's an interesting idea.

Let me pull it in so that it's not them coming up with some random ideas. It's actually then also pulling in more scope from the end user. So for me. Yeah, I would say is like the BA's, the stakeholders, the designers and the researchers are like the golden group in my opinion. I am curious to throw a question to you if I can do that, Joe?

Yeah, because, and like I'll say my opinion as well, obviously, but I also would potentially add in like the engineers or developers Yeah. In that bunch as well. Because I think it's. Again, like if they can get a better insight as to just the context of what they're building, I think, and to do that early too.

I think that also helps out a lot so that by the time they get to building, they have more insights. Whether it's understanding why we did something, whether it's insights also for them to just get an idea of the flow so that if there's, loop. If there's holes in it or whatever it is, they can bring it up early as well.

But the reason I said, let me bring question is I'm curious if you agree to agree with me on that as well.

Yeah, I do agree. I, you said the, the main word that you said is just give them the context. I've found what, whatever role, whether it's, developers, engineering, like marketing people are some somehow involved in it.

I found that it's not about in terms of bringing, like getting people bought in and just in on research driven or like research driven design decisions. It's a lot more about for me, in most projects, keeping them in the loop, right? Where it's not like you're, I've gone to developers with hey, here and unloaded a research study or every single piece of, feedback that we got on a usability test or sharing that with a founder that I'm working for that's doing 6 billion other things. Starting early and like little context 'cause re if you jump into research that's already rolling, whatever it is. Yeah. You can't like digest it. Especially if you're in a different role. So I've always leaned towards keeping them in the loop whatever the role is and whatever the project, but more so about like frequency and Hey, here are some things that we're hearing.

So then when it comes time to like maybe address that in a couple months, it's not it's not a shock. They understand where it came from. Oh yeah. Joe said that we had, this was on our radar as something we were going to see if we wanted in terms of feedback we were getting. So I do agree and I think regardless of the role that you're, of the person that you're bringing in, I found that that frequency and just context and even if it's in the back of their mind, goes a long way when it's then time to put that into action and see, like actually go through the feedback and build a new feature based on it.

Yeah, a hundred percent.

Sweet. Let's see. We got translating and presenting research to different audiences like like Henry. So for this one can you share an example of like where you.

When you've maybe taken the same feedback or findings from research and presented it to different ways or like how you go about that. And what maybe more importantly, what's worked for you when you take a pile of research findings and then have to communicate it in a couple different ways to different people.

Yeah, sure. So I'm going to, before I actually get into breaking down like the two different ways, let me give you a, an example or a scenario. So there was a project where there was a just table of information and my, and the design assumption, not mine. I should take again what we've been saying, the design assumption and what we've we're learning, what we expected was that the end user would want kind of everything front and center in this table as much data as possible so that they didn't actually have to click anywhere, but it was more around, let me just see it without having to add and clicks and, load time. And when we did research, we ultimately realized we were, that it was actually anything happened was they were overwhelmed by the data. It made them just spend more time reading everything. It really just didn't help at all. And so if I then had to translate that into both to the stakeholder's perspective and then like a designer's perspective, so I'll start with stakeholders.

I would say something along the lines of, to that team we did the research. We realized that what ended up happening was the end users was actually just completely overwhelmed. It honestly wasted more time for them to see the data front and center. They were just too much out there.

And that we really gotta find a way to figure out how to create a better separation between the data so that we really help them not be overwhelmed and so that there's not a cognitive overload. If I go the other route and share this with more of a designer mines that are like a smaller part of the design team or researcher it would be more along the lines of let's work with business to get a list for the hierarchy of information.

But while we wait for that, let's figure out a way how we can maybe separate out the information without adding in extra clicks or limited number of clicks I should say.

Nice. Cool. So we got some good questions going in the chat here. So I'm going to, I'm going to jump to those, Frankie. Okay. 'Cause I want to make sure we got time to, to get some of them.

And also, sorry, let's talk and the very key takeaways, I'll share quick key takeaways I'll share at the end. We'll get an answer to what that last question was. Frankie, take a look at some of the questions in the Q and A. I think I put cans and min juice. But everyone else, if. Take a couple minutes.

If you have a question for Frankie, drop it in the chat. I'll add it to our Q and A tab, and we'll answer these for the rest of our session, minus a quick one minute wrap up from me. So go ahead and drop those in. And Frankie, if you see any that you want to tackle or answer or tag team go for it.

Sounds like a plan. Give me a second just to read them.

Minjoo's question. Yeah, me too. Just right there. So no, I like that question 'cause exactly. I did mention that I do think engineers could be helpful to bring them in earlier. In terms of the specific strategies or suggestions to help them be engaged or more interested. I'm not it is a tough one.

Where you can't really control if someone's interested or not. That's out of your control to be fair. But I think what's helpful and what I've learned in the past is making sure that you're ultimately talking to the different mindset. So again, if we go back to our theme of reading the room, in this case now, if we have engineers, if we have business or stakeholders in the room, and design in the room.

Those are three different users. Ultimately, like we all have different takeaways from our research finding. And so I think the way to really keep them engaged is to make sure that we remember who's in the room and remind ourselves that, and so that we can then, give them insights that's going to be helpful to them.

So maybe after the research study, we then do a little re recap call. And maybe we can say, okay, one bullet point for, something we learned for business, one bullet point we learned for dev or engineering and one for design. I don't know, I'm making this up on the go here. Yeah. But something like that where it's like, just making sure that you're not just targeting your business stakeholders, I think is a way to keep them engaged,

'cause then they're like, oh, this is for me. Yeah. It's not just oh, I'm here as a fly on the wall. It's no, we're talking to you.

Yeah. And listening to you. Yeah. I think it is a good question. I think part of it, like my answer to this question would be fir first just setting the stage of they don't like.

Setting the, a amount of engagement that they need, right? Like your engineers might, they don't need to be like pouring over research in some cases, right? Like pouring over your research studies or hey, what came back from that study? So just kinda setting that level of how much do we like deep?

Do we need to go with this? But I think. I think in terms of like motivation having context, at least for me, sitting down and working on something when I have a clear direction of what's trying to be solved. Obviously as a designer, that's really important and developers are problem solving as well.

They're not just like building what we deliver them. So having that context I think opens up one just clarity for engineers or developers where it's like I have a clear understanding of the overall theme of this feedback we got or this problem and how and slash why we're going about solving it.

And I think what's also important is that developers, engineers make a lot of little decisions along the way that impact the user experience. They might, whatever, you make a slightly different UI decision or wire up a form to do some, behave a certain way. These like seemingly little things that are that add up quickly.

And if they have a clarity about the background of it and why you're doing it, even at a pretty high level that's going to, that might motivate, but motivate them just by knowing I'm not going to have to rework this. I know what I'm trying to do and decisions I'm making to build it are, I have a basis for doing that. I'm not just like in the dark, building, building stuff.

Yes. Agree completely.

Got a question from Ken here. How do you use research to shape or influence business objectives? Put that up and I'm going to check the chat too. Perfect. I know I was trying to listen and read 'cause there's so many good questions.

I'm like, I don't know where to go next. But yeah, we can answer Ken's question. That's a good one. So how do you use research to shape or influence business objectives? I think it's obviously going to depend on where design sits in your company or your project or situation even as to if you can influence business at all and have any sight in those objectives.

But I would say it's, if you do, I think it's a great way to use the research to say, hey, these are things we should prioritize. I think personally that's where it comes into play is it almost becomes like a mini roadmap to pull from in a weird way where, if you keep hearing the same thing over and over again as insights from research studies will.

Clearly that's proving something. Clearly, even if that's not what your research study is on and it comes up again maybe you do have to take another look at that. So I say that's just like a way to figure out like what to keep working on because like I said before, when you do research studies, you still get other insights.

So that's how I would use it is like almost create like a, a running log of all the pieces that come up and then maybe tally them or something, however you want to keep track of how often it comes up. Yeah. I dunno if this is the full question, but that's how I would do it.

Yeah, I was going to say like a backlog, that was going to be me, my answer, but like a menu right? And maybe you're not involved with like, how the product makes money or like what a goal is business goals being focused on for a certain quarter. But if you have even like trends or things that are coming up like that backlog of maybe other things that you're seeing in research that can then be presented, maybe if it comes down to where it's like, Hey, we're trying to, our goal is, everything we're working towards this quarter is to get like new free trials converted to whatever paid accounts if you have research and a backlog or even just like a, somewhere right. Ideas of what's valuable, what is, things that you might have learned from other studies, those could be then presented as opportunities.

So in terms of influencing business objectives, it can be either offering a new opportunity oh, hey, this is what we're trying to do. I have some like things that might be pointing us in the right direction of how to do this. And that depends on like how much, control you have over it.

But yeah. It could be like a little, in your back pocket of, okay, we're trying to increase cart totals or something. Here are some things that we've seen that might be worth like building on or exploring to get to that goal. Let's see.

What are we tackling next?

Any other question?

Alright, we got some good ones. Check 'em out. Let me know which one you want.

I like this one. I think it's the third question. Sorry I haven't gotten the bottom. Is that Stephanie's. No, the, it's the opposite question from Minjoo. How do you prevent teams? Oh, yeah. Being micromanaged. Cool. Or micromanagers. So I love this question.

I promise you the ones at the bottom, I will read in a second, but no, I really like this question 'cause it talks about how do you prevent teams from being micromanagers and da dictating your questions and interviews or surveys. So this is huge. So obviously I've talked about, yes, I love having more people.

In the research sessions as possible, like I think I still stand by that comment, but with that being said to this question, like 1000%, that does become an issue where. For me, anytime I've had non-research or design members in my research sessions I will make it clear to the stakeholders, the devs, whoever it is beforehand, and say, look, this is why you're bringing, being brought in.

This is what we're going over. But do me a favor, stay on mute. And what I'll do is I'll make a chat for everyone else. So everyone but the participants so that we can then chat in the background so that they can still be heard, but it goes through our researcher or me or whoever it is. And so it's basically me saying, Hey, let's have a conversation.

Tell me exactly your questions. But just don't say it yourself don't come off mute. And I will say as long as you're upfront about it and they still feel like they're going to be heard. I haven't had pushback on that and I haven't had issues. I think if it's no, you can't say anything and we're just keeping you silent, you probably will, but yeah, as long as I have some outlet, I think you're okay.

Yeah. Yeah, I think that's a, that's not where my mind went first, but I think that's a really good answer because you do have, it's, there's what if they're micromanaging? I guess Helene there's a they have ideas that they want to be address or things they want to learn. Yeah. If they're writing, if you have this problem, which is definitely opposite of a lot of like similar questions or more common questions.

If they're micromanaging, they have a reason for doing that. Maybe there are some other things at play, but there's a reason why they're sending you survey questions or interview questions. There's something that they want to learn from it. And then there's the translation point of there's that, which is something we want to hear and be able to translate into an actual as professionals into a good interview question or an unbiased one or one that's going to work with the flow.

Listening to that need, and, not hearing it saying, I got to the bottom of what you're trying to, like, why you're trying to learn this. And using that need, but then maybe transferring it to we're going to, here's how we're going to do it to get that, or why, or the method that we're going to use or why we're not going to do that right now.

I think for the micromanaging part I don't know if I've ever had this come up, but lucky I would, yeah. Not for like interviews, I guess I have, but I my advice would be Helene is. Look, at the end of the day, your research that you come back with from a study or a survey, the idea for the most part is going to be to make product design decisions confidently from it, right?

So I guess the worst case scenario is if this is happening and they're really steadfast on, tweaking or rewriting your interview questions and not letting you do that as a professional designer or researcher. Then see what comes back. And without making it too much of an I told you so thing let it play out as like when it's then hard to actually make that design decision based on the research, you can come back to here's how we could, frame it a little bit better.

It's let's, here's what we should try next. AKA. Here's why you shouldn't have let me write the research plan in the first place. But letting it play out to see or let them maybe see for themselves that it's not the best route to the end goal of using that to make good product decisions.

But I think that's huge. I feel like that doesn't just go to towards the micromanaging of the research questions and things like, I think that kind of goes along with everything we've talked about today is people learn best when it's their own idea or they think it's their own idea. At least what I've noticed.

And so I think like it's so important to just let them go down the path, especially when it comes to proving. And this kind of gets into Stephanie's question a little bit. If we can jump there and I,

Yeah, I was going to say, I was just reading stuff. Perfect. Yeah, let's start.

I think this connects to it where it's around how do you get the excitement, how do you get more people involved?

And I think that if you can, what.

Oh, I put the wrong one on the screen, but essay is that wasn't my question.

Yeah. The one about getting more people involved, other people who didn't like directly ask for it. But I think that it's around calling out, or using this to say, Hey look, this is what we're learning.

And if they decide we're going a different route, it's you know what? Actually, like it's a learning experience. You're letting it just not fall on you almost. But to get to this one a little bit more, how do you get more people excited? How do you bring research is a thing, I think, honestly.

Yeah. It's like learning from mistakes almost, where it's doing a project where they don't really allow you to do research. You go forward with it. And you get to the end and it flops and that's not on you as a designer, that's not a critique to you. It's the fact that you went down the wrong path 'cause you didn't know differently.

You didn't get the chance to do that research to stop you when you should have. And I think that it's honestly such an important lesson for companies and team members to learn because I'm, the saying that basically says like, when you change something earlier on, it's way less expensive for multiple reasons than when you do it later on.

And so I think, unfortunately, it's like one of those hard learn hard moments where it's okay, you don't want to, I told you a soap piece you don't want to put in their face. But it's a perfect example to say, Hey, you know what, joke around with it being like, had we done research, this could have been completely different.

And so I think that's one way is just kinda like jokey, met. Be like, you know what? Come on. The other way is, I think also is just like getting relationships outside of all of this with those individuals. And I think that even though it's not directly Ooh, let's bring you into research, it's more of let me get the relationship going with you so that then ultimately you trust me more.

And if I then tell you that this is something that like, is make or break and actually will have an impact then hopefully. And at that point, usually it does work. You actually respect me more and understand that I'm doing this to do my job. And I'm not doing this to be annoying. Yeah. And so I think that also helps have you ever tried that Joe?

Yeah. Yeah, totally. I think it's like about showing, so I'm going to Stephanie's and what was the question about like the re or getting people like excited outside of the. People. Like, you'll get them excited with the results and the successes that come out of doing good research or having answers available to questions or bus like problems that they're trying to solve, like a, a product manager who's trying to figure out a churn rate on a subscription product, when that is then answered and like you go down the right path with it. Because of research that you've done that is going to be like the most direct path to say, like showing the value of getting excited about it.

You don't need to have, and for to galos thing of a research repository, right? That might be a nice thing for people to know exists, but also hey, we're answering questions, we're building the right thing. We're not wasting time. And the reason we're doing that is 'cause we have this and we're going to it, and it's being used and you can contribute to it.

You can, or, whatever. It's, you can use this. Like it's like taking a step back and not trying to get people like too stoked on research in general and like the concept of it. But I think a lot of things that have worked for me is the what comes out of it and the light bulb of, okay.

Okay. I'm excited about not spinning our wheels on 15 different things we could build, but being able to have a process for figuring out which is going to, which one's going to hit, I. Go ahead Frankie.

Can you jump in for one second? Yeah. I also think though if we bring it back to like today's theme, 'cause I love to do that, if we bring it back to reading the room and understanding kind of what I said at the very beginning of the, the understanding in reading the room is making sure you're prepping for who you're talking to.

And I think even more so to add on to your point is if you also can correlate it to say this is why it's helpful to you. And make that very clear to them. I think also that would get them excited and be like, oh, you're not just doing a razor repository for yourself. And for the research team, it's actually to help the bigger picture.

Yeah. And I think too often ex our external partners on the product teams don't really understand those pieces. And I think that if we can open that up and explain the benefits for them specific, I think that goes a huge way.

Awesome. Sarah, I love this question you have here, but since we're a minute over time, I'm going to wrap it.

I'm going to send out I'll send you my quick thoughts on this one in in the follow up email, which is going to have all this stuff is a good question. 'Cause it is a, it, I got like a, I don't even want to start on my answer too, but I do have an answer and I'll send it out with this, since we're a minute over, let me just do a quick quick wrap up.

I got just a couple things to share with you guys and some links I'll put in the chat. First and foremost, Frankie thanks so much for joining. I know we, we packed a lot into 46, 7 minutes and it's great to chat and hang with you and just, hear your experience and your take on some of these things.

I always end up learning quite a bit from hosting these Q and As. So thank you so much for joining.

Thanks for having me. So fun.

I'm going to share some links. I'll put these in the chat. I'll put them in the follow up email as well. I to connect with Frankie and Frankie posts stuff. So Frankie's not just a good person to connect with.

I'm just like, do it. Frankie is at the top of my feed a lot with really interesting, valuable stuff and a lot of things touching on what we talked about here. So I shared those links for Frankie's site, LinkedIn top Voice, two time winner as I found out. Top Voice on LinkedIn. So connect with Frankie and keep the conversation rolling.

Some Q and A feedback. I will share this in the email. To just get your thoughts on how everything was today and suggest topics for the future. I will also share this right now. I have a workshop coming up next Tuesday not a Q and A. More of a hands-on project testing. A fun one and an important one.

Because it's about navigation and that helps users find things on your site. And that's important. So check that one out. And that'll be a little more hands-on experience based. I know it's a holiday week here in the States and people are out, but it's going to be a good one. We ran this a couple months ago and it's was one of my favorite workshops so far at Lyssna last thing. I'll put this up in the chat. This is a promo code that you guys can use. Frankie 20 nice and easy to remember. I don't know how many of you here are using Lyssna new to it, have an account but haven't touched it in a while, using it every day, whatever the case. You can get 20 free credits.

To start testing today and recruiting participants, you can click that little button down there and use code Frankie 20 to claim it. This is for the first 50 people and it expires in a week. We don't have 50 people here right now, but I'm going to be sending this recording out. So even if you don't have know how you're going to use those credits or don't have your next study.

Ready to rock. Go ahead, claim that. Put Frankie 20 in it. And as I said, I'll follow up with with that link in info in the email. All right. I'm going to skip my key takeaways 'cause they're in the email and we hit on so many of them. But my quick bullet points. You'll see those in 25 minutes when that email goes out.

So I'll let you guys go for now. Thank you so much for joining everybody. Thanks for the great questions. Sarah, I'm going to follow up with an answer to yours. And Frankie, thanks so much for joining and covering so much and sharing so much of your experience. Really appreciate it. Thanks for having me.

This was so much fun. Have a great day everybody. Talk to you later.

Q&A overview:

About our guest

About our host

Transcript

Try for free today