Every time user experience expert Laura Klein gives a talk, she’s asked, “How do I get my coworkers to understand that what I do is important?”
Her insightful answer is below, excerpted from a recent interview with Lisa Regan for Eric Ries’s blog; you can read the full interview here. Laura is the author of UX for Lean Startups, creator of the design blog Users Know, and Head of Product at Hint Health, a software company working on healthcare affordability.
Lisa is a writer for both The How and The Lean Startup Conference.
Lisa Regan: So what are some of the questions people most often ask you, and what advice do you give?
Laura Klein: Here’s one question that I’m going to share with you not because it’s the most important one, but because it is the one that I get asked, I think, in every single talk I ever give that has anything to do with research. The question is, “How do I get people at my company to understand that what I do is important? How do I get them to see the value of User Experience research or design?”
The answer that I used to give, which I think was not very helpful but was how I felt, was, “Quit and join someplace that actually understands what you do, because they’re going to win in the end anyway.” But I think the right answer—assuming that first answer is not an option or that you just enjoy tilting at windmills—is to find a way to treat the other people at your company as themselves being users of your research. Just as you would with a customer, you need to understand their needs better.
First, you need to find a way to have them experience what their customers are actually going through. Often, a good way to do this is with video. So you would just go ahead and do that user research yourself, figuring out a fast way that you, on your own, can capture that information and then share those little snippets with the people that you need to convince. Nothing is more impactful than actually seeing what you are putting your customers through. Because it’s very easy to ignore that or not fully accept that there are problems with your product, but seeing person after person after person struggle with the same thing is incredibly impactful. So that’s an excellent way of doing it.
But I think that another thing to do is to understand why they don’t care about this. Is it because they don’t understand the value of it? In which case something like showing a video of people struggling with the product, and then showing video of people not struggling with it after it’s been fixed, can be incredibly helpful. Is it because they’ve had a bad experience in the past with research? I think then the answer is to help them understand ways to do research or design that aren’t what they’ve experienced in the past. Maybe they worked with a really big agency that charged them a huge amount of money and gave them really crappy results. I’ve run into this. Maybe they’re just like, “We don’t have time for this.” I hear this all the time, “We don’t have time for research.” At that point, you really have to explain to them that they don’t have time to not do research—because it takes a lot longer to fix it later than it does to fix it before it’s built.
LR: Do you think people just don’t want to hear what they already know to be true?
LK: There’s also that, and I think this happens a lot, honestly. This happens whenever people are rushing to get new features out, and they’re ignoring the old product. There’s, “We already know about the product problem. We already know about that. We’ve heard about that.” At that point, you really actually need to show them the impact that the bug is having on their bottom line. In that case, metrics and analytics are really important. “Hey, look, look at the funnel. You’re spending all this money to get people into the product, and they’re all dropping out here, and we’ve identified why they’re all dropping out here. This problem that you’ve been ignoring for a year, that I know you are totally used to, is costing you X amount of money or X number of users. This is a quantifiable problem.” If they’re real numbers-driven people, then that’s a good way of getting to them.
But again, I think the way to figure out how to change people’s minds within your organization is to understand them better. User experience people, we are trained to have empathy, or at least try to fake it, but we can understand. That is always our goal. We need to understand our users, and we need to understand our own problems. Apply that within your company, apply that to your engineers. I’m a big advocate for having empathy for your engineers. Understand what their needs are in terms of what you’re delivering to them, and they will be much better about implementing the things that you’re asking for. Understand and have empathy for your managers. Understand what they’re getting judged on and what their role in the organization is, and understand how to make them better at their jobs, and they will be much better about helping you do what you need to do.
This seems a little bit off the topic, but it’s around this concept of, how do I convince people that what I’m doing is important? I think the answer is that you give them not more deliverables or not more exact deliverables, but you understand what they need to see from you, and you deliver that. That’s a very user experience way of looking at things.
LR: What’s something that the product team would need to see? What’s an example of what that would look like?
LK: I just joined the team I’m working with as Head of Product a couple of months ago, and I’ve been working very closely with the engineering team. In fact, I have to tell them what to build, because part of the Head of Product’s job is to be sure that they’re building the right things. So the first thing that I did when I came in and sat down with them was I looked at how they’re currently working and I basically asked them, “What do you need from me to be successful?”
To get an answer to that, I would show them different levels of deliverables. For example, I would show them various works in progress. The last thing that I’m ever going to deliver to an engineering department is a pixel-perfect set of Photoshop mock-ups and just be like, “Here, implement this exactly.” That’s pretty much never the right thing. So I was like, “What level do you guys want to work at?” I would show them, “Here’s a task flow of when something happens. Then here’s some human-readable user stories that document everything that could possibly happen in this situation, and here’s a sketch with some notes on the side. Which of these–or is it some combination of these–will help you when you’re sitting down and writing the code? Also, by the way, I’m standing right here. I’m not away at a desk. I’m right here, a foot away. Literally turn around, tap me on the shoulder, and ask me a question.”
What we ended up with is that we use some combination of all of these kinds of things, including interactive prototypes sometimes, sometimes sketches with annotations, and sometimes test flows, and sometimes user stories, and sometimes sitting down and working through an error case together. We use a combination of all of these things to produce the different features. Depending on the feature, they get something different. Because it depends on if it’s a little thing, or a big thing, or a very complicated human interaction. They don’t just get the deliverable that I want to give them. It’s never that. They get the thing that they need in order to move forward and be successful on the first try.
The funny thing is that, with my team, I haven’t had to resort to showing them videos of the users. I probably won’t have to do that, because they are incredibly empathetic, and they see all the customer service emails that come in. They care deeply about the users already. So, I don’t have to convince them that users are important. But I think in a lot of engineering teams—not mine, luckily—but in a lot of engineering teams, especially at big companies, they can feel very removed from what the customer actually wants. So the design deliverables that you give them have to be quite explicit, because they are not necessarily going to have the framework for making good decisions about the user on their own. The right approach to that is to help them get closer to the user, because if they understand the user’s needs they will make better decisions on their own, because they will make them by thinking about the user. So I figure out what deliverables I can give them that will be the most useful will help them to make the right decisions.