The beauty of research is that when it works really well, you start to discover all of the stuff that you hadn't considered before, and it opens up a ton. You should come out of it with a ton more questions than you had going in.
This is Erin May.
I'm John Henry Forster, and this is awkward
silence. Silences. Hello, everybody, and welcome back to Awkward Silences. Today, we're here with Amy Chess, a UX researcher on the talent products team at Amazon. Today, we're here to talk about generating good research questions, something that I'm pretty sure is applicable to just about anybody that might be listening. So Amy, thanks so much for joining us to talk about this very interesting topic.
Thank you both for having me. I am super happy to be here, and this is one of my favorite topics and a really, really important one in the user research space.
Jay just here too.
I feel like I could do a seminar on bad podcast questions, So I'll incorporate some of this
out my Stay for the deep cut director's cut after hours for JH's hot takes. Very bad podcast. All right. Fantastic. So we're not here to talk about interview questions. We're talking about research questions. So what's the difference, just to set the stage here, Amy?
Yeah, absolutely. So a research question pertains to what you need to learn in order to make a decision. And the interview question is what you ask in order to get that information. So it's two pretty different things, but people get them mixed up commonly. And so, you know, for your research questions, you may come up with questions that you want to have answered in order to make decisions that you would never ever in a million years put in front of a user.
You may ask those questions in subtly different ways, or sometimes in pretty substantially different ways. And the questions that you ask your users do tend to be a little bit more indirect, sometimes just kind of going around the topic. I can give an example of that would be helpful for everyone.
Yeah. We love examples.
Okay. Yeah. So do I. So I was working on a user flow at one point previously where the initial home screen had an entry point that would take you onto a secondary screen. And on that secondary screen, there were a variety of tabs.
And we needed to make a decision about what is the order of those tabs and what's the default tab. So that was our research question, or one of our research questions. So which is the default tab? Now, we didn't ask that question directly to our users. Because of course, when you ask a question like that, you're forcing your user to abandon themselves as the user.
You're asking them to leave their shoes and enter the designer's shoes. And that doesn't really help us as researchers, and it's kind of unfair to the user. Right? So we need another way to get at that information besides asking them, well, what needs to be the default? So in that case, your interview question becomes, what do you expect to find when you click on that button?
What information do you think you'll see there? And then in that way, you kind of begin to enter the participant's world and see what are their expectations, what are their needs, what do they expect based on what they've already seen in the flow. And those expectations can then form the basis for what the default becomes. So that's one, you know, really good distinction between what the research question would be and then what the actual interview question would be and how they are different.
I love that example. In in the way you described that, you had mentioned a research or research questions. And I guess I had already made the assumption that you only have a single research question when you go out to like learn something. Is it the case that you can have multiple if they're similar enough? Or is there a best practice there?
Yeah. So I typically have for any given research project four to five, sometimes more research questions. But with any given research question, you may have to ask multiple interview questions in order to get an answer to an individual research question. There is the case when we are prioritizing with teams that you may have more than that four to five research questions. Maybe you have a very long list, and then you have to begin to prioritize because it becomes too much to tackle in a single research session.
So prioritization becomes really important. But I've never seen a situation where you have only a single research question that you wanna have answered. Typically it's four to five, maybe a little more than that.
A research question different than a learning objective? Are they related concepts?
I think they're related concepts. Because to me, the point is all about exploration, right? I don't like approaching research as like a validation exercise or an exercise to confirm what we think we already know, right? So we should be we should have the objective of learning about our users, learning about their unmet needs, their challenges, what they're trying to achieve. So that's absolutely the purpose of the research.
I would say that those are analogous concepts, research questions and objectives.
Okay. So when you have this list of research questions, these four or five research questions that you wanna get answered, how do you think about, as your participant starts kind of giving you information, has it been answered or not? And adapting your script or your sort of sub questions to check that Got that one answered. Can move on.
Yeah, yeah. That's a really good question. So I think there's a distinction between answering the question in the context of a single interview versus answering the questions in aggregate across your entire sample. So for example, I had an interview this morning where I had a certain set of questions. But because of the mental model that the participant had going into it, it was difficult for him to really address the questions that I had pre prepared because he came into it with a really different way of visualizing the problem, which is also really important for us to know.
In a sense, that opens up another set of questions. So I always say like research is never really done, right? So part of it is, yeah, you're getting some answers, but you're also learning to ask questions that you didn't know you should be asking. And that's one of the greatest benefits of doing research. It's not about getting answers.
It's really about understanding what you don't know. And so in this case, this morning when I was talking to somebody, I had a long list of pre prepared questions. And then what he offered up to me was that, Hey, I understand this process in a way that's really different than what you've laid out here. So he wasn't able to answer the questions I prepared. But what he gave me instead was actually much more valuable. It was a different perspective on the problem that we hadn't considered before.
Nice. Yeah, I think that's something you always hear from experienced researchers is that improvisation and pivoting to what you're hearing is actually where you get some of most interesting stuff. I think people who are earlier to research are a little bit more anxious. I'm like, I need to stick to the things that I had defined ahead of time. That's a really good point.
To zoom out for a second on order of operations, I think we're going research question, interview questions. Is it actually research question methodology to answer that question and then you get into specifics? Or does the methodology come first and then you go into the question? Or where does that fit into this?
That's a fantastic question. So I always tell the teams I work with, don't come to me with a methodology ever. Always come to me with the question that you want to have answered first. And the reason for this is because I think people can get really hung up on like, is it a survey, is it analytics, is it an interview, and they can spin their wheels. Really like the value that the rest of the team brings is their own expertise around the thing that they're trying to figure out.
And the value that I bring is I can say, oh, you're asking this kind of question, then we need to be using this kind of technique. So usually the way it goes is identify the research questions, identify the appropriate technique, then identify how you want to actually pose those questions. You know, I've certainly had people come to me before asking things like, can you do interviews so we can see how many people use this feature? And I'm like, no, not really. Like we should look at analytics for that.
And then if you want to know why the people who are using it, why they're using it, then we can do interviews. So it's really kind of helping direct what it is that people need, really getting them to focus a lot more on what the questions need to be rather than coming to me with a specific technique.
Do people usually know what their questions are or do you have to kind of co create those questions
together? Yeah, so it's very, very collaborative. People generally need a lot of help coming up with the questions. And that's very common when people haven't worked with a researcher before. It's extremely common to not know where to start.
And I try to be really encouraging because developing that skill of query formation is so essential to being able to work on a product team and being able to be effective. And that skill will serve that person throughout the rest of their career. So I really bring them into the process. And to get them to identify good questions, I keep it I ask them really simple questions. I'm like, what keeps you up at night?
Right? Like, what are you really worried about? What is gonna happen if we don't understand this? And get them to identify areas of risk because at the end of the day, user research is a risk mitigation strategy. So if we can get people to hone in on those areas that feel slippery, that feel nuanced, that feel like, woah, we could really mess this up.
Or if you are up against a potentially irreversible decision, what we call one way door, then that's something that you probably need to direct research resources to. So that's where I try to get people to dive in first. And then I also ask them, you know, what decisions do you need to make? What is outstanding that you feel like you don't have clarity on? Or what are you arguing with people on the team about?
What are you arguing with other teams about? You know, what are the unresolved issues? And the research is not there to tell us who's right and who's wrong. It's to inspire a more informed debate. It's intended to give us sort of directionally correct information, kind of pull us in the right direction and help us resolve things enough where we feel like we can bring in tech teams and start the actual building process. Yeah.
Yeah. Because you hear that, like, help me settle a debate. It's like, you're both wrong.
Yeah. You could both be wrong, right? And that happens.
The debate, right? Like, stay on
the table. That's right. Yeah.
Yeah. I love that phrase, the one way door. I feel like I you talk about that in, like, in the product side where I work, you talk about, you know, what's reversible and things like that quite a bit, but that's a good way to put a point on it. Where can a research question go wrong? Like how do you end up with a bad research question?
Yeah, so I think bad research questions, you know, one, if they're not anchored specifically to a decision that needs to be made, or two, you know, understanding what's maybe two to three years off in the future, which is a huge benefit of having research is being able to be forward looking. I think another area where research questions can go wrong is if they become very solution specific, and not anchored to customer problems. So a lot of times you'll see people asking things like, you know, they'll come to me with a research question like, well, what features should we have? And I'm like, you know, this gets us so far afield from the actual issues that people are experiencing. And I think with user research, you want to stay very grounded in what are the person's goals?
What are they trying to accomplish? What are the barriers and challenges? What are their compensatory strategies when they are not able to get what they need? How does that impact their other work? And in fact, I think it's really important in research, When somebody's talking about a problem that they're having because they don't have a product that meets their needs, there are actually a bunch of downstream cascading problems that occur from that that aren't always documented.
But I think it's really important to understand what they are. So for example, let's say there is some sort of manual process that you have to do today as a user. And you're building pivot tables in Excel and you're spending tons of hours doing this manual stuff that could be done in an automated fashion with a tool. You know, asking questions around, well, what kind of problems does that present for you? Okay, and then how do you resolve that?
And who do you have to pull in to help with that? Oh, you had to build this other thing to compensate for that. Oh, it delays you. And then going through that whole downstream, you know, cascading sort of network of bad things that happen. Your product isn't just addressing that first primary issue, which is the manual work.
It is actually addressing all of the downstream crap that happens as a consequence of that initial thing not working well for them. And so even when we're thinking about success metrics, we can think about all of those downstream things that are happening as being ameliorated by the product. And how cool is that? Like the success that we have when we introduce a product that solves a problem, that success can ramify out to a lot of different things. So that's why I don't like to be solution focused in research and really concentrate on what are the problems?
What problem does that cause? And then what happens compensatory strategies? And then my other thing that I absolutely love to ask people about is, well, if you had this automated, and you get all that time back, how do you use it? What do you do with all that time? People's eyes just light up.
They're like, oh, well gosh, I get to do all the strategic work that I was hired for. And, you know, I get to use the skills that, you know, I want to use to be effective. And I get to talk to more people. And so that is another form of success, right? It's not just about like what your product is doing for people. It's not just about the future. It's about all the other stuff that the product or service enables.
Yeah, absolutely. I mean, shameless plug for user interviews. We hear that all the time. No one wants to spend their time doing recruiting logistics, right? So yeah, yeah. If you can say automate stuff for people, that's always a huge win.
Huge win, yep.
All right, so what's a good research question look like? And you talked about, sometimes you ask a question, you learn, whoever you're talking to this morning, some other interesting stuff that maybe is answering a different question. So what's a good research question?
Yeah, so I think good research questions, number one, at the outset uncover how people think about fundamental concepts that we may be taking for granted. So it could be, you know, I used to work at Amazon Web Services, and I would talk to people about how they define applications. What does the concept of an application mean to you? Really basic question, but really important that we have a shared understanding of what that is at the beginning of an interview so that we're talking about the same thing, right? Same in the human resources space.
Just making sure, hey, we're talking about the concept of succession planning. What does it mean to you? How do you define it? What are the steps? What are the sequence of those things?
So getting an understanding of things that may seem really obvious, I think is a great place to start because a lot of people kind of blow right past it. And then if you do that, number one, you're making a lot of assumptions during the interview itself, thinking that you're talking about the same concepts in the same way. But number two, you know, if you establish it at the outset, you have a nice foundation upon which to build for the rest of the interview. And that can be really valuable. So I think, you know, number one, understanding, having like that shared understanding of certain fundamental concepts.
And then number two, getting a little bit of information around how different concepts, processes, events, etc, relate to each other or not. So that then you can start to build out a schema or a mental map of that individual user's perception of the world that they work in, right? So what does this particular process mean to you? And how does it relate to the thing over here? And then what do you do?
And is it always that way or just under certain circumstances? And then from there, you can see, those models match up across your participants? Do they differ along specific demographic characteristics like geography or level of expertise? Those are all really important things to know. So I would say those are really good types of research questions, because it gives you enduring insights.
It's not just kind of a one off thing. You can return to it over and over again. Because generally speaking, the way people conceptualize these kinds of concepts, their relationships to each other, the challenges and barriers in their work, those things tend to be relatively long lasting and enduring. And you can return to that research over and over again. It's much better than the notion of someone asking like, design do they prefer?
That's not a research question, right? Like that doesn't give you enduring insights. It's a, I prefer this or I prefer that. It doesn't give you any sort of insight into the mechanism behind it or the why.
Something you said there was about, you know, does this vary by segment or or other kinda demographic vectors and stuff like that? Is that one of the research questions? Like, you're up front saying, like, we need to figure out, does this figure? Or is it, like, the answer you're you're asking one question, and you're just talking to a different cross section and so you're keeping an eye on if it is varying or it's both? Or like how does that actually work out in practice?
Yeah. So sometimes we do have explicit research questions where we do want to dig into the differences between different demographic groups because we have suspicions either through, you know, informal conversation or some other piece of information that there may be a difference between them and we need to explore it in a more systematic way. Sometimes it emerges during the research, like go into it not expecting a difference, and then we start to see something. So that's been really interesting. Some of my recent research, I've been observing differences in tenure of people and how that impacts their perceptions of certain activities.
So that was not something that I expected at the outset, but it's definitely something that emerged as a consequence of the research.
Yeah. And so on that, when you're actually you know, a research project and doing this, and you started out with a set of research questions, do you modify it and groom it as you go, or like, because you're learning new things and you want to adjust it a little bit, or is that more of like you factor that into future research and to kind of stick to the original set that you had started with?
Yeah, that's a really good question. I think it's a little bit of both. So sometimes, I would say most of the time when I'm modifying research questions as I go, it's because things aren't landing right, or we, you know, there's a reason that we need to maybe like focus on a certain area a little bit more as we've gotten information during that set of research. Sometimes it's the case that you open up a can of worms and you're like, Oh, wow, this is like a whole new world. And we do actually need to dedicate a secondary set of research to it.
Because you've simply learned more. And now you're aware of what you didn't know before. And there are what we call known unknowns. You guys have probably heard that phrase before. The beauty of research is that when it works really well, you start to discover all of the stuff that you hadn't considered before. And it opens up a ton. You should come out of it with a ton more questions than you had going in. I think sometimes It's
good way to keep yourself in the job, right? You got some more questions here,
Exactly.
It's infinitely self reinforcing. You always have more questions. And I think that's actually something that can feel intimidating a little bit to people who aren't used to research because they want some finality, some conclusions, some like, Oh, we're good. But you don't really get that with research. Know, you get enough information where you feel like you can make an informed choice.
You make the choice, and then you have a robust plan to continue to collect information after you've released it to people. It never really ends. And so you're like constantly in this feedback loop of getting that information and then making changes and folding it back into the product or service.
Alright. A quick awkward interruption here. It's fun to talk about user research, but you know what's really fun? Is doing user research, and we wanna help you with that.
We wanna help you so much that we have created a special place. It's called userinterviews.com/awkward for you to get your first three participants free.
We all know we should be talking to users more, so we've went ahead and removed as many barriers as possible. It's gonna be easy. It's gonna be quick. You're gonna love it. So get over there and check it out.
And then when you're done with that, go on over to your favorite podcasting app and leave us a review, please. So you wanna ask a good research question. We talked a little bit about what some characteristics are there, and you wanna, like, chip away at, like, something approximating, like, sort of answering them. Right? Mhmm.
But you're gonna get new questions out of this, and it's never, like, over. Mhmm. And so what is the enterprise zooming way out of user research in terms of, you over time, if you knew a customer 0%, do you get closer to 100%? Or the product's always changing. The market's always changing.
The world's always changing. So the goal is not to know every customer in their totality 100%. But is the goal to, over time, get closer so that you feel that you really start to know your customers and their various segmentations and their contacts better and better over time?
Definitely. Yep. And you can begin to anticipate their needs perhaps. I've never stayed in a space long enough to know or to observe things changing so substantially that the research was like no longer valid. Like if you're doing good generative research, that information tends to be relatively enduring.
But, you know, I would imagine like a fast paced place like cloud computing, I wasn't in that space for that long, but I would imagine because it changes so quickly, you could perhaps have to do a lot of work to kind of catch up to all the changes that the customers have.
Yeah. So the questions keep piling on, but it's not this sort of sisyphusian thing of like, you're starting over. The questions keep coming and you get closer to an answer.
Yeah, yeah. Knowing. Yeah, yeah, exactly. Yeah, you're kind of it's more additive than starting over from scratch and feeling like, oh, I don't understand any of this. It's more like, okay, now I'm filling in the nuance.
You start out like in any research area, you start out and initially you're going kind of broad and just understanding what are the needs, challenges at a really high level. And then as you start to amass the information, you can start to get more detailed, more nuanced in those conversations and just kind of fill in the gaps.
Yeah. It feels like almost like there's like a tree and you kind of keep adding branches to it and it gets like, you know what mean? It's like you have one branch and you kind of know where you are and then it has sub branches and you have more leafs and you have like more coverage and some like, that's the thing that's coming to mind for me.
Yeah. Yeah.
You mentioned, you know, like, a common way of having a bad research question is being too solution focused. And so I almost think of that as being, like, too narrow. Right? Like, we're really zoomed in on the thing we wanna build, and we're asking or trying to learn about that. It feel and that to me feels like something where even if you're not an amazing practitioner of this, you could probably identify like, group of people could probably be like, hey.
This seems a little solution y. Maybe we should zoom out a little bit. But I'd imagine you can miss in the other direction where you go way too broad, where your research question is like, what do you value in life or something, right? And it's
like, wait, what's happening right now?
And that almost feels like maybe harder to diagnose, like when are we maybe overshot in the other direction? How do you make sure that you end up too far removed from things?
Yeah, that's a great question. I think the answer to that is to always make sure that your research questions are very tightly coupled to the decisions that you need to make. So one exercise I've done in the past is I've kept an Excel spreadsheet where we list out the research questions, and then we have a column for the decision that question would help inform. It could be an item on the roadmap. It could be a specific requirement.
It could be some sort of, you know, piece of customer feedback that came in and we needed a deeper dive. But I think that's really the solution to having it be too out there in the world and not having it be tethered to anything specific is just to make sure that there's a nice relationship between the research question and the decision that you're trying to address with it.
Nice. Yeah, yeah, that's good Going
back to the other end, we'll swing back and forth, right? So on the more narrow side of things, you talked about good research questions, having enduring insights, right? And not being like, which one do you like better, A or B? That's what AB tests are for, right? But is there like, what makes a good research question for an evaluative test?
Right? Like, is there's clearly a place for later stage evaluative testing within the UX research toolkit? Yep. So how do you ask good research questions kind of later in the game?
Yeah, I think that's a fantastic question. So my favorite technique for that is to, at the beginning of an evaluative session, spend a few minutes understanding their goals, what they're trying to achieve, and the work that they're trying to do. Then we'll explore a prototype. And they'll give me feedback on that, and I'll have some targeted questions. And then I'll ask them, how does this, you know, relate to what you told me you needed at the beginning?
Does this align with what you said you needed? Is it off base? And then that way we can have a conversation that's very much rooted in what their needs are. Because if you just give them a prototype without any kind of, you know, introductory conversation about what their needs are, it's a little decontextualized and it becomes really difficult to be able to tie it back to the needs that they have. So typically, and this is true of generative or evaluative research that I do, the way that I structure my interviews is I start out really general and then go increasingly specific, more and more specific about certain functionality, features, etc.
The reason I do that is because having it open ended at the beginning allows them to offer up whatever's top of mind for them. It allows them an opportunity to put their priorities out there. And to direct the conversation, it keeps them firmly rooted in their perspective as the user. And I think that's really important. Even when we're testing solutions, even when we're, you know, testing prototypes, having everything be anchored to the work that they're trying to do is extremely important.
And then bringing the conversation back to that and saying, okay, how does this align with what you need? So then it's not a question of a preference. It's a question of, does it help you? You know, it's a question of, does it have value?
So a good evaluative research question is, what is your need? What is your pain? What is your job to be done? Whatever. And does this solution do that? Yeah, yeah, exactly. Exactly. And when you're choosing people to talk to, do you already know what their pain is? Right? Like have you done your sequel to find the people with the right viewpoints? You have a sense of maybe that they're a relevant user, but you're trying to zero in on exactly how you would their relationship to this kind of
I have a general sense sometimes of what the issue is, but I always have them go through it because sometimes there's subtle differences depending upon wherever they are in the organization. And so I do have them go through it. And also, it keeps it front of mind for them, too. If we've just talked about that, you know, all of their pain points and what they're trying to achieve, it's salient for them. They're kind of primed, then.
And so then when they're going through the prototype, they can easily circle back to the things we discussed at the beginning. But yeah, the point is just to keep it very relevant to them.
Nice. Yeah. It's like the knead sandwiches the prototype sort of like align on it up front, then show them something, then like circle back on at the end.
Right. I love that. I love that sandwich analogy. That's great. Yeah.
Because you don't I I think a bad approach would be to do like a prototype review first and then ask them if it meets their needs. Because I think sometimes people feel a little bit of implicit pressure to be like, oh, yeah, yeah, sure, I guess it does. But if you have them to state their needs upfront, you know, without any kind of biasing information, then you're going to get a better pulse on what it is they really need. They're not going to be there feeling like that, you know, social desirability pressure. I think having it and sequencing it in that order is really important.
Yeah, it feels like there's like a powerful psychology thing there, where if you do it in the order where you show them something and then say, Do you like it? They want to be pleasing, so they're going to have some pressure to say yes.
What we're going to talk about today. Do you tell them the outline of obviously, you're not like, I'm going to ask you about your pain, and then I'm going to see right. But do you give them a sense of how the time's gonna go that we're just gonna kind of chat for a bit and then I'm gonna show you some stuff and then we're gonna Yeah. How much do you reveal so that they're oriented about how the time's gonna go without sort of revealing the act, right?
Yeah, that's a really good question. So I give them an overview at a very high level. So I'll tell them, Yeah, I'm going to talk to you for the first few minutes to learn a little bit more about you and the work that you do, any challenges or, you know, barriers you experience in that work, things that you do today to accomplish it. And then we'll do a review of the prototype, and you can give your insights on that. And that's generally all that I give them at that point.
I keep it pretty high level. Don't explain the rationale behind it, certainly. Right, right, right, right. I keep that to myself.
Yeah. To switch gears a little, it seems like stakeholders you're working with, sounds like they don't often come to you with great research questions off the bat. They might come to you with a methodology in mind or a business question or solution thing. And then you're trying to help them, you know, let's, hey. Let's unpack this a little bit and actually get it to a better research place.
Are people pretty receptive to that? Is that a pretty natural back and forth? Or do you get it into like a little bit of like a headbutting thing of, no, I just wanna run a survey, like, let's run the survey or whatever.
No. Actually, people are very receptive to to the feedback because it is a conversation, and I do want them to own part of that. And it should be a really nice collaboration. It should be fun, really, if you're doing it right. So I try to bring people in, they'll ask questions, and then I'll ask them questions back.
I'll be like, Well, why is this important for us to know? What is this going to help us understand? And then if they realize that, well, maybe it's not going to help us understand anything that's important for what we're doing, then maybe we don't need it. And then we go through that process. But people have been very receptive to it, very engaged.
And I think it's important to, you know, meet people where they're at and bring them in. I mean, user research is pretty new for most teams, right? There's not a lot of precedent for it. Almost every team I've been on, it's been the first time where they've worked with a researcher. So making it a positive experience, I think is really important.
And making it a good partnership is really important. Making it fun is really important. Because it really is, it's a journey. It's an act of discovery. You can, and through your research, learn and discover things that no one else in your company knows. And you're the first person to see it. And how cool is that? Right? So I love bringing people into that process. I think it's awesome.
So yeah, people have been extremely receptive. It's definitely a back and forth around what the questions should be. And, you know, giving people the advice of like, you know, you don't need to come to the table with a technique in mind. People have been really receptive to that as well and been better about thinking about the precise question they need to have answered.
I feel like there's so much trust that must be relationship building, EQ, things we associate with UX researchers. But with internal stakeholders, right, too, I mean, you mentioned to ask a good research question. Let's just start with what keeps you up at night. No big deal. Right? Oh god, how much time do you have? Right?
Right. Right. Exactly. You
probably really get to know people digging into that kind of existential stuff, work stuff. But yeah, it must put a lot of importance on building those relationships, right, to get to great research questions.
Yeah, yeah. It is like that. I think that relationship between researcher and the rest of the team, it feels like a special one because you are sometimes revealing things that are hard for people to hear, too. You know, maybe an idea that we thought would be would land really well. Maybe it's not.
Maybe the need that we thought was there in the market isn't as there as we thought it was. So sometimes we come back with tough information. And I think it's all about like not personalizing it. It's like the research and the data. It's like a gift that is supposed to make our lives easier, prevent us from building things that don't get used or get used in the wrong way.
It's supposed to be a help, not a judgment. And so I never want to couch things in terms of this was good or this was bad, or they preferred this or didn't prefer that. It's like, want to couch things in terms of an understanding of people, an understanding of human behavior and the mechanisms behind it. And, you know, really get people to learn and be curious about all of that because there is so much to learn. So yeah, I think that relationship is very special.
And I think trust building is really important. So I'm always really open to just when I'm conducting interviews, if I've asked a question, like maybe not in the best way, I'll point it out to people. I'll put my vulnerability out there. I'll put my mistakes out there so people can learn from them, because this is really all about learning. But it is a vulnerable space. And I think it can be intimidating too, for people who have not worked with research before.
Yeah, always feel like stakeholders are always juggling other considerations too, right? And I think sometimes when they come in maybe with a question that is a little loaded, like, I just want validation for this idea, It's probably not because they, like, need to be right, like, from an ego perspective. It's it's probably right of, like, well, I'm I have to have a q three plan outlined soon, and all my thinking is around this idea so far. So I would, like, like to kinda check the box and say this is a good idea. Yeah.
And so Sure.
Yeah. Yeah.
It was a matter of just getting with them early enough so that there's some runway that if you need to course correct because you learn something new, it's not like catastrophic. Or how do you get them comfortable with the idea that we're maybe just not gonna rubber stamp this and we're actually gonna do some real discovery here?
Right. That is an excellent question. So I literally just gave a presentation on this like a week or two ago. And one of my slides said something along the lines of work with UX research before you're ready to work with UX research. Because I think there's the tendency to for people to have kind of their idea more fully fleshed out.
What is my product concept? And who is the market? And have all of this, you know, out and understood before the research. But the research is actually the method that you use to get to more clarity and to having those things more fleshed out. So I think that the reluctance to come to research early enough is really out of, it feels really uncomfortable sometimes to go to somebody on your team and say, this is a big ambiguous mess, and I really don't know where to start.
It could go this way, it could go that way. I don't really know. And so I think sometimes people will, because that is uncomfortable and doesn't feel great when it's the ambiguous, people will put off coming to research longer than they should. And then it becomes a real headache to try to get everything done in time. So I tell people, it's okay if you feel uncomfortable, it's okay if it's ambiguous.
I love ambiguity. Bring it on. Let's have a conversation about it. Again, it's not about getting definitive answers. It's about understanding the space enough to know, have we identified risks? Have we identified questions we didn't know were there before? And so that very early stage of research, that's kind of more of what you're focusing on.
Yeah, feel like it's such a superpower and people realize that sharing work early is to their benefit, like, whatever you do, right, whether it's an early draft of a marketing material or a sketch of a design or a product strategy. Like, there's something I think when you're earlier in your career and you don't have as much confidence, it's harder to do because you wanna show people that you're competent and present something that's good. I think when you get a little bit more tenured and experience, you you start to have some of that confidence of just like, here's something off the cuff. Like, what do you think about it? Because that input's valuable to me, and I want it real time,
and it's really good for what you're Absolutely. Yep. Two thumbs up. What do you like most about UX research?
The most I I would say I have, like, a top five probably. I don't know if there's, like, a single thing I like the most. I think I like teaching team members. That's probably my favorite thing.
Other UX researchers or stakeholders? Or
Stakeholders. Stakeholders. Yeah. I haven't had too many opportunities to work with other UX researchers. But in terms of bringing research to stakeholders, I absolutely love just the process of opening people's eyes up to what this world looks like.
And having our team members become better at query formation, asking better questions, being curious, those are lifelong skills that can be applied anywhere. But I think really teaching all of that stuff, I just absolutely adore. I have a teaching background, so that's probably where that comes from. I get my teaching fix like on the team, which is great. Yeah, but seeing them ask questions and make their own discoveries and gain confidence around that and then be able develop some autonomy around developing their own questions and and doing their own research is really great to see.
So I I would say that's probably my favorite part.
Thanks for listening to Awkward Silences brought to you by User Interviews.
Theme music by fragile gang.
Editing and sound production by Kerry Boyd.