[SOUND] Welcome to User Experience Design. The goal of the requirements gathering phase is to understand the problem space. To understand the problem space, we carry out a set techniques. These provide us with information with data, I've told you that one of the mantra's of this class is that design is a systematic and data driven process. Techniques will give us different kinds of data. The two main categories are quantitative and qualitative. Quantitative data can be thought of as information that can be transcribed numerically. Think about survey data, we can put it into spreadsheets. We can then analyze it using descriptive statistics. We can find out things like what's the average age of the user in the study, what was the median number of years that that user had their current phone? Qualitative data, on the other hand, is more easily thought of as providing us with Thematic information. An example of qualitative data is information gathered from interviews with users. The information you collect will more easily be put into a narrative than into spreadsheets, imagine that you interviewed 15 people about the reasons they got a new smartphone. Is likely that we can start to see commonalities in the categories or themes that lead them to their decision to get a new phone. Is one type a data better than the other? No, they both give us different and important information, I've heard colleagues say that quantitative data gives us the what about the user and qualitative data give us the why. In fact most designers will use a combination of quantitative and qualitative data. This is called a Mixed method approach. So far I've been talking about the user as if they were a monolithic class of people. You know that they're not, they can be different on many dimensions. One way to think about users and categorize them systematically is by considering how they will be affected by the new design. In the next set of slides, I'll define each term and then provide an example of how the various users are united by a given design. Primary stakeholders are the people who use the design directly. These are the users that designers most commonly interact with, they're called the end users. Secondary stakeholders do not use the design directly, but may do so indirectly because they get some kind of output from it. Tertiary stakeholders may not use the design at all, but are directly affected by the design in either a negative or a positive way. All right, so here's the example I promised you. Let's say that we design a new system to keep track of wear on running shoes. The runner would be the primary stakeholder, because she is wearing the newly designed running shoe, she is the end user. Using the same example, let's say that the runner is actually part of a member of a track team. Here, the coach for the track team would be considered a secondary stakeholder. Because he would be the one that monitors the data about the runner's shoes and makes decisions about when they have to get a new pair of sneakers. A tertiary stakeholder in our example maybe the project manager of the company that builds the shoes. He may get a bonus if the new design increases sales or he'll get a cut in the budget if it doesn't. As designers we often focus on the end user. However, thinking about secondary and tertiary stakeholders can also help us to develop designs that are innovative and can give our client a competitive edge. In this sense, understanding stakeholders leads to better user experience design. Back to our example about another running shoe design that measures tread wear. We can imagine that our high end running shoe might have a high cost. If we now include a dashboard for coaches, this is a value added, however if we consider the tertiary stakeholder's prospective. On how much it would cost to put an actual sensor in each shoe then we might come with an alternative design consideration. Maybe it's not worth it to put our sensor in every shoe but maybe it's best to fabricate the sensor and make it transferable from shoe to shoe. In this lesson, we learned about the kind of data that we can collect during the requirements gathering phase and how we can think about the user as being stakeholders. I look forward to seeing you in our next lesson, where I will talk to you about the four different discovery techniques. [MUSIC]