Hello and welcome to this UX research lecture. We're going to talk about some of the aspects of UX research, including why it's important, how it affects the change and uncertainty in our UX oriented project, and how it will impact the follow on design and verification cycles that will get us to actually producing a device or a system. So first off, we'll talk a little bit about research. What we're talking about here is very carefully, studying the users. Understanding what it is that they want from the product, what it is that they need to get done, what tasks they have to do, and what other things might impact their use of what it is we're making for them. Jakob Nielsen's quote here, "Paying attention to what the users do, not what they say", really talks to observing users and making sure that you understand how they will use your product in the environment that they will use it in. So that's really one of the main focus areas for the UX research phase. So in this lecture, we'll look at why we're doing this research. We'll also talk a little bit about what if we don't do it, what the impact is? Then we'll dig in a little bit to how change and uncertainty affects engineering projects in general and our UX related projects in specific. So why are we doing this? You would think at this point, after all the work we've done, we'd be making something by now. But in fact, there's still a lot to learn before we want to commit to prototypes or design decisions. The main thing that we're looking for in this part of the research is to understand the users. Again, who are they? What tasks do they have to do? What goals do they have for what it is that we're making for them? What other factors in the environment or in any use case that they have for the device will impact how we make the design work. If we look at the research phases, we've moved from analysis and planning into this research phase. In this phase we'll use a set of methods to try to determine as best we can what the users are after, what it is that would satisfy their needs. Then we'll also make sure that we've documented that to a point where it will feed into the design cycles to come and also provide the design team with a constant reminder of what it is that the users are expecting to keep them at the center of what it is that we're doing. We also might do a little bit of modeling of a proof of concept nature just to look at the feasibility of some of the things that we're considering including in this device or in this system. So a little more why about user research. Our focus here is to look at user behavior, their needs, and their motivations. We must start these projects with the user in mind in order to be successful. Remember the engineer's conceit. We might think we know what a user needs, but until we actually do this research and do the discovery necessary to understand specifically what they encounter, what they know, how they think about the tasks that they're approaching, we really won't know how they expect a device or system to work. So we'll be looking to try and use methods that give us direct or indirect insights into what the users need and how they perceive the use of the device that we're going to create. So we'll look at who they are, what they're doing, we'll look at any limitations they might have as a class, we'll look at the environment that they're using the device in. All of this will lead into the design and verification phases that will let us eventually produce the device. So what if we don't do this? Well, certainly it happens all the time. People go right into a design cycle, start to develop prototypes, don't involve the users, and just make the device or system based on what they know and what they think the users want. This starts to lead us into considering what the cost of a defect or a mistake in the design is at different stages of the project. Certainly, early in the design cycle, if we find that we've made an error and we're still on paper, all we have to do is change that paper, the cost of making that change is very low. Later on when the device is actually created and when we're starting to move it into a factory to build it or where even when it's out in the field and it's in the user's hands, the costs of those changes becomes much higher. Our goal really should be to discover and iterate through, understanding what the user wants and what changes that might come from that as quickly as we can and as early as we can. This is a fairly famous engineering concept. Barry Boehm, back in the 1970s, developed a curve on the cost to change a design at various stages in an engineering cycle. Now, more recently, some people have disputed how this curve looks and whether it applies to modern development cycles. Like Agile development where we're responding to changes on a regular basis. I would say that even with more modern design techniques, it's still true that it's easier to make a change early in the cycle. Certainly easier to make a change while the design is still on paper or still in an early prototype stage versus device that's coming out in a box from a factory, or it's out in the user's hands. In most cases, I think this concept that Barry Boehm has created still holds up, even though there may be some dispute about the slope of the line or the definition of the various engineering phases. The other diagram that Boehm is fairly known for is the cone of uncertainty. Again, when we look at the iterative design approach that we're going to take to develop our products, we can see that we're working within this column to progressively elaborate our designs. We start very wide, we consider different approaches, we consider different ways to satisfy the user's needs, but then as we get further and further into the project, we start to make design decisions that narrow down specifically what it is we're going to deliver. At the beginning this is very uncertain and it's also hard to estimate which is an issue for project management. But later as we start to narrow down specifically what it is we're going to produce, it becomes easier to estimate the time of the deliveries and to be sure that what we're making is what people expect. The important thing for the research phase is to understand the user and document that understanding to a point that you can share it with your design team and keep the user at the center of your design activities. By doing this, you make sure that what you're producing is relevant to those users. That they'll be able to use your design easily and maybe he enjoy using the device or the system you create. Then that the effort that you're putting into this in engineering terms and in the cost of the design is worth it. That it's actually having some return and it will impact the acceptance of the design by the users later. All those things are part of why we're in this research phase. What the users are, what the tasks are, what the goals are. How much can we reduce design change by using these research methods? How do we keep the image of that user in the forefront of our design team as they're putting the system together? Of course, as we get into the research phase, just like with all these phases, we have to consider the time that we're spending and the resources that we're spending to learn this information. We're going to have to select the methods that we want to use and make sure they are appropriate to what we need to learn. This is no different than the other phases, we have to be prepared to iterate, if we've used a method and there's still some things that we're not certain about. But once we've gone through this phase, we should have a fairly good foundation for making a very user-centric design that could satisfy and maybe even delight the users once they start to use the device or the system that we develop. In the next part of the lectures we'll look at some of the specific methods that we'll consider applying to this research phase. Thanks.
