The Power of 'No' in UX Research: Asserting Influence and Driving Product Strategy

Tyler King at UXDX Community: Empowering UX Research & Customer Listening. Video: https://youtu.be/_Y_pTp7MDro

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.

Introduction

[00:00:07] Hi everybody. Thank you for that great introduction. We can hop right in, but I'll introduce myself really fast. Like Rory said, I'm Tyler King. I'm a senior UX researcher at SAP. But before SAP I was a UX researcher at IBM, so I've worked on everything from mainframes to the business partner ecosystem to software networking. And now that I'm at SAP, I'm in the enterprise software space.

[00:00:36] Right now at SAP I am on our central design team. I am part of a central research team that's basically a rotating research team, where we go out and join different teams across different lines of business, and we step in to run research where there might be gaps or a lack of resources, or just really cool opportunities.

[00:00:59] But the big reason that I joined SAP is because SAP's design maturity is still kind of emerging, and we're at this really, really cool inflection point where we get to set the tone for best practices in UX and UX research. That's really exciting to me because what I get to do is essentially teach designers and product managers and engineers and whoever else how to most effectively leverage research. So basically, every time I join a new team, my goal is to make sure that my stakeholders come out of this interaction knowing how to more effectively leverage UX research.

[00:01:40] At the same time, I want to teach other folks on my team, maybe greener researchers or just any other researcher, I want them to know how to look more critically at research project requests, because we've all gotten a project request from a stakeholder that is just not good.

[00:01:59] I know I can't see any of your reactions, but pop in the chat just an "ugh" or a clappy emoji or something if you have heard any of these things before as a UX researcher, because I get these all the time. I hear things like, oh, it's going to be a quick research sprint, one-month turnaround time tops, by the way, we don't have any research participants for you, so go recruit them yourself. I've heard things like, we just want to confirm the customers are going to love it, I mean, pay for it. Or, we just want to make sure we know which features and functions are most valuable to our customers, but by the way, we've already built them.

[00:02:35] So if you've heard things like that, throw it in the chat, tell me what you've heard before that's annoying. But what we're going to cover today is addressing those pain points associated with those types of requests. I'm going to talk to you guys about how to rescope and set expectations with a new project request. We'll talk about how to gather your UX research data like a boss. And then I'll talk about maybe my favorite topic that I love talking about, which is delivering bad news to stakeholders, because it's really awkward but it's really, really important.

Setting expectations and boundaries at work

[00:03:05] But we'll start by talking about setting expectations and boundaries at work, because that's really what the essence of this talk is about. What you should be doing, what we all want to be doing, is producing outcomes that we are proud of. Producing outcomes, as researchers, as designers, as whoever, that we're not proud of is not going to help you achieve your career goals. By advocating for yourself and by setting up expectations and boundaries at work, you are setting yourself up to do better work, be more reliable, and just be happier overall, which again is going to create this cycle of doing better work.

The vibe check request

[00:03:43] So we'll talk about rescoping and setting expectations. I like talking about things by telling stories, because it's fun for me and it's probably more fun for you. Last year I got a project request and it was pretty simple. They basically just said, hey, we have a new prototype for a website, go and evaluate it. Simple enough.

[00:04:05] But there were some caveats. The timeline that they gave me was a two-week turnaround time, because the website was going to go live in three weeks. They also said, we don't want A/B testing, we don't want usability testing, and we don't want any content evaluation. I was like, okay, so what do you guys actually want? They said, what we do want is a vibe check before we launch. We basically want to make sure that the vibes are right. Which made me do a bunch of face palms, because that's a very tight and squishy type of research request.

[00:04:40] It's not hard for us to be critical of this type of request, so let's do it together. The first issue was this timeline. Two weeks to build a study, recruit users from scratch, deploy the study, synthesize the data and the results, and then build a semi-decent presentation is not enough time. It's just not enough time. I don't know if you guys are superheroes and you can move really, really fast, but that is not enough time for me to get my work done in a way that I'm going to be proud of the outcome.

[00:05:13] And we talked about this very vague ask, in terms of they just wanted to do a vibe check. Vibe checks are for going and scoping out a bar before you commit to drinking there for the whole night. They are not for UX research, because we could be spending our time and resources much better and do better UX research than by doing a vibe check.

[00:05:35] So I got this request and I wanted to throw it out the window. I wanted to tear it up and throw it away. But I do not have the charisma of Allu Arjun, who is in this GIF. I don't have his spunk, his nerve, I don't have his hair, I'm not as fabulous as him. So I couldn't do that.

Level setting with my manager and stakeholders

[00:05:53] The first thing I had to do was level set with my manager. The things that we talked about were the sacrifices that we'd have to make because of the short runway. We decided, my manager and I, that we have to be very clear with the stakeholders about the sacrifices that they'd have to make by introducing such a short runway. They'd have to sacrifice quality of data a little bit, or trustworthiness of the data, or sample size of the data.

[00:06:21] At the same time, I wanted to be clear with my manager that I wanted to do work that I would be proud of. I wanted to be proud of the outcome. I wanted to learn something while doing the exercise, or by doing the study. And so we wanted to figure out how to take advantage of the vagueness of the request to gather additional quantitative and generative data, so that the team could do something actually useful with it, and then I would be proud of what I was giving to the team.

[00:06:50] With these kinds of expectations in mind with my manager, I moved forward by meeting with my stakeholders. My primary goals every time I meet with stakeholders for a new project are: listen to their needs, make sure they feel heard and valued, but be very, very clear about the sacrifices that we have to make. I wanted to explain the methods I was considering, so they could understand why the timeline was a little tight, and they could understand, maybe for future reference, that they need to allocate more time for research.

[00:07:23] And then the last thing that I wanted to ask and understand was how the research findings would be used after the study. I put a little star here because this is super, super important. I ask this question before starting any new project: how will the research be used? If the answer isn't concrete, my manager and I always very, very seriously reconsider taking part in the study. Because if they're like, I don't know, I just kind of want to know this and I don't know what I'll do with the findings, then it's a waste of our time, it's a waste of our resources, and they're kind of arbitrarily delaying the start of their own project just for checking a box that they did research.

Writing the study plan

[00:08:04] But for this project we had a good answer of how they would use the findings and how they would pivot accordingly if anything popped up. So I started to write a study plan. When there are expectations that need to be clear up front, having a study plan in writing is going to be very, very helpful, because it will save you a lot of awkwardness.

[00:08:26] This is how I usually structure a study plan. I put down the stakeholder goals and I rephrase them as research goals so that the stakeholders feel heard, timelines, research participant criteria, the usual stuff. But the one thing I want to call out here is, when allocating time for this timeline, always leave yourself a little bit of leeway. Always ask for a little bit more time than you need, so that there's no disappointment on your end or disappointment on the end of the stakeholders. Ask for a little bit more than you need.

[00:09:01] And then present this research plan, this proposal, to your stakeholders, ask for feedback, and then haggle a little bit. So I might ask for four weeks for a study when in reality I could probably pull it off in three weeks. So I have a little bit of wiggle room to give and take with the stakeholders and still have them come out feeling like they've accomplished something and they've gained something from the interaction, and I still know that I'll be comfortable conducting the study in the way that I wanted to in the first place. So you always want to make sure you're not running on full sprint. Allocate a little bit extra time.

Gathering data like a boss

[00:09:37] So we have this very exciting research study. We have a proposal. Now it's time to gather data like a boss, because ultimately your goal as a UX researcher is to build trust and investment in the data that you collect and the insights that you deliver. We don't want anybody poking holes in your findings and pushing back and saying, hey, this data is not valid, because it's just a headache for everybody and we don't want to waste time. So how do we do that? How do we build trust? How do we build investment while still protecting our own boundaries and establishing our authority as UX researchers?

[00:10:16] The way I do this: I generally involve my entire team in my research process. It builds trust with the team, it strokes their egos, it makes everybody feel very important. But from a practical perspective, it brings a lot of diversity of thought and allows crowdsourcing of questions, so that we're building a very, very robust research plan with questions that I probably wouldn't have thought to build.

[00:10:43] I do this by getting the entire team involved in the research planning process. Usually when I start a new project, I kick it off with a questions and assumptions exercise directly in Mural or Figma or wherever you want to be. You could do it in a Word document, I don't care. But get everybody together, synchronously, asynchronously, to just brain dump all the questions, all the assumptions, anything that could happen. Because again, we're getting a really great set of questions that maybe we wouldn't have thought to ask in the first place.

[00:11:15] And it's also building trust in the questions that you're asking, because you might get really interesting questions from your engineering stakeholders that you wouldn't have known to ask, and they're feeling like they're doing you a favor, but they're helping you a lot more to gather that data that they're asking for. At the end of the day, your stakeholders are basically your users, and we're trying to get them the information that they need in order to do their jobs most effectively, because we're researchers. So pulling in your stakeholders from the beginning for the planning process is really, really helpful.

Involving stakeholders in the sessions

[00:11:49] And I like to pull them in for the study itself. Not every single stakeholder, because if you have too many the users start to get overwhelmed, but I like to grab a small number of teammates so that they can join in on my user sessions if I'm conducting live sessions. But it's really important when you're doing this to send out a note to establish and agree upon boundaries, roles and expectations ahead of time.

[00:12:15] I'll go back to the slide, but in this note I said, hey, this is what we're going to do, we're going to conduct these sessions, I am the researcher, I will be conducting them, and when I need you guys to ask questions, I will call on you, I will ask you. And we want to stay on time, so don't deviate from the questions that we've already agreed upon. So this is how you start to establish that authority that you really need to have as a researcher.

[00:12:40] And here's what this can look like in action when your stakeholders are on calls with you, or your teammates are on calls with you. I usually just have a little Slack conversation behind the scenes. It can go a very long way, but it allows me to facilitate what's going on with the user and facilitate what's going on behind the scenes with my teammates or my stakeholders, so I can maintain control, but I'm still getting everybody involved and getting their help when I need it. Because we, at the end of the day, are a team. So it's just great to have everybody feel like a team, and I'm not holding research too close to my chest, I'm starting to democratize it a bit.

[00:13:19] But one thing that's really important throughout your entire research process is to communicate with your stakeholders along the way, especially if something changes, like a timeline or deliverable type of thing. Or if you're running low on research participants, you're having trouble getting those research participants, they might be able to help you. But we never, never want to have any surprises, because surprises are bad in business. It freaks everybody out.

[00:13:45] One more thing I'll leave you on when gathering your data is that you want to have a good mix of qualitative data and quantitative data. The quantitative data is going to be super, super important because numbers do not lie. So make sure, even if you're doing a qualitative study, you get some type of quantitative data, because it's very, very hard to argue with numbers. Having numbers makes your study more airtight and makes your insights more trustworthy if you can back things with metrics. Here are just some examples of some solid quantitative methods that you can use. They're pretty easy, very Google-able to figure out how to do them. But yeah, try to incorporate at least one or two quantitative questions in a qualitative study.

Delivering bad news to stakeholders

[00:14:31] All right. My favorite section is about delivering bad news to stakeholders. When I joined SAP I told people that my research specialty is crushing people's dreams, because I have no problem delivering bad news to stakeholders. But that has come with a lot of practice.

[00:14:49] For this story that we're telling: I conducted the study, I executed on it, I did the research and I synthesized the data. The data very clearly indicated that the users were not at all happy with the prototype I was sharing with them. And that is totally not a bad thing. That is 0% a bad thing, because we do research so that we can fail fast, and we do research so that we can fail cheap. It is a lot less expensive to find out that a prototype is bad before it's been built and coded out than it is to find out that a product out in the world that has been marketed and sold is bad.

[00:15:32] So I'll deviate from the story a little bit to talk about one of our favorite stories, the beloved characters of Jack and Rose. Again, I can't see emojis or anything, but drop a little Titanic or a little boat emoji in the chat if you have seen Titanic. I'm going to assume that you guys have, but I will recap just in case. Titanic is the story of the supposedly unsinkable ship that turned out to be quite sinkable. And in the movie about that very tragic tale we have our two protagonists, Jack and Rose. They're beautiful and they are in love.

[00:16:10] I saw this little cartoon online when putting together this presentation and I thought it was very pertinent. It's two people on board the Titanic. It's about to hit the iceberg. And one guy says to the other, yeah, I saw that iceberg about a mile ago, but I didn't want to cause a panic.

[00:16:29] If somebody had caused a panic and raised the alarms about this iceberg, Jack, our favorite beautiful protagonist, would still be alive. And we wouldn't be blaming Rose for not making space for him on the door, which he still wouldn't have fit on. We can talk after this if you have a disagreement there.

[00:16:48] But if we take this topic of the icebergs and Titanic and we bring it to what we do as researchers, it is up to us as UX researchers, as folks that care about our customers, to help spot and steer our ships away from icebergs. But real talk, people do not like receiving bad news. Wow, crazy. People don't want to hear that their babies are ugly. That's wild, that's news to me. No, it's really awkward, people don't like hearing bad news.

Curating your findings

[00:17:16] One way to make bad news a little more clinical and easier to process for stakeholders, or anybody, is that it comes down to curation. Curating your findings is super, super important. You have so many things to help you tell a story as a UX researcher, so it is up to you to choose wisely. You have lots and lots of raw data. You have your insights, which are your brain babies, they're beautiful and they're great. And then you have graphs and charts and things.

[00:17:51] But before you decide how to curate your findings, the first thing you should ask yourself is: should I tell my stakeholders what to do, or should I lead them to a decision? There will be a wrong answer, maybe, in your scenario, but every single scenario is going to be different. I have had situations where I just straight up tell people the facts of what I've come to the conclusion of: hey, this is bad. I have had more scenarios where I lead my stakeholders to a decision that I have technically already made. We'll talk more about that in a second, but I'm a big fan of leading to a decision because it is less awkward for me.

[00:18:31] When you're curating your findings, straight-up raw data is totally an option. It can be very, very powerful. So make sure when you're synthesizing your data that it's easy to consume. During synthesis I use colors, I use icons, I label everything, so that, one, I can understand what I'm looking at, but if I end up having to show people my raw data and the data that I've synthesized in Mural, I love Mural, then it's easy for those folks to consume.

[00:19:01] I've straight up had presentations with VPs where I don't make a PowerPoint, I don't make a keynote. I'm like, this is a very heavy topic and there's a big decision that needs to be made, we're going to go straight into my Mural and look at the synthesized data, because it'll be a lot easier for you to consume. And then while we're doing that they can see the exact user quotes that led to the insight. It's very powerful sometimes, not all the time. It's up to you to decide.

[00:19:34] We also have lots of graphs and charts and things, and not all data is created equal. So you don't have to, and definitely should not, include every single graph and chart that you generate from your data. Like a pie chart: very, very easy to read, very easy to understand and interpret what's going on. Whereas this ranking exercise, this rank distribution exercise, I did this so long ago I do not remember what it's about. I barely would be able to explain this even if I had done this study very recently, because it's something that requires a good deal of explaining. Whereas a pie chart is pretty easy to pick up and understand. So this is something I would be inclined to include in a study or a presentation, whereas the rank distribution is just something that we as researchers use to make decisions, and then we can interpret it and share the actual insights.

Consumable and actionable

[00:20:33] But one thing that's really important: you could have the most insightful research in the world, but it is not worth anything if it is not consumable and actionable. So if I share a bunch of rank distribution charts and it's not consumable or actionable, it doesn't mean anything to anybody. I could have done great research, but if people can't do anything with it, it's not helping anyone.

[00:20:56] So when you're putting together your findings and you're curating your insights, you're thinking of data visualizations, ask yourself: what action is this thing going to yield, and what result do I expect? If the answer is just, I think this is an interesting insight to throw in, there's no action, maybe don't put it into your presentation. I've had lots of scenarios where there have been very, very cool insights and very cool data visualizations, but when I ask myself what is someone going to do with this, and the answer sometimes is just, I don't know, it just looks cool, I always have to suck up my ego and put it aside and be like, this is just for me to have. Because it's not going to help anybody, it's just going to confuse people and add extra noise and take away from the message you're trying to convey.

Permission to say no

[00:21:45] But when you're delivering bad news and telling people no, I'm not going to lie, it totally sucks. It's really awkward. We love being people pleasers, at least I do. But it is our job as UX professionals to build products that are going to help people, not just stuff that we think is cool. So if you feel awkward telling someone no, if you feel awkward telling someone hey, this product is bad, just leave lots and lots of breadcrumbs and let other people, quote, decide. Come and form your own opinion. Decide what the outcome should be, and lead people there, because you have the data and it's your job to guide them to a decision.

[00:22:24] But at the end of the day, you are probably saving your company thousands, if not millions, of dollars by spotting an iceberg and raising the alarms. Think about how expensive it is to build a product. You have development costs, you have design, test, marketing, sales. Everything that goes into building a product and bringing it to the world is so expensive. So again, we would rather fail fast and fail cheap and raise the alarms, and save your company lots of money. If someone complains, you should say, you're welcome.

[00:22:59] Because I do not want you to feel guilty at all for raising alarms, raising red flags, because it is your duty as a UX researcher. And you 100% have permission to set boundaries at work and advocate for yourself and advocate for your users, and ultimately produce work that you are going to be proud of. At the end of the day, you have permission to say no if something does not suit you. You have permission to say no if a product should not be built, because that is your job. And at the end of the day you'll be serving your business much better.

Key takeaways

[00:23:35] All right. So, key takeaways before I leave you guys. Set very clear expectations in writing when you're building out a research plan or any type of plan. But play to the egos of humans, because we all have egos, and it'll help you build trust a little bit, because trust is going to be your big driver to help you move forward.

[00:23:56] Communicate very, very frequently and very clearly with your stakeholders as you move forward, even if the news is totally good. People love hearing good news, you can just sprinkle that in. Or if there's no update, just say no update. People like feeling in the loop. But make sure the study that you're conducting is airtight by involving the team and also incorporating some quantitative metrics in there.

[00:24:18] And when you're telling a story and you're sharing your insights, curating your findings is going to be key, again, to making sure that nobody pushes back and everybody trusts what you are saying. And then when you're doing that, you have to decide: am I going to tell people what they should do, or am I going to lead them to a decision that I've kind of already made? There's no wrong answer there, it is up to you. But again, you have permission to do the work that makes you proud, and you have permission to say no. Thank you, guys. I think we have time for questions. If not, you can hit me up on LinkedIn and ask me questions. But thank you. Bye.

Q&A

[00:24:53] Rory: Excellent, thank you very much, Tyler. That was really great. As you said, sharing the story made it a lot more interesting.

[00:25:01] Tyler: Thank you. Thank you.

[00:25:03] Rory: So if anybody has any questions out there, please write them in on whichever platform you're watching it on and I'll pass those questions through to Tyler. But the first one, I'm not sure if I missed it or something, but your vibe check example: you gave a lot of examples about how you give bad news at the end of the research, but how do you go about, in a nice way, without burning bridges, saying no, I'm not going to accept this because I don't think you're professional enough?

[00:25:33] Tyler: That's a great question. In this scenario with the vibe check, I really wanted to say no to the project, but there were some political reasons that my manager and I were like, you've got to do it. So I pushed back a little bit and I put this into my research proposal, where I basically said, I will do your vibe check, but I'm also going to get some other data that's going to help you guys in the long run, but it's going to make me much happier and feel like I'm doing a better job.

[00:26:02] Tyler: So I did a vibe check, but I was like, I'm also going to incorporate Likert scales, I'm going to incorporate some prioritization so that you guys can have some data. You're welcome. And they were like, we don't really want it. And I was like, well, you're just going to get some. And they ended up being happier after the study was done, and they were like, oh, okay. So just kind of pushing back, and you can sneak things into the study that will better suit the stakeholders without them realizing it. So be a little sneaky.

[00:26:36] Rory: And have you ever had to actually do a firm no?

[00:26:41] Tyler: Yeah. I was pulled into, I go to different lines of business, right? So I was pulled in to do research with this one line of business and I was immediately told to partner with their UX designers, which, I love UX designers, that's great. But the UX designers on that team were like, ooh, we want to do usability studies, because that team only knew that UX research equals usability studies. They didn't know that I had higher potential to do more strategic level work. So they were like, we're going to do these usability studies, we're so excited you're here. And I said, hold on, hold on.

[00:27:20] Tyler: I need you to tell me who your product managers are, and I want to start partnering with the product managers so I can do higher level strategy work, and I'm happy to support you doing your usability testing, but that should be something that you guys are owning and I'll be owning the strategy work. So I felt kind of bad, but yeah, I was like, no, but here's what I need instead. And it worked out, it worked out nicely. Did a very cool study.

[00:27:47] Rory: Excellent. Well, that actually brings us to time, Tyler. So I just want to thank you once again, Tyler.

[00:27:52] Tyler: Thank you so much.