Guest post by Lisa Regan, writer for The Lean Startup Conference.
If you build products or services, then having empathy for your users is part of your job. Good news: If you build products or services, then we have empathy for you. We talked with Laura Klein, a preeminent expert on user experience, about the questions she gets asked most often by other product pros. Laura is not only the author of UX for Lean Startup and the creator of the design blog Users Know, she’s also Head of Product at Hint Health, a software company working on healthcare affordability, and one of our most popular speakers. At this year’s Lean Startup Conference, she’s running a hands-on session teaching you how to validate your assumptions, explained below (the conference runs December 8 - 12 in San Francisco, and you can register here to attend in person or via livestream).
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 you 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.
LR: So that was one question that actually breaks out into two approaches. What else do people ask you?
LK: I get asked the difference between UX and UI a lot, and I see a lot of explanations of this online. Again, UI--user interface--is a subset of user experience design. I really like to think of UX as the umbrella for all of this stuff. But the UI is very much more about the layout and the heuristics and the visual design. It's about the flow. Are you going to give people one big screen, or are you going to give them three screens where they do something different on each one, or are you going to give them a walkthrough, or are you going to point out important things, or are you going to hide things from them until they become more involved?
If you're a Twitter user, is your first experience with Twitter just seeing a random list of tweets, or is it picking from a bunch of different topics that you're interested in, or is it finding your friends? What is Twitter about in that onboarding experience? How does that work? That's a crossover of UX and UI, and they definitely impact one another. I think that too many people focus too much on the UI part. They focus too much on the visual and the pretty, and just the layout of the screen, and they don't focus enough on what's the context in which the user is using this product? What's the flow? Where did the users come from? Who are these people? What are their needs? What is the reason that they are using your product, and what is the fastest way that you can fulfill that need for them?
Nobody ever says, "I want to use this product." Nobody's ever like, "I want to use a power drill," unless they just bought a power drill, and they might be like, "Let's see what I could use a drill for." But in general an owner of a power drill very rarely goes, "What can I drill a hole in today?" They have to put up a bookshelf, or put together a piece of IKEA furniture. They think, "You know what, I should totally get my power drill, because that's going to help me put together this furniture." So, what's the fastest way that you can get that bookshelf built? What's the fastest way that you could fill the need that prompted someone to use your product?
That's the context of the user, and that is very much about the user experience. Yeah, having a bad UI on a power drill is really dangerous, and it can totally prevent the user from fulfilling their need. But you can have a great UI that actually has a bad user experience. Because it can be a beautiful, really well laid-out, really nice-looking page that just doesn't fulfill a need for anybody or that dead-ends people. Or, where people are like, "This is beautiful. I don't know what to do." It's not that one is more important than the other; it's that one actually is just a part of the other. The UI is part of the general UX, and so I'm just getting very tired of people coming and saying, "We need a user experience designer, because our pages aren't pretty enough" or, "because things are laid very badly" or whatever. It's like, "That's a small portion of your problem."
I might look at something and go, "It's not the problem that your product page is laid out wrong; it's that when somebody puts something in their cart, they actually can't make it through to checkout because the checkout flow is really confusing, and it has all of these dead ends," or, "because if you go through the checkout flow, and then you jump out to get a new product, something bad happens." There's what I always call the "happy day flow" or the "sunny day flow." A sunny day flow is: I come to the product, I find something I love. I put it into my cart, I go through the checkout process, I put in my credit card number, and I buy it.
In the real-life flow for a lot of people, it's more like: I put something into the cart, I realize, "No I'd actually don't need that; I need something else." So I go back and get something and try to take the other thing out of my cart. I try to get two of this new thing. Then I go through, and I realize I don't have my credit card, I want to pay with Paypal, but then I realize it's a gift. Then I go back and I try to change the gift options and ship it to someplace else and suddenly, I'm lost. That's not just the user interface, that’s the user experience.
LR: Is the problem that the people designing the flow don't know that's how people behave? Or is the problem that they find it technically difficult to find solutions to all of these contingencies?
LK: Certainly it is much harder to design for the second thing. But realistically, I think one of the reasons that this happens is because lot of designers think from the screen. "Does this screen allow people to put their credit card information in?" "Yes." "Great, it's done." But they're not thinking about the actual user experience; they're not thinking through the whole list of human stories that could happen. They're not actually being user-centered. They're thinking, "What can I allow my user to do?" Don't allow your user to do anything. Show them what they're supposed to do. Help them do the thing that they want to do and that you want them to do. Understand that there will be problems as they do it, and that your design has to comfortably accommodate all of those edge cases to a certain extent.
LR: Talk about the relationship between edge cases and MVPs.
LK: A lot of times people ask me about MVP: “How do I know if my MVP is big enough?” The answer to that is, "Can you learn something from it?" Not just anything--we can all learn something from everything. But, can you learn the thing that you wanted to learn from it, specifically? The truth is that MVPs should solve very hard problems, but they should really only solve one problem. Like if you are a startup and you've got your first product, it should solve a serious problem. But it should solve one serious problem for one specific person.
If you're trying to solve a bunch of problems for a bunch of different people, you have increased the complexity of your product to the extent that you're going to run into that thing that I talked about before. You're going to run into all these edge cases and corner cases and, "What if they do this? What if they do that?" The more contained the problem that you're solving, the easier it is to account for all of those cases. So that you don’t get somebody who comes in with the right problem and they want to use your solution, but they have a really shitty experience doing it.
If you're building a product that allows people to buy something, maybe the first iteration of that, so that you can avoid all of that cart stuff, maybe the first iteration of that is that they come in, and they click a button, and they can buy one of those things. What you're trying to learn from that is: Are people interested in buying this particular thing? That's what you're trying to learn. They can come in and they can buy that thing, and maybe you store their payment information, so if they want to buy another one they can click the buy button again, and it will just buy it for them.
Maybe you avoid all of that business of put it in your cart, take it out of your cart, put it on your wishlist, buy something on your wishlist. Avoid that for now. You don't have to do that first. If what you are trying to learn is, do people want to buy this thing that I am selling, then make it as easy as possible for them to come in and buy that thing that you are selling. Don't necessarily make it possible for them to come in and do all of this other things with it. When Amazon started out, you could go in and you could buy a book. I shopped on the original Amazon. You could search for a book, you could pick a book and you could buy a book. That was it. It's gotten a little bigger since then.
Just because I'm talking about building a very small thing that only does one thing, it does not mean you're going to launch that to the entire world. The entire world is not going to look at it and go, "It only does one thing; I’m not interested." You're going to show it to a small number of people. You're going to get feedback. You're going to iterate. You're probably going to hear the same thing, "Why doesn't it have a wishlist?” That’s fine. You're not worried about that yet. You're worried about getting the interaction of this one thing correct. Then you could add in the other things. Adding in the other things later really helps you to manage the complexity of the design.
LR: It sounds simple, but let's say you're not doing a shopping cart-driven business. How do you know which complexities of your model you can just set aside for now?
LK: At that point, it's all about early user research and customer development. You have to know really, really clearly what problem you're solving, and for whom you are solving it. The kinds of problems that you are looking to solve in an early early, early product are not things like, "I would like to reduce energy usage among US households." Too big. "I would like to save time for moms." Too big. That is not a specific, addressable problem for an individual human being that you can identify. Moms are not an early adopter group. Some moms are, but there are too many of them. Mine is not like yours. That's not a persona; that's not a group I can define for. They have too many very different types of problems, depending on who they are, where they are, and what they like, dislike, and what technology they're using, what their jobs are.
By narrowing it down to a very specific small user group with a very specific problem, you will be able to narrow down that initial product or that MVP to something very specific. Facebook always is the good example of this. It started for Harvard students to look at pictures of other students. That's what it did; that was the whole thing. They didn't start out being whatever the hell they are now--an advertising platform and a gaming platform and a way to keep in touch with everybody you've ever met and a way to follow celebrities. No. None of that. Harvard students looking at pictures of other Harvard students. You don't have to start big to get big.
LR: So interestingly, the best thing to do for improving your user interface is to strip a bunch of stuff off your website?
LK: I honestly think that's why the whole mobile-first thing is so popular, because all mobile-first really means, if you really look at the design ethos behind mobile-first, the reason people go mobile-first is because mobile forces you to make every screen about something very specific. You can't add shit into a mobile interface. You have five inches; make the most of it. That means every single interface, every single thing is about one cold action. It's about one message, at least the successful ones. You could take a picture and you could post a picture, and it's got to go in that order. Those are the successful ones-–that every single screen is about solving a very specific problem within the user experience. It's not about allowing people to do whatever they want; it's about showing people what to do to be successful.
I think there's a really nice method for doing this, which is imagine your successful customer. Don't just imagine them, use metrics to figure out who they are. What have you helped them become? If you're doing tax preparation software, your successful user has successfully filed their taxes without tearing their hair out. Maybe you've been able to show them that they've saved a certain amount of money by doing it. How do you get them from the person who thinks, "Shit, I need to file my taxes," to the person who has filed their taxes? You have to start from imagining who your successful, happy user is. Then you can tell them how to get there. You don't let them get there; you help them get there. You show them the path.
You start even before you have a product. You talk to the people who had the problem that you think you're solving. You understand what they've tried to do to solve it in the past. This is actually a question that I get a lot, which is, "How do you figure out what the user’s needs actually are?" You reach out to people who you think will have this problem, and you have conversations with them. You don't pitch them your solution; you just have conversations with them about their problem. You see what other things they have tried, because here's the thing. If they've got a problem and they have tried in the past to solve it and they have failed, they are a great market. Much easier to sell into that market, where people already know that they want your product.
Then you go back to them afterwards and you see how they're doing with your stuff. You also go back to the people who have tried your stuff and given it up to understand what promise you didn't fulfill to them. "Why did you try this product? What were you hoping to get? What did it did not do for you? Why did you stop using it?"
If you talk to five people who are really similar to one another, you should start to see patterns. If you do not start to see patterns, then you may need to narrow down the type of people you're talking to. There is another question I hear a lot, "How many people do I need to talk to learn something?" Well, you need to talk to enough people to where you're seeing patterns. If you are not seeing patterns within about five people, you are talking to too broad a group. Again, you may be going out talking to moms. Don't talk to moms.
One way to narrow the people you’re talking to is to use screeners. These are surveys that actually help you recruit for user research people that you think would like your product. You can write your own screener, or you can hire a recruiting agency that will go out and find people in very specific groups. But you're trying to identify the people that you think are going to use your product. You write the screeners in such a way that you're asking about behavioral things. You're not asking them necessarily about things that are directly related to product design. And you're not looking for just like 35- to 45-year-old men who smoke and read GQ.
Again, if you're making tax preparation software for accountants you might ask what their job was. You're only going to pick the ones who are accountants. But it may be that you think that your market is accountants who do taxes for a lot of small businesses, maybe even in a particular industry. That might be accountants who handle the taxes for restaurants. That's a market that you can imagine. You would go out and write a screener that would help you recruit people like that. You would try to weed out all the people who didn't do taxes for restaurants or who only did taxes for big companies or who worked in-house at big companies or whatever.
So then you get five of those people, and you do interviews with them about their needs, their problems, or maybe you show them your product and you see if it solves a problem for them. If you can record ten of those talks and do the same interview with them and hear the same significant problem from nine of them and it's a problem you could solve, that's excellent confirmation that you're onto something. That's a pattern. Like, if they all have a problem with getting the restaurants to file quarterlies on time or whatever. If you start to see that pattern, that is a problem that is worth solving. Especially if it is a pattern where they are like, "Urgh, I have this terrible problem. I've tried to solve in at least three ways, I've paid for solutions, they never worked. I'm just doing it all on Excel, because it's super hard. It's really manual." That is worth solving.
LR: Is there something nobody ever asks you, that you think, "People ought to ask me this," or, "People should want to know this, and yet they don’t ask”?
LK: People often ask UX questions in the wrong way. In general, the questions that people ask about UX are too broad. They're like, "How do I user research?" Not, "How do I learn this specific thing about this particular user?" If you asked me how to do user research, I would launch into, as you saw, a lot of talk about needing to figure out who your user is and what you’re going to learn, and so on. But once you've gotten there, if can come to me with, "I have this particular question that I want to learn about this person, and it's very specific. How do I do that?" that’s framing things in a much more specific way. And that’s also telling you that, if can frame things in a more specific way, you've arrived somewhere more detailed.
LR: One last question: What are you going to speak on at this year’s Lean Startup Conference?
LK: I'm doing my talk on validating assumptions in order to build better products. This idea is really core to Lean Startup. My approach is very hands-on, teaching people a particular skill and a method for figuring out what assumptions they are making when they are deciding to build a product.
What I’ve found is that if you make the wrong assumption too early, you then build a lot of things on that assumption, and it's like building your house on quicksand. I see an awful lot that people go into building a product and they specifically make assumptions like, "Well, I just assume that people have this problem that I'm solving." It turns out that if they don't, or not enough people have it, or if it's the wrong people who have it and it's not the people that you're going after, then this thing that might have been really easy to correct before you build a product becomes really hard to fix. So, that's what I'm talking about: how to identify those things and how to think about them, and I actually have a test people can take.
LR: I love a test! Ok, so you’re going to be speaking on validating assumptions, but much of your work is in UX. It sounds like your talk is going to be more broadly Lean Startup?
LK: So, here’s how I think about it. I've done a lot of dance in my life, and I know a whole bunch of different types of dance. I was talking to a dance teacher about different styles, and she was like, "At some point, after you know a bunch of different styles and you're just used to it, it's all just dancing.” There is no Lindy, or salsa, or even ballet. It's all just dancing.
This is how I'm starting to think about product: it's all just product. To me, it's all just the user experience, because the user experience to me covers literally everything. The user experience is the user's entire interaction with your product and company. If you think about something like Uber--however you feel about Uber--the experience of being in an Uber is not just the Uber app, and it's not just the rider. It's also the driver, and it's also the service of the cab company you’re not using. There's a whole experience with the company. There's the time in the car. There's the time waiting for their car. There's the time when you get the email afterwards telling you how much the car cost. There's figuring out who's paying for it. Really, there's this entire experience that exists around what a lot of people consider to be the product. But, what's the product there? I stopped thinking about it as, "There's product and there's user experience and there is customer experience.” It's all just user experience.
--
Laura has a very useful PDF available for $10, "How To Recruit Participants For User Research/UX Tests." To learn from Laura and many other great speakers at The Lean Startup Conference, register today to attend in person or via livestream.
If you build products or services, then having empathy for your users is part of your job. Good news: If you build products or services, then we have empathy for you. We talked with Laura Klein, a preeminent expert on user experience, about the questions she gets asked most often by other product pros. Laura is not only the author of UX for Lean Startup and the creator of the design blog Users Know, she’s also Head of Product at Hint Health, a software company working on healthcare affordability, and one of our most popular speakers. At this year’s Lean Startup Conference, she’s running a hands-on session teaching you how to validate your assumptions, explained below (the conference runs December 8 - 12 in San Francisco, and you can register here to attend in person or via livestream).
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 you 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.
LR: So that was one question that actually breaks out into two approaches. What else do people ask you?
LK: I get asked the difference between UX and UI a lot, and I see a lot of explanations of this online. Again, UI--user interface--is a subset of user experience design. I really like to think of UX as the umbrella for all of this stuff. But the UI is very much more about the layout and the heuristics and the visual design. It's about the flow. Are you going to give people one big screen, or are you going to give them three screens where they do something different on each one, or are you going to give them a walkthrough, or are you going to point out important things, or are you going to hide things from them until they become more involved?
If you're a Twitter user, is your first experience with Twitter just seeing a random list of tweets, or is it picking from a bunch of different topics that you're interested in, or is it finding your friends? What is Twitter about in that onboarding experience? How does that work? That's a crossover of UX and UI, and they definitely impact one another. I think that too many people focus too much on the UI part. They focus too much on the visual and the pretty, and just the layout of the screen, and they don't focus enough on what's the context in which the user is using this product? What's the flow? Where did the users come from? Who are these people? What are their needs? What is the reason that they are using your product, and what is the fastest way that you can fulfill that need for them?
Nobody ever says, "I want to use this product." Nobody's ever like, "I want to use a power drill," unless they just bought a power drill, and they might be like, "Let's see what I could use a drill for." But in general an owner of a power drill very rarely goes, "What can I drill a hole in today?" They have to put up a bookshelf, or put together a piece of IKEA furniture. They think, "You know what, I should totally get my power drill, because that's going to help me put together this furniture." So, what's the fastest way that you can get that bookshelf built? What's the fastest way that you could fill the need that prompted someone to use your product?
That's the context of the user, and that is very much about the user experience. Yeah, having a bad UI on a power drill is really dangerous, and it can totally prevent the user from fulfilling their need. But you can have a great UI that actually has a bad user experience. Because it can be a beautiful, really well laid-out, really nice-looking page that just doesn't fulfill a need for anybody or that dead-ends people. Or, where people are like, "This is beautiful. I don't know what to do." It's not that one is more important than the other; it's that one actually is just a part of the other. The UI is part of the general UX, and so I'm just getting very tired of people coming and saying, "We need a user experience designer, because our pages aren't pretty enough" or, "because things are laid very badly" or whatever. It's like, "That's a small portion of your problem."
I might look at something and go, "It's not the problem that your product page is laid out wrong; it's that when somebody puts something in their cart, they actually can't make it through to checkout because the checkout flow is really confusing, and it has all of these dead ends," or, "because if you go through the checkout flow, and then you jump out to get a new product, something bad happens." There's what I always call the "happy day flow" or the "sunny day flow." A sunny day flow is: I come to the product, I find something I love. I put it into my cart, I go through the checkout process, I put in my credit card number, and I buy it.
In the real-life flow for a lot of people, it's more like: I put something into the cart, I realize, "No I'd actually don't need that; I need something else." So I go back and get something and try to take the other thing out of my cart. I try to get two of this new thing. Then I go through, and I realize I don't have my credit card, I want to pay with Paypal, but then I realize it's a gift. Then I go back and I try to change the gift options and ship it to someplace else and suddenly, I'm lost. That's not just the user interface, that’s the user experience.
LR: Is the problem that the people designing the flow don't know that's how people behave? Or is the problem that they find it technically difficult to find solutions to all of these contingencies?
LK: Certainly it is much harder to design for the second thing. But realistically, I think one of the reasons that this happens is because lot of designers think from the screen. "Does this screen allow people to put their credit card information in?" "Yes." "Great, it's done." But they're not thinking about the actual user experience; they're not thinking through the whole list of human stories that could happen. They're not actually being user-centered. They're thinking, "What can I allow my user to do?" Don't allow your user to do anything. Show them what they're supposed to do. Help them do the thing that they want to do and that you want them to do. Understand that there will be problems as they do it, and that your design has to comfortably accommodate all of those edge cases to a certain extent.
LR: Talk about the relationship between edge cases and MVPs.
LK: A lot of times people ask me about MVP: “How do I know if my MVP is big enough?” The answer to that is, "Can you learn something from it?" Not just anything--we can all learn something from everything. But, can you learn the thing that you wanted to learn from it, specifically? The truth is that MVPs should solve very hard problems, but they should really only solve one problem. Like if you are a startup and you've got your first product, it should solve a serious problem. But it should solve one serious problem for one specific person.
If you're trying to solve a bunch of problems for a bunch of different people, you have increased the complexity of your product to the extent that you're going to run into that thing that I talked about before. You're going to run into all these edge cases and corner cases and, "What if they do this? What if they do that?" The more contained the problem that you're solving, the easier it is to account for all of those cases. So that you don’t get somebody who comes in with the right problem and they want to use your solution, but they have a really shitty experience doing it.
If you're building a product that allows people to buy something, maybe the first iteration of that, so that you can avoid all of that cart stuff, maybe the first iteration of that is that they come in, and they click a button, and they can buy one of those things. What you're trying to learn from that is: Are people interested in buying this particular thing? That's what you're trying to learn. They can come in and they can buy that thing, and maybe you store their payment information, so if they want to buy another one they can click the buy button again, and it will just buy it for them.
Maybe you avoid all of that business of put it in your cart, take it out of your cart, put it on your wishlist, buy something on your wishlist. Avoid that for now. You don't have to do that first. If what you are trying to learn is, do people want to buy this thing that I am selling, then make it as easy as possible for them to come in and buy that thing that you are selling. Don't necessarily make it possible for them to come in and do all of this other things with it. When Amazon started out, you could go in and you could buy a book. I shopped on the original Amazon. You could search for a book, you could pick a book and you could buy a book. That was it. It's gotten a little bigger since then.
Just because I'm talking about building a very small thing that only does one thing, it does not mean you're going to launch that to the entire world. The entire world is not going to look at it and go, "It only does one thing; I’m not interested." You're going to show it to a small number of people. You're going to get feedback. You're going to iterate. You're probably going to hear the same thing, "Why doesn't it have a wishlist?” That’s fine. You're not worried about that yet. You're worried about getting the interaction of this one thing correct. Then you could add in the other things. Adding in the other things later really helps you to manage the complexity of the design.
LR: It sounds simple, but let's say you're not doing a shopping cart-driven business. How do you know which complexities of your model you can just set aside for now?
LK: At that point, it's all about early user research and customer development. You have to know really, really clearly what problem you're solving, and for whom you are solving it. The kinds of problems that you are looking to solve in an early early, early product are not things like, "I would like to reduce energy usage among US households." Too big. "I would like to save time for moms." Too big. That is not a specific, addressable problem for an individual human being that you can identify. Moms are not an early adopter group. Some moms are, but there are too many of them. Mine is not like yours. That's not a persona; that's not a group I can define for. They have too many very different types of problems, depending on who they are, where they are, and what they like, dislike, and what technology they're using, what their jobs are.
By narrowing it down to a very specific small user group with a very specific problem, you will be able to narrow down that initial product or that MVP to something very specific. Facebook always is the good example of this. It started for Harvard students to look at pictures of other students. That's what it did; that was the whole thing. They didn't start out being whatever the hell they are now--an advertising platform and a gaming platform and a way to keep in touch with everybody you've ever met and a way to follow celebrities. No. None of that. Harvard students looking at pictures of other Harvard students. You don't have to start big to get big.
LR: So interestingly, the best thing to do for improving your user interface is to strip a bunch of stuff off your website?
LK: I honestly think that's why the whole mobile-first thing is so popular, because all mobile-first really means, if you really look at the design ethos behind mobile-first, the reason people go mobile-first is because mobile forces you to make every screen about something very specific. You can't add shit into a mobile interface. You have five inches; make the most of it. That means every single interface, every single thing is about one cold action. It's about one message, at least the successful ones. You could take a picture and you could post a picture, and it's got to go in that order. Those are the successful ones-–that every single screen is about solving a very specific problem within the user experience. It's not about allowing people to do whatever they want; it's about showing people what to do to be successful.
I think there's a really nice method for doing this, which is imagine your successful customer. Don't just imagine them, use metrics to figure out who they are. What have you helped them become? If you're doing tax preparation software, your successful user has successfully filed their taxes without tearing their hair out. Maybe you've been able to show them that they've saved a certain amount of money by doing it. How do you get them from the person who thinks, "Shit, I need to file my taxes," to the person who has filed their taxes? You have to start from imagining who your successful, happy user is. Then you can tell them how to get there. You don't let them get there; you help them get there. You show them the path.
You start even before you have a product. You talk to the people who had the problem that you think you're solving. You understand what they've tried to do to solve it in the past. This is actually a question that I get a lot, which is, "How do you figure out what the user’s needs actually are?" You reach out to people who you think will have this problem, and you have conversations with them. You don't pitch them your solution; you just have conversations with them about their problem. You see what other things they have tried, because here's the thing. If they've got a problem and they have tried in the past to solve it and they have failed, they are a great market. Much easier to sell into that market, where people already know that they want your product.
Then you go back to them afterwards and you see how they're doing with your stuff. You also go back to the people who have tried your stuff and given it up to understand what promise you didn't fulfill to them. "Why did you try this product? What were you hoping to get? What did it did not do for you? Why did you stop using it?"
If you talk to five people who are really similar to one another, you should start to see patterns. If you do not start to see patterns, then you may need to narrow down the type of people you're talking to. There is another question I hear a lot, "How many people do I need to talk to learn something?" Well, you need to talk to enough people to where you're seeing patterns. If you are not seeing patterns within about five people, you are talking to too broad a group. Again, you may be going out talking to moms. Don't talk to moms.
One way to narrow the people you’re talking to is to use screeners. These are surveys that actually help you recruit for user research people that you think would like your product. You can write your own screener, or you can hire a recruiting agency that will go out and find people in very specific groups. But you're trying to identify the people that you think are going to use your product. You write the screeners in such a way that you're asking about behavioral things. You're not asking them necessarily about things that are directly related to product design. And you're not looking for just like 35- to 45-year-old men who smoke and read GQ.
Again, if you're making tax preparation software for accountants you might ask what their job was. You're only going to pick the ones who are accountants. But it may be that you think that your market is accountants who do taxes for a lot of small businesses, maybe even in a particular industry. That might be accountants who handle the taxes for restaurants. That's a market that you can imagine. You would go out and write a screener that would help you recruit people like that. You would try to weed out all the people who didn't do taxes for restaurants or who only did taxes for big companies or who worked in-house at big companies or whatever.
So then you get five of those people, and you do interviews with them about their needs, their problems, or maybe you show them your product and you see if it solves a problem for them. If you can record ten of those talks and do the same interview with them and hear the same significant problem from nine of them and it's a problem you could solve, that's excellent confirmation that you're onto something. That's a pattern. Like, if they all have a problem with getting the restaurants to file quarterlies on time or whatever. If you start to see that pattern, that is a problem that is worth solving. Especially if it is a pattern where they are like, "Urgh, I have this terrible problem. I've tried to solve in at least three ways, I've paid for solutions, they never worked. I'm just doing it all on Excel, because it's super hard. It's really manual." That is worth solving.
LR: Is there something nobody ever asks you, that you think, "People ought to ask me this," or, "People should want to know this, and yet they don’t ask”?
LK: People often ask UX questions in the wrong way. In general, the questions that people ask about UX are too broad. They're like, "How do I user research?" Not, "How do I learn this specific thing about this particular user?" If you asked me how to do user research, I would launch into, as you saw, a lot of talk about needing to figure out who your user is and what you’re going to learn, and so on. But once you've gotten there, if can come to me with, "I have this particular question that I want to learn about this person, and it's very specific. How do I do that?" that’s framing things in a much more specific way. And that’s also telling you that, if can frame things in a more specific way, you've arrived somewhere more detailed.
LR: One last question: What are you going to speak on at this year’s Lean Startup Conference?
LK: I'm doing my talk on validating assumptions in order to build better products. This idea is really core to Lean Startup. My approach is very hands-on, teaching people a particular skill and a method for figuring out what assumptions they are making when they are deciding to build a product.
What I’ve found is that if you make the wrong assumption too early, you then build a lot of things on that assumption, and it's like building your house on quicksand. I see an awful lot that people go into building a product and they specifically make assumptions like, "Well, I just assume that people have this problem that I'm solving." It turns out that if they don't, or not enough people have it, or if it's the wrong people who have it and it's not the people that you're going after, then this thing that might have been really easy to correct before you build a product becomes really hard to fix. So, that's what I'm talking about: how to identify those things and how to think about them, and I actually have a test people can take.
LR: I love a test! Ok, so you’re going to be speaking on validating assumptions, but much of your work is in UX. It sounds like your talk is going to be more broadly Lean Startup?
LK: So, here’s how I think about it. I've done a lot of dance in my life, and I know a whole bunch of different types of dance. I was talking to a dance teacher about different styles, and she was like, "At some point, after you know a bunch of different styles and you're just used to it, it's all just dancing.” There is no Lindy, or salsa, or even ballet. It's all just dancing.
This is how I'm starting to think about product: it's all just product. To me, it's all just the user experience, because the user experience to me covers literally everything. The user experience is the user's entire interaction with your product and company. If you think about something like Uber--however you feel about Uber--the experience of being in an Uber is not just the Uber app, and it's not just the rider. It's also the driver, and it's also the service of the cab company you’re not using. There's a whole experience with the company. There's the time in the car. There's the time waiting for their car. There's the time when you get the email afterwards telling you how much the car cost. There's figuring out who's paying for it. Really, there's this entire experience that exists around what a lot of people consider to be the product. But, what's the product there? I stopped thinking about it as, "There's product and there's user experience and there is customer experience.” It's all just user experience.
--
Laura has a very useful PDF available for $10, "How To Recruit Participants For User Research/UX Tests." To learn from Laura and many other great speakers at The Lean Startup Conference, register today to attend in person or via livestream.
