Welcome back. In this lecture, we are going to be talking about design rationale, or how to make design decisions in a systematic and principled way. What do we have in mind when we talk about design rationale? Designer is often confronted with a plethora of design options. In many ways can feel like someone shopping in a US grocery store tried to buy cereal, where there are hundreds of different options and he's trying to decide which one to go with. Through brainstorming, and sketching, and creation of artifacts like scenarios and storyboards, the designer will get to a point where he or she is dealing with a large number of different ways that something can be implemented, and needs to make a decision with which those ways to go with. Design rationale allows the designer to articulate the tradeoffs of different alternatives in a way that would allow him or her to guide design. In other words, the goal of design rationale is to understand the design options, their are various pros and cons, and to make a principal about which design option to pursue. There are a number of different ways of doing design rationale. Some of them more systematic, some of them less systematic. But all of them are really dealing with the same general principle of articulation of tradeoffs and then using those tradeoffs to make a decision. What I'm going to be presenting in this lecture is a system called Questions, Options, and Criteria, which is developed by Ellen McLean and his colleagues in the late 80s and early 90s, to provide designers with a systematic way of making these design decisions in a systematic and principled way. In this QOC framework, each technology feature is represented by multiple options which answer a particular question. Then criteria are used to help articulate the tradeoffs of those different options and guide the choice of which options to go with. To concretize what we have in mind let's stick with our example of tracking food, creating some mobile health application that allows an individual to track what they're eating and drinking. In QOC framework, questions provide the structure to the design space and help uncover and define design alternatives. In the case of our example of a food tracking application, here are some example questions that a person might ask. How should consumed food be entered into the food log? What kinds of food should be tracked? At what granularity should food be tracked? For each one of those questions there will be multiple options that the designer by [inaudible] want to make a decision among. Options then define the different potential answers to the same question. The idea here is to be able to compare different design solutions apples to apples, so that we're comparing options for the same feature in a way that is censoring the same exact problem. These are design alternatives, design ideas that all various ways of trying to implement the exact same feature. In the case of our example, one question that we might be able to ask is how should consumed food be entered into the food log? Here's some ways that that question can be answered. We can be entering food by finding them in a database. We can log the nutritional contents. So, things like grains and fruits, leafy vegetables, things like that. We can even just take a picture of the food and then enter it into a food log. All of these various ways are alternative solutions to the same problem of entering what the person is about to eat or has eaten into a food log. Let's see what that looks like in visual terms. Here are some examples that represent those different solutions to the question of how do you enter food into a food log. On the left side, we have a screenshot from a Jawbone Up application, which is an example of a standard way that many commercial applications handle food journaling, which is by selecting food from a database. Next to that is a screenshot from a research application called Ponds developed by Andrew, Andrian and her colleagues, which logs food by enabling an individual to log different amounts of nutritional ingredients like vegetables, and grains, and fruit by pressing plus one buttons to the right of each ingredient type. To the right of that is an application called Few Touch which is a research application that supports patients with diabetes in logging nutrition and managing their blood sugar levels. In this case the food logging is done through a much simpler interface where there are only six icons on the screen that represent a carb heavy meal, a carb light meal, a carb heavy snack, a snack that is light on carbs, and a carb heavy drink, and a drink that does not contain carbs. Again, only six icons and food is logged just by pressing one of those icons. Other optional dealing with food journaling is to just take a picture of the food before one eats it. Finally, one can even just use a simple slider that describes of how much one has eaten. All of those different options in this case they're much more developed than one would normally do at this stage of making design decisions, but they're just different options of entering food into a food journal. That's what the QOC framework refers to as options. They're all answering the same question which is how do we enter food into a food journal. Criteria are the required and desirable properties that the design should satisfy. These are the things and factor that differ in importance and generality, and help a designer determine reasons for their decisions. These are basically the criteria that they're going to be used to articulate the pros and cons of different design options. Criteria can come from a number of different places. Formative work with users for example is a typical way of how a lot of the criteria are derived because the formative work will uncover user needs that are important to keep in mind, as well as, the constraints that you have to be accounted for in the design process. Things like usability is a source of criteria as well. So, we might care about how well a particular technology integrates with a daily routines, issues such as privacy, social desirability, and so on. Previous studies of similar technologies can also uncover important criteria, as well as, behavioral theory and requirements from other parts of the system. For our food tracking system, here are some example of criteria that the design might need to satisfy. We might want to create a system that can be maintained long-terms to allow an individual to try their food over extended periods of time. We might want to design a system that does not require deep nutritional knowledge to be used. We might care about how quickly a user is able to track their food, as well as, that there's not the steep learning curve. So that user can start using the system efficiently and effectively from the very beginning. Finally for particular applications, it's important to be able to use the data about logged food to create graphs and statistical summaries of that data. So, that might be something that a particular system needs to accommodate and support. In the case of our design options, we can now take a look at this design options and use those criteria to see how well they stack up. For the database based system like the Jawbone app, these things are often very accurate in terms of logging exact number of calories that the user has consumed, but they become very burdensome to use after a while. Many people who use these systems only are able to maintain them for two or three weeks. So for supporting use over extended periods of time in keeping the burden low, database based systems don't fair very well. As system like Ponds might not be able to accommodate users who do not have the nutritional knowledge and who would be able to easily translate the food that they're eating into ingredients that they need to log. On the other hand, we have something like the picture on the right which logs food by just taking a photograph of a plate. This is very easy to use. It could potentially be maintained for extended periods of time, but it does not provide the data that can then be inputted into statistical models or into graphs of the data over time. Just by using these criteria, we were able to go from five different design options that we started with to only two using other criteria that might come into play. In this case, we have a slider which is really easy to use, very quick, and there's out to satisfy the criteria that we outlined earlier very well. We have a icon-based system like the Few Touch where there's only a small set of categories that are being logged. Both of these are probably not the first things that would come to mind when one was designing a food tracking system. But the criteria that we outlined earlier really eliminated many of the more standard options that would easily come to mind when one is designing systems like this. This I think is one of the great strengths of a framework like QOC. It allows the designer to clearly keep in mind the key requirements that the designers try to satisfy and then use those requirements to make principled decisions among the alternatives. By doing that, often we end up choosing solutions that are not the first thing that the designer would go to without a system like QOC. That is pretty clear in this case where neither of the two contender options are really the designs that initially come to mind when one is designing a food tracking system. When working through the design rationale, there are a number of things that need to be kept in mind. One especially in complex design problems, there's usually not a single clear answer that emerges out of the process of articulating design rationale. In our case, we were left with two equally plausible design alternatives. That is not unusual. It is usually the case that when the central criteria are considered, that still leaves a multiple options on the table that then the designer needs to pick among. In that case, often we need to go to other criteria or to bring requirements from other parts of the system to bear in order to make a decision. It's also important to know what the most important criteria are. Not all the criteria are going to be equally important, and often some criteria are going to be pulling the design options in one direction, and other criteria are going to be pulling them in another direction. Being able to rank the criteria and have a clear sense of what the most important criteria are that need to be accounted for is very important. A design decision can also often affect many other aspects of the system. In the case of our example, the version of the food tracking interface that is chosen has all consequences for what kind of feedback the system is able to give the user about what they're consuming, what kind of graphs are possible, what kind of statistical summaries are possible, how that data can be combined with data about the person's physical activity, or contexts and other things of that sort to provide feedback. So, decisions in one part of the system have effects on other parts of the system, and that's one of the main reasons why decisions have to be revisited over and over again as different parts of the systems get more solid and more robust. Finally, often a designer has to bring to bear empirical data from things like surveys, and focus groups, and even small studies with users to inform design decisions. Sometimes when there are a couple of options on paper appeared to work equally well, there's no substitute for showing those options to users getting feedback, either through surveys or even by prototyping those options in a simple way and then deploying them in the field in order to get better information about which of the design options one should go with. To summarize then, deciding which option to pursue is a key design activity. This is something that designers are faced with time and time again in the course of a design project. Since ideation is done throughout the design process, many times through the process, a designer is going to be left with multiple alternatives among which he or she needs to decide. Design rationale allows a designer to make those decisions in an intentional and reasoned way. Systems like QOC allow those decisions to be made in a systematic way so that designer is confident that all key requirements and criteria are being taken to account. Thanks for watching, and see you next time.
