All right, so now let's take a look at some of the specific UX research methods that we'll use in this part of the design cycle. Hopefully after we go through these you'll understand how you would select which method you'll use. And you'll be able to compare, review, and apply the different methods. The ones that were going to look at in this section include contextual interviews, focus groups, the use of journey lines, using surveys, doing task analysis, doing comparative assessment, and doing proof of concept models. All these things are really designed to let us learn about what the user wants to do with the system and who the users are. We're going to talk about another pair of tools, personas, an use cases, both text-based and UML use cases, but we're going to do those in separate lectures. There's quite a bit of detail on those methods. So let's jump into the ones in this section. The important thing, again, to remember is, as we look at these, we want to think about how much time they take, how complex they are, an whether or not the goal of the particular method is what you need to learn about your users in order to move the design forward. How it fits in your overall project, whether or not it gives you the level of detail that you're trying to get. Contextual interviews really are one of the primary ways to learn about your users. It can take anywhere from a few hours to meet with the user and get an understanding of what it is they're trying to do. There's usually some upfront work to develop a plan for what questions you want to answer, and then maybe a little bit of a wrap up to review what you've found. The important thing here is when you're doing these things, if it all possible, you want to work with the users in the environment that they're going to be using your device or your system. What you might learn by both talking with the user and observing the user are the kind of issues that the users face in real use. What other equipment do they work with? How their space set up? What do they prefer to do during interactions? How long does it take them to do tasks, maybe currently versus with your new system? And whether there are other people involved that impact the design. What you'll end up with is a set of qualitative observed data that can really move a design forward. This is one of the most important tools in the toolbox for the user research phase. And in fact, in the Buley book on the UX Team of One, she cites this as the best way to get a sense of who users are and what they care about. She makes a point that you want to, during these interactions, encourage conversation through open ended questions. And that's really important. You should always be able to ask a user, why? What is it that they are looking for? Why are they doing something in a specific way? And get them to interact with you about what it is they expect. There's a great example of this type of an interview for Menlo Innovations, where their team of researchers run into accounting clerks office and noticed in the environment that the clerks had travel postcards at their workstations. They asked why those those postcards were there. And the clerks, being in a kind of a tough, stressful job, said that they like going back to their desks and looking at the post cards as a way to relieve the tension of the day. The Menlo team observed this and included those images of the postcards in their application design. This sounds like a little thing, but in fact it delighted the users. And when that application came out it was a huge success. So again, observing as well as talking to the users is a very important part of these contextual interviews. Another way to do user interaction is in a focus group, and this is a way to talk to multiple users at one time and get more input in a shorter amount of time for the work that you're putting in. One of the issues with focus groups is that usually you lose some of the contextual advantage of working in the user's workspace. But it has the benefit that you can talk to multiple people at the same time. It's a moderated discussion, so usually you plan out the questions ahead of time, you think about how you're going to interact with these users. Because you've got 5 or 10 people that you're talking to, you want to make sure that they're all engaged and you want to make sure that you're using their time to everyone's best benefit. So it's important that you pre-develop and review the script and consider recording this session or having someone act as a note taker to make sure that you don't miss anything from this valuable time with your users. Another concept that people use to understand what a user goes through in a particular task cycle is something called a journey line. These are fairly easy things to do sitting down with the user, it can take a little more time if you're using a specific template. But really what you're encouraging the user to do is describe the exact steps that they take in a task, and also which ones of them are easy versus difficult. So usually the way this works is you'll place the tasks that they do on a time axis. And then use the Y axis to include any emotional content or difficulty in performing that task. This is really an interesting exercise to go through, because often times it gets the users to start telling stories about what they do and issues that they've run into. So you want to give yourself time to allow for that valuable input. You can also use journey lines as a reporting tool to discuss a UX process that you've investigated. But really it's more of a discovery tool that you'll want to use with the users. Another way to get user input is through surveys. Certainly this is a tried and true method. It can take time to prepare a good survey, can take time to analyze the results, and it can take time to get the replies. A lot of times when you're in a captive environment where you have the cooperation of the users in a business or in a firm that you're working for, you might be able to get those responses easier and more thoroughly from the user population. When you're going out to the public a lot of times people will ignore surveys, and so the response rates can be much less. Really, all a survey is, of course, is structured questionnaire, and you can vary how that survey is structured. You can give them true, false questions, you can give them choices, you can have fill in the blanks, you could give essay questions. But the goal really is to keep the survey as short as possible, targeted at specifically what it is you need to learn. And to keep them brief, but allow for some open-ended questions that the users can give you more information on some of the specifics around what it is you're trying to learn. We'll talk, again, about surveys doing during the verification and validation cycles, where that quantitative measurement data that comes in from a survey about the user experience can be extremely valuable. Here we're talking about it more as a discovery tool to get more information about specific concerns. Another common thing to do during this cycle is some sort of a task analysis. This is one of the most common UX research approaches. Really, what we're doing here is we're just trying to detail out what tasks the users are going to perform, and maybe try to prioritize those tasks to understand what's most important to them. When you're doing a task analysis, you can understand the goals, the actions, the experiences of your user, how they perceive their tasks, how they use those tasks in a workflow, how often they do them, what the sequences of tasks are, etc. So typically in one of these research approaches, you would break this into several steps. You would go through the tasks with the user, break them down a bit into subtasks and start to capture some detail for those subtasks. So that you can put together some sort of a diagram that captures the flow of what is the user is doing. There are many ways to do this. There are many templates available and as we get into use cases and the use of UML, you'll see some diagramming techniques that you could use to capture task information. This example here is from a UML state diagram that kind of shows a movement through tasks as you go from state to state, what makes of state changes occur, etc. So I will talk about this a little bit more in the UML lecture. Another method that's very valuable is Comparative Assessment and really this can be done over a couple of hours. Or you can do a much more detailed analysis that might take some days. What you're doing here is you're looking at what users expect from your product by comparing it to similar products. This is somewhat like a competitive assessment, but the targets don't necessarily have to be competing with the design that you're creating. It could be things that have elements of the device. Or the system that you're going to create and gives you a chance to explore how users interact with similar products. What they expect for content, what features they like, what functionality they expect, how things flow, what the strengths and weaknesses are of other products that they interact with. Usually these things would get summarized into a text spreadsheet or diagram and you would use them later to build up the design guidelines for your eventual design. The last method we'll talk to here is Proof of Concept Models. This isn't specifically UX-related, although it can focus on UX elements of hardware or software within your design. But a proof of concept shows up at this stage because there may be some elements of the design approach that you need to verify feasibility for. This is not a prototype and the difference here is prototypes are usually leading to some kind of measure of user acceptance. The proof of concept is really focused on whether something is even feasible, whether the tool or the design element that you're selecting can even work in what you're creating. So these are usually very quick, disposable models that just give you enough information to make sure that what you're selecting could be part of your design envelope later on. It really is very much an engineering exercise. It's not necessarily directly related to user experience. In some cases you may look at mechanical or electrical or software elements that you're a little unsure of whether or not that thing fits in a particular design. So again, this is all part of ramping up to putting the design requirements together. And can answer some early questions about what it is you're going to do and how are you going to do it. So in summary, for an actual product you'd have to walk through these methods and consider how you would drive this phase. Doing interviews, doing a focus group, doing some comparative analysis of other tools, doing some proof of concept development. That information that you develop here of course starts to give you that key understanding of your users and drives into the design in the verify stages to come. We're going to look at two other methods in the following lectures. User Personas, which really give the team something to point at, when they're thinking about whether user would like or use a specific feature and then use cases. Which really are a way to define the tasks more thoroughly that we're going to make sure that our product addresses. So let's get into those. Thank you.
