Lessons

Lesson Info

Design Research

The first and arguably most important step is doing your researcher, AKA understanding the problem. So, I mean it kinda makes sense, right? You can't do good design unless you know who you're designing for. No matter how skillful or creative the designer is, if the designer doesn't have clear and detailed knowledge of the people that they're designing for, and of the problems constraints, and the business and organizational goals that are driving the design, they will have a little chance of success. If you don't do research, you don't have anything to base your designs on. All you have is opinions then, right? So then you'll end up having a lot a of... If you don't have research, you don't have any data, you end up having a lot of debates that work where it's like, "Oh, I like this. "Well, I like this." and then person who's better at debating ends up winning, versus solving a problem for the people that you're trying to design for. Research usually goes in this order. So, and it's so...

rt of like everything is leading up, these first three steps don't involve other people all that much, and they're leading up to the interviews, and everything sort of culminates interviewing the the actually users. So, in the kickoff meeting, it's not technically a research activity, but it contains an important component of research. So, this is an opportunity for designers to ask something initial key questions of some of the most important stakeholders at the meeting. And those questions may seem basic, but they give you some insight into not only the product itself, but also into how stakeholders think about the product, how they think about their users, and how they think about themselves and their competitors. So, those are like some of the questions that you'll wanna ask in that first meeting. When people approach you and they're like, "Hey, we wanna make this thing." and you sit down with them. It's like an initial one-hour meeting with all the people who are responsible for making decisions, all of the stakeholders. These are like some sample questions that you can ask them to get that conversation going. So after that initial conversation, the next step that makes the most sense in most cases is doing a literature review, and that really just means looking at all of the internal, everything that's out there related to the product and the company, you're looking at it, right? So you're looking at internal documents like brochures, marketing plans, brand strategy. You're going on line and looking in the news, what people are saying about this company and about this product. Like there's really cool tool by Google. It's called Keyword Planner, Google Keyword Planner. And with that tool, you can see what search terms people are searching for. So you can use that to see what people are searching for in relation to this product that you're trying to design or redesign, and that can then lead to some interesting insights too. The point of all of this is, you remember that the designer's job is to fill that gap between the system and the interaction model. And in order to do that, you just need to know the system really well. So that's why the goal of this initial research before you end up designing a product is to become, well, if not an expert, then very, very literate in the stakeholder's business and what the problems are that you're trying to solve. So, first, you talk to them in a kick-off meeting, then you look at all the literature that's out there. Then you look at the product itself. You can do that sort of in tandem with the literature review or not, but you look at, "Okay, what's the product "that we currently have? "How does it work?" Try using it yourself. And then also look at what some of the competing products are. In that first interview, you learn what some of the competitors are, if you didn't know already. So you know, it's like... Okay, let me give you a specific example. If you're redesigning a website that sells shoes. One of the first steps you would do to sign up for that site and try to order a pair of shoes and notice what goes well about that process and what goes badly about that process, and then you compare it to some other shoe sites. You go to Zappos, you go to Designer Shoe Warehouse and see how it works there, what are the similarities, what are the differences. And that way you build up knowledge about the product that you're designing and also about the space as a whole. All of this stuff that you're doing is leading up to the interviews. And the reason you do it in this order is because what you really don't wanna do is go into an interview with the business partners and ask them questions that you could've answered yourself with 30 seconds of Googling, because that makes you look really bad, right? So, that's why you do all of these research that you can do yourself first. And then when you've studied yourself full of research, you can go in with some really, really good question for the stakeholders. So what are stakeholders? A stakeholder is someone who has a stake in the project, and those are typically executives, managers, people from development, sales, product management, support. Those people that are in some way or another related to the project. It's not just the decision makers, although those are the most important ones. And I would say that it's most effective to interview these people one on one. Because if you get them in a group setting, one or two people will end up dominating the conversation more than others. And if you get them one on one, you get each person's individual take, and you'll see some of the... It promotes more honesty, more candor, and you can see where the similarities and differences are, and how different departments see the direction of this product going, it's really, really interesting to know. So, some questions you wanna ask your stakeholders are, what's your vision for this project? Are there any budget constraints, any schedules, any deadlines we need to hit? Any existing technology we need to consider? A lot of times when you're working with, especially when you're working with big companies, it happens very rarely these days that as a designer you have a chance to create something new from scratch. There will almost always be something there already and you need to take that knowledge and technology base into consideration. Then of course, what are the business goals? And what do you stakeholders know about your users? There are some stakeholders that are really helpful in finding out more about users, people that, customer support representatives, people that work in sales. You know what, in a lot of projects, everybody always talks about interviewing users, and that's useful if you have the time and the budget to do it, but a lot of times you don't. And in those case, the next best thing is to talk to people that have that connection to users, right? So, those are really important people to interview. And the reason you're doing this, and the reason you're doing this early on, besides getting information, is that as a designer it's your job to develop a vision that the entire team believes in, right? Your like this conduit that's taking in all this information, all of these different sides and turning it into something new. And you can only do that if you talk to everyone, and you try to understand everyone's perspective and you also understand the system really well and the people really well. And then after you feel like gobbled up all of this info, you can start turning it into a new solution. And if you don't do that, if you don't talk to everyone... People like to be involved, right? It's good to involve everyone early. If you don't involve them early, it's much more likely that they will block you later on, right? So, if you don't ask for people's opinions up front, there's a chance they'll force it on you later. The next step is subject matter interviews, subject matter expert interviews. So subject matter experts aren't really stakeholders. I mean they're different from stakeholders, like they work in the domain, but they're not directly involved in the project. So for example, if you're redesigning medical device software, right, a subject matter expert would be someone who trains nurses in how to use that software. So they're not like, they know the product really well, they talk to the users a lot, but they're not directly involve din the project's success. Or if you're redesigning a hiring software, a stakeholder will be someone like the CEO, or the product manager, or the engineers, while the a subject matter expert would be someone who sells the software or trains others in the software. So they know it well, and they use it often, and they also have contact with regular users. So, subject matter experts are really important when you're working in spaces that are highly technical. Because you as a designer, you're an expert at design, but you're not necessarily an expert of the problem space that you're entering. I've worked in a lot of different problem spaces. I've worked in gaming, in telecommunications, in automotive, and retail, and every time you go in knowing how to design for people, but not knowing really anything about that space, so one of the first things you need to do is gather information. And the fastest way to gather that information is from people who are already deep in that subject. So, a lot of times I'll even do... A lot of times I'll talk to subject matter experts before the stakeholders or somewhere around the same time. It's really Imp in real projects to have access to someone who knows the field so well that whenever you run into a wall while you're designing, you can just ask them a question really quick. All the projects that I've worked on that went really well, I had someone like that. So, finally, the user interviews. And user interviews, these are the people that are going to prospect, the people that are going to use the product or that are currently using the product. And you want to understand them as well as you can. Sort of what's their context? How does it fit into their life? You understand what they're trying to accomplish, what their goals are, everything that we've talked about so far, you find out through interviewing people, or even better than interviewing them is observing them. So, the reason... Yeah, so the two primary methods of finding out about users is asking them and watching them. And observing them is way more effective because most people are notoriously bad at assessing their own behavior and what makes them happy. There has been cases where you'll watch someone fiddle with an interface for five minutes and trying to get something done and they can't get it done. It's take them five minutes, just clearly struggling. And afterwards, you give them a questionnaire where one of the question is, did you find this task easy or hard? And they click easy even though it was clearly hard for them to do, because otherwise it wouldn't have taken them five minutes. And that's something that you find out quickly by watching them, that you don't find out by sending out a questionnaire. And you know, a lot of people fear seeming dumb, or incompetent, or impolite, so they might not tell you the truth about this product that they're using just out of fear of social retribution or because you put in so much work already into the solution. But if you're watching people use it and you see that they're having problems, it's much, much more effective. So for user observations, I would try avoiding the camera and audio recorders, because as soon as there is a camera in the room, people start behaving differently, right? They try to start showing their best version of themselves, rather than their natural version of themselves. So, typically, I found just going in with a notebook and listening closely and watching closely, that works better. And when I use a camera, it's just to capture a... Only after there's been a lot of comfort established already with the person. And then it's just sort of to take pictures of certain things that I find interesting in their environment, or that will help me remember something in particular about this user. The next thing is you wanna watch users in their context, right? So you don't want to invite in people to a usability lab with cameras and a two-way mirror and a helmet that they put on that tracks their eyes. I mean it'll yield results, but it's not gonna yield natural results. It's like going to the zoo versus going on a safari. So, there's actually a term for this, watching users in their context. It's called a contextual inquiry, and it's basically just going to someone's house, or to their job, or wherever, and watching them use the thing that you're trying to redesign, and taking notes along the way, and asking a few questions. One thing to keep in mind when you're doing this is approach these people with a sense of humility, that you're sort of the pupil, so they're mastery, because they know you're good at designing, but they know their subject really well, right? So you wanna go in there with a sense of humility and really trying to understand them. And I think that's particularly important because design still has this association, sort of like this association that designers are... It's kind of intimidating. The word design is intimidating to people who aren't designers, and if you sometimes... I remember once I told someone I'm a designer, and she did this thing with her head like, "Oh, you're a designer." (audience laughs) And I really didn't mean it that way, right? But I think that that's a natural reaction by a lot of people because design is still this foreign subject. So you need to work extra hard to approach these people with a sense of humility that you're really trying to understand them. Then bring in a few questions, like the questions that I've added in the bonus material, which you get with purchasing of this course, but, but also be ready to go with the flow, right? So, you might ask them one question, and then based on what they say, you start asking different questions and taking notes. And then if it gets too far off topic. Then you can shut the discussion down with a close-ended question and bring it back to one of your, to your original questions, redirect the flow. In an ideal scenario, you'd have two people in your interview. So one person who is doing more of the discussion facilitation and another person who's sitting over there and taking detailed notes. You rarely have that though. Most of the time it'll just be you. But if you have that, if you have the ability to get someone with you on those interviews, it's super useful because one person can't catch everything. And trying to listen and look them in the eyes and also take notes and look around their environment is difficult. It's cognitively exhausting after a while. So other things to consider are, and you don't wanna make the user a designer. So what that means is... Especially when you're talking to subject matter experts, or to users that are using the product a lot, they will already give you a solution of how they think it should be done. And a novice designer will be like, "Oh, well, let's do it that way then. "That's what they asked for." While a designer who's been doing it for a while understands that this proposed solution by the user, they can ask that, they can reverse it and ask the question, what's the problem that needs to be solved that they're trying to solve with the solution that they're proposing. Does that make sense? That was a mouthful. So, if the user says, "Yeah, I real think there should be a dropdown over here." because they've heard the term dropdown and they wanna use it to seem knowledgeable, then your job as the designer is to ask the questions, "Okay, what are you really trying to solve here "by adding a dropdown? "And is adding a dropdown really the best way to do it?" Sometimes they are right and it is the best way to do it. Most of the time they're not right. So you wanna focus more on problems that people are encountering, rather than the solutions that they're giving you. In the same way that you don't want to make a user a designer, you also wanna avoid making them an engineer. So, avoid discussing the technology of how you would solve a problem. This is not the time to discuss technology. This is just the time to figure out how people are using it and what the story is that they're encountering. Then another thing you wanna do is something I've seen done really badly is leading questions. So, I remember I was sitting in this one test once at a major, major company, but one of the interviewers really asked, "Do you think this is good?" It's like that's such a leading question, right? Because what is someone going to answer if they're on your turf in your office, they might have even gotten paid to be there, and then you ask them, "Do you think this is good?" How often are you gonna get an honest response there? So, it's important to avoid those leading questions, instead of asking questions about particular features and whether they think this is good, or whether you think that we should add that, encourage them to tell a story of how they're using the product now. And then while they're telling that story, listen closely for parts of that story where you could improve the flow, take out steps, make something, do something to make them more effective. So, yeah, designers need to make these connections between the facts of behavior, watching people what they do, looking at the environment that they're in, and also what they say. There's like a delta between those. It's kinda hard to express into words, but when you're actually in someone's office or something, and you're asking them question, it sort of happens almost automatically. This is one of those things that you really need to do to really understand that. Okay, how do you go about finding people and finding the right people to interview? Well, luckily, before you got to the user interview, you've already done six other steps, right? You've done a kick-off meeting, you've looked at the literature, you've looked at competitors and the current product, you've talked to people inside the company, actually on the subject so based on all of that information, you can already get a, ideas just start forming of who the people are that you need to interview, and how their needs and behaviors vary. So, when you're setting up these interviews, the best way to go about it is just to talk to the people inside the company, and be like, "Hey, "where can we find some of these... "You know these people that we've talked about "and this problem that we're trying to solve for them. "What's the best place to go "to find some of them and ask them some questions?" And then in that conversation, you'll get the information that you need. If that doesn't work, sometimes it doesn't work, you can use market research firms, usability research firms. Contract out to them to find you some people. The problem there is that sometimes it can be challenging to find people that will allow you to come into their house. And finally, you can recruit your friends and family members, but it doesn't really give you good information, but it's still better than not testing at all. After the interview... So user interview is one of those things where there's this huge hurdle of courage to overcome to actually do it, because it's much, much easier to just sit at your computer and make a UI than to go out and ask people about stuff, or cold call someone. But it's one of those things that is hugely rewarding and gives you so much information, but also that information is fleeting. So, the best thing to do is write down right after the interview. Don't even drive off in your car. Just sit in the car and take some notes. Try to remember everything. And after you've done all of your interviews, I would do at least five interviews, try to identify trends. I'm sure that one of the big questions will be, what type of... What should I ask during a UX interview? And thankfully, in the bonus material, you have something like, you have some question to get you started when you're sitting at someone's office trying to find out how they use your product.