Welcome back. In this lecture we're discussing scenarios. Stories that designers use to start testing their early design ideas. So scenarios like personas, answer the question of, how do we translate formative research into the design artifacts and how do we use the formative research to move the design forward? As such, there's stories that describe how specific users are using technology to accomplish specific goals in a specific context. In other words, scenarios bridge the findings about user needs and ideas about how technology may be able to support those needs. So unlike personas which are really intended to just concretize user needs themselves, scenarios start on the process of translating those user needs into actual design ideas. So what does the scenario look like? They're basically short stories, often about one or two paragraphs in length. And we can take a look at one, just to get an idea what that looks like. So here is a scenario that I wrote to help concretize some of the design ideas about what an intervention for physical activity for patients with heart disease might look like. And in this particular case, here is what that seems, looks like. Every since Mary returned to work after her heart attack last year, she has struggled to incorporate regular physical activity into her daily life. HealthyHeart, an app she recently discovered, is slowly changing that. As Mary is finishing her meeting, her activity tracker gently vibrates to indicate that HealthyHeart has sent her an activity suggestion. When Mary looks at her phone, she finds a message showing her a 1500-step walking route to her next meeting that goes by the beautiful fountain on her company's campus. She gets just enough time to walk over so she hits "thumbs-up" to indicate she liked the suggestion, and she follows the suggested route. That evening, after dinner, HealthyHeart alerts her that there is a salsa dance three days later at restaurant 20 minutes away. " great!" Mary thinks. "This could be a fun way to get more intense activity to meet my weekly activity prescription." She taps "let's do it!" and salsa dancing, along with the directions, is added to her calendar. So as you see here, this is a very brief story, in this case only a short paragraph in length, that describes how Mary is interacting with HealthyHeart to help her be more active throughout the day. So what did we learn from the short scenario? Well, we learned a few things. One, we learned something about Mary's context. For example, we know that her days are packed with meetings and that she's trying to get some physical activity during those busy workdays. Second, we also heard a little bit about her goals in this case to get enough high intensity activity to also meet her exercise prescription that was given to her by her exercise physiologist. And finally, the scenario demonstrates several features of this imagery application, HealthyHeart, and how those features are being used to support Mary's goals. So we know that HealthyHeart is proactive. That it reaches out to Mary by pinging her current activity tracker and providing her with suggestions on her phone. We also know that the HealthyHeart provides just-in-time, contextually tailored suggestions. So the suggestion that Mary got in the middle of her workday takes into account her calendar, and provides her with a suggestion that fits her current context. We also know that HealthyHeart tries to help Mary discover novel physical activities, and if you remember our persona of Mary from the last lecture, novelty is one of the things that Mary valued highly. And we also get a little bit of a sense that the way that HealthyHeart works, is that it's intended to create an effective response in Mary. In this case it's intended to help her feel a feeling of pleasant surprise. Why would we use scenarios like this? Well for one, scenarios are really effective in helping designers reflect all their design ideas during the design process. And we will see that in just a minute in relation to the scenario we just heard. They're also open-ended and easily revised. So these stories are quick to write, they're quick to revise. And they allow the whole design team to categorization about how the features that are being considered are going to be affecting the target users. And what kind of issues and problems might arise related to them. And finally, the anchor design discussion, because like personas, stories are easily understood by everyone. By programmers, by business analysts, by other stakeholders. So they provide designers with another kind of a representation, another kind of design artifact, that they can freely share within the design team. To support the discussion about the design and design decisions. So let's see how that plays out in the case of the scenario we just saw. Here are a few things that emerge just for considering the short paragraph that we read. One is there's a question of, how many suggestions would Mary be able to tolerate before she gets annoyed, right? If Healthy Heart is constantly pinging her throughout the day, at some point you will likely get frustrated. One of the questions that arises is, at what point that happens? What could the system need to know to provide good suggestions, right? So as the system is trying to provide her with both contextually tailored suggestions, and suggestions for novel activities. What kind of information would be needed to support those kinds of suggestions? This arises right out of the the scenario we saw. And how should such a system respond if Mary doesn't like a suggestion? Should they cut down on how often they provide suggestions? Should they switch to different kinds of suggestions? Again, it's not clear, but a scenario allows us to start considering these kinds of questions. And then again, where do the novel suggestions come from, right? What is, again, the background information that the system needs to have access to in order to be able to provide novel suggestions? All of this comes directly from the scenario we considered and it allows designers to start thinking about these kinds of questions to see whether the design idea that they had for this particular kind of application is feasible,. And whether it's something that is going to be useful to Mary, and how it needs to be designed in order to meet Mary's needs. Each scenario has a number of elements. The first one of these is setting, so this represents the situation, or the context in which an activity occurs. In the case of our scenario about Mary, the first part of the setting was the particular workplace and the period between the two meetings. And the second part of the setting was her home after dinner. Every scenario also has an agent, this is a person or people who are performing the activities that are being described in the scenario. Our scenario had only one agent, Mary. And then each scenario should have some kind of a goal or objective that the agents are trying to accomplish. In case of our scenario about Mary, her goal was to get more physical activity throughout the day and that is the goal that is being pursued in the scenario. And then there are actions that are belong performed by agents to accomplish their goals. In this case, the actions refer to Mary's interaction with the application. So reading the suggestions and deciding whether to follow those suggestions or not. And then often the're some events that happen to users while they're doing the activities in the scenario. We didn't have very much of that in this particular scenario, but one can imagine a elaborated version of this scenario we developed that describes how Mary goes on the walk to the next meeting and who she encounters, and what happens with her along the way. Designers use different kinds of scenarios as part of the design process. John Carroll, an interaction designer who develops scenario-based design, which is the body of work related to how scenarios are used in design, has identified multiple types of scenarios. First of these are problem scenarios. Problem scenarios describe the features of the current situation as it is found before any kind of technological solution is implemented. So one can think of problems scenarios as being influence of personas in the sense that they describe the target users and that user's context as the designers found them when they did their formative work prior to introduction of the technological solution. Goal or task-based scenarios describe what the user is trying to accomplish. So they describe users' goals and any constraints on those goals that are relevant to understanding why the user is trying to do what he or she is trying to do. Activity scenarios, transform the current practice into new design features. Our scenario about Mary is an example of an activity scenario because it describes how this imaginary application, HealthyHeart, is affecting Mary's actions as she's trying to become more physically active. Task scenarios are more elaborated versions of activities scenarios and they describes the steps that the user is taking to accomplish the a particular task. So these scenarios can include a lot more detail about interactions that the user has with the technology as they are pursuing their goal using that technology. Information scenarios describe how users perceive, interpret, and make sense of information. So for technologies that have a intensive informational component, that expose users to new information and allow them to search, sort, or otherwise manipulate information. These kinds of scenarios can provide more detail about what those interactions might look and feel like. And finally, interaction scenarios describe the physical actions that the users perform using the technology and how the system responds to them. So they're even more detailed in a relation to the actual interaction that the user has with the system than activity scenarios and task scenarios describe. Designers are going to use these different types of scenarios at different stages of the design process. Problem scenarios are often done first after the designers have conducted their formative research. Just to make sense of that research. And to help them concretize what they have learned about their target users and the barriers they're experiencing as they try to pursue their goals. Activity scenarios and task scenarios are then developed to start field testing some of the design ideas for how a technology might help users pursue their goals in the context in which they live and work. And finally, things like interaction scenarios are done later on after the designers have already done a lot of work about flashing out their design ideas. Just to make sure that the physical action that the user would need to take as they use the technology are not overly burdensome and that the technology is responding in an appropriate way. So some final considerations about scenarios. One thing to keep in mind is that one doesn't need to be a great writer to write useful scenarios. All of us can write stories. The point of the scenario is like with personas, it's just to provide enough details. So that the designer gets a clearer picture of what the situation is that he or she's trying to target. What actions the user is taking, and how the technology might be able to support the users in pursuing their goals? A related point is that scenarios should be quick. It's often better to write more rough scenarios than spend a lot of time trying to refine a smaller number of scenarios. So if we write a number of scenarios that describe different aspects of the application, different aspects of the setting in which the user lives. Those often end up being far more useful than just a small number of scenarios that describe a narrow range of features but that have been refined to a high level. A related point is that scenarios are ultimately process artifacts. They're to help the design process be moved forward. They're not ends in their own right. So one should only create as many scenarios as it's actually useful to move the design process forward and no more. Finally, even though we haven't discussed this point in this lecture. One of the virtues of scenarios is that they can help designers uncover unwanted technology effects. And do that early in the design process so technology can be designed in a way to try to avoid the worst of those side effects. Batya Friedman and her colleagues at the University of Washington, for example, had been working on something they called Value Scenarios. Which are scenarios that explicitly try to envision and articulate what kind of various side effects on the society, on the user herself, on the user's social network, a particular technology might have. And then those scenarios are used to guide the design decisions in such a way so as to try to avoid some of those worst side effects. To summarize, then, technologies can help designers test their design ideas early, before they can draw out wire frames, before they can prototype those ideas. Just to get a sense of the visibility of the ideas and how those ideas might help or not help target users pursue their goals. One of their main virtues is that they support communication of the whole design team because they're easy to understand and easy to share. And finally, scenarios can help designers reflect on intended and unintended consequences of their designs. So that they can make design decisions appropriately to maximize the value of technology to the target users, and minimize the side effects that are unwanted. Thank you for watching and see you next time.
