D48fhCAF

11 - Humans
2This is Morgan. Hello. Morgan is a human. Last time I checked. As a human, Morgan has various ways of perceiving the world around her, like seeing, hearing, and feeling. Is anyone else seeing these? There area few more as well like smelling and tasting, but we won't deal with those as much. Thank goodness. But Morgan has more than senses. She also has memories, experiences, skills, knowledge. Thanks. In human computer interaction, we have to take into consideration every element of the human, from the way they perceive and interact with the world, to their long history of using computers and technology.
3
42 - Computers
5This is a computer. Or at least, this is probably what you think of when you think of the term computer. But this is also a computer. And so is this. And so is this. And so is this. And so is this. Hey! This is Amanda, my video producer. Go on, I'm rolling. Right, and so is this. And so is this, and this, and this, and this, and even this. And so is this. And so is this. And so is this. And so is this. And so is this. Hey David? One second, trying to get to Squirtle. There we go. With mobile devices and augmented reality, HCI is quite literally everything. Pokemon Go was released a few days before I recorded this and augmented reality games like this turn effectively the entire world into an instance of HCI. Even out here in the middle of nowhere, I'm still doing something with computers.
6
73 - Interaction
8We have humans and we have computers and we're interested in the interaction between them. That interaction can take different forms though. The most obvious seems to be the human interacts with the computer and the computer interacts with the human in response. They go back and forth interacting, and that's a valid view. But it perhaps misses the more interesting part of HCI. We can also think of the human interacting with the task, through the computer. The interaction is really between the human and the task and the computer in the middle just mediates that interaction. Or to put this differently, the human and the computer together, interact with the task. Ideally in this case, we're interested in making the interface as invisible as possible, so the user can spend as little time focusing on the interface and instead focus on the tasks that they're trying to accomplish. Realistically, our interfaces are likely to stay somewhat visible. But our goal is to let the user spend as much time as possible thinking about the task, instead of thinking about our interface. We can all probably remember times when we've interacted with a piece of software and we felt like we spent all our time thinking about how to work the software. As opposed to accomplishing what we were using the software to do in the first place and that's frustrating. So our goal as designers, is to help the human feel like they're interacting directly with that task. While our interface, kind of vanishes, in the middle of that interaction.
9
104 - Reflections: Interacting & Interfaces
11We'll talk extensively about the idea of disappearing interfaces and designing with tasks in mind. But in all likelihood, you've used computers enough to already have some experience in this area. So take a moment and reflect on some of the tasks you do each day involving computers. Try to think of an example where you spend most of your time thinking about the task and an example where you spend most of your time thinking about the tool.
12
135 - Reflections: Interacting & Interfaces Solution
14Video games actually give us some great examples of interfaces becoming invisible. A good video game is really characterized by the player feeling like they're actually inside the game world, as opposed to controlling it by pressing some buttons on a controller. We can do that through some intuitive controller design like pressing forward moves forward, and pressing backward moves backwards. But a lot of times we'll rely on the user to also learn how to control the game over time. But as they learn, it becomes invisible between them and their interaction. A classic example of a place where interaction is more visible, is the idea of having more than one remote control that controls what feels like the same system. So I have these two controllers that control my TV and my cable box together. And for me it feels like this is just one task, watching TV. But technologically, it's actually different tasks. So I have to think about am I using the number pad on this controller or this controller, depending on what I'm trying to do at a given time. So I spend a lot of time thinking about the interface and not as much thinking about the task.
15
166 - The HCI Space
17One of the most exciting parts of HCI is it's incredible ubiquity. Computers are all around us and we interact with them everyday. It's exciting to think about designing the types of tools and interfaces we spend so much time dealing with, but there's a danger here too. Because we're all humans interacting with computers, we think we're experts at human-computer interaction. But that's not the case. We might be experts at interacting with computers, but that doesn't make us experts at designing interactions between other humans and computers. We're like professional athletes or world-class scientists. Just because we're experts doesn't mean we know how to help other people also become experts. In my experience, many people look at HCI like this. The red dot represents what they know and the black circle represents what they think there's to know. They know there's probably somethings they don't know yet, but they're already pretty at it, and it wouldn't be too hard to become an expert. After studying HCI for a bit though, they look more like this. You can see that they've increased what they know but their perception of what there is to know has grown even more. That's the journey we'll be taking together. You'll learn to do work in HCI, but perhaps more importantly, you'll learn how complex and large the field of HCI is. Your knowledge will increase, but yet you might exit the class less confident in your HCI ability than when you started. You're taking the first step into a larger world.
18
197 - HCI in the Big Picture
20Now, what we've described so far is a huge field, far too big to cover in any one class. In fact there are lots of places where you can get an entire masters degree or PhD in human computer interaction. Here are some of the schools that offer programs like that. And these are just the school that offer actual degree programs in HCI, not computer science degrees with specializations in HCI, which would be almost any computer science program. So let's look more closely at what we're interested in for the purpose of the next several weeks. To do that, let's look at where HCI sits in a broader hierarchy of fields. We can think of HCI as a subset of a broader field of human factors engineering. Human factors engineering is interested in a lot of the same ideas that we're interested in. But they aren't just interested in computers. Then there are also sub disciplines within HCI. This is just one way to represent this. Some people, for example, would put UI design under UX design, or put UX design on the same level as HCI, but this is the way I choose to present it. Generally, these use many of the same principles that we use in HCI, but they might apply them to a more narrow domain, or they might have their own principles and methods that they use in addition to what we talk about in HCI in general. So to get a feel for what we're talking about when we discuss HCI, let's compare it to these other different fields.
21
228 - HCI vs. User Interface Design
23For many years, human-computer interaction was largely about user interface design. The earliest innovations in HCI were the creation of things like the light pen, the first computer mouse, which allow for flexible interaction with things on screen. But the focus was squarely on the screen. And so, we developed many principles about how to design things nicely for a screen. We borrowed from the magazine and print industries and identify the value of grids in displaying content and guiding the users eyes around our interfaces. We created laws that govern how difficult it is for users to select what they want on screen. We examined for example whether it's easier to select a menu on a Mac, where the menus are always at the top of the screen. Or on a PC, where they're grouped with the individual window. We develop techniques for helping interfaces adapt to different screen sizes and we develop methods for rapidly prototyping user interfaces using pen and paper or wire frames. Through this rich history, UI design really became its own well defined field. In fact, many of the concepts we'll cover in HCI were originally developed in the context of UI design. But in HCI, we're interested in things that go beyond the user's interaction with a single screen. Technically, you an cover that in UI design as well, but traditionally most of the UI design classes I see focus on on-screen interaction. In HCI, we'll talk about the more general methods that apply to any interface.
24
259 - HCI vs. Psychology
26The research side of HCI connects to the relationship between HCI and psychology. And if we zoom out even further on this hierarchy of disciplines, we might say that human factors engineering itself is in many ways the merger of engineering and psychology. As well as other fields of design and cognitive science. In HCI, the engineering side takes the form of software engineering, but this connection to psychology remains, and in fact, it's symbiotic. We use our understanding of psychology, of human perception, of cognition to inform the way we design interfaces. We then use our evaluations of those interfaces to reflect on our understanding of psychology itself. In fact, at Georgia Tech, the Human Computer Interaction class is cross listed as a Computer Science and Psychology class. So let's take an example of this. In 1992, psychologists working at Apple wanted to study how people organized the rapid flow of information in their work spaces. They observed that people tended to form piles of related material, kind of like a less formal filing system, and so they then designed a computer interface, that would mimic that ability. Finally, they used the results of that development to reflect on how people were managing their work spaces in the first place. So in the end, they had a better understanding of the thought processes of their users as well as an interface that actually helped users. So in the end, their design of an interface with an HCI informed their understanding of psychology more generally. We came away with a better understanding of the way humans think about their work spaces because of our experience designing something that was supposed to help them think about their work spaces.
27
2810 - Introduction to CS6750
29Now that you understand a little bit about what human-computer interaction is, let's talk about what this class is going to be like. In this lesson, I am going to take you through a high level overview of this class. What material we'll cover, how it fits together, and what you should expect to know by the end of the course. I'll also talk a little bit about the assessments we'll use in the class, but be aware, these assessments are only applicable to students taking this class through Georgia Tech. If you're watching this course on your own or taking it to complement other courses you're taking, those assessments won't apply to you, but you'll get to hear a little bit about what students in the actual course do. If you are a student in the course, you should know the assessments do tend to change a bit semester to semester. I'm going to try and stay as general as possible to capture future changes, but make sure to pay attention to the specific materials you're provided for your semester.
30
3111 - Learning Goals
32In education, a learning goal is something we want you to understand at the end of the course. It's the knowledge contained within your head that you might not have had when we got started. In this class we have three major learning goals. First, we want you to understand some of the common principles in human computer interaction. These are the tried and true rules on how to design good interactions between humans and computers. Second, we want you to understand design life cycle. That's how interfaces go from conception to prototypes to evaluation. And we especially want you to understand the roll of iteration in this process. Third, we want you to understand the expense of the human computer inherent interaction field and the current applications available for HCI. HCI is really everywhere, from domains like healthcare, to technologies like virtual reality, to emerging techniques like sonification. We want you to understand the broad range of application areas for HCI in the modern world.
33
3412 - Learning Outcomes: To Design
35While learning goal is something we want you to know at the end of the course, a learning outcome is something we want you to be able to do. This course really has one learning outcomes but there are some nuances to it. The learning outcome for this course is to be able to design effective interactions between humans and computers. The first part of this learning outcome is to design. But what is design? Well for us design is going to take two forms. First, design is an activity where you're appl known principles to a new problem. For example we'll talk a lot about the importance of getting users to write kind of feedback at the right time. That's a plan of principle of feedback to some new design problem ww encounter. But design is a second form as well, design is also a process where you gather information, use it to develop design alternatives, evaluate them with users and revise them accordingly. When designing interface for some tasks, I would ask some potential users how they perform some task right now. I develop multiple different ideas for how we can help them. I give those to the users to evaluate, and I will use the experiences to try to improve the interface on that time. So let's take an example of this. Imagine I was designing a new thermostat. On the one hand, designing a new thermostat means applying known HCR principles, like feedback and error tolerance to some new design. On the other hand, designing a new thermostat means creating different ideas, giving them to users, getting their feedback and then revising those designs. Both these sides of design are very important. You don't want to ignore decades of experience when designing new interfaces, but simply applying known principles to a new problem doesn't guarantee you have a good design. Designing is about both these things. And in fact, these two things are a vast majority of material that we'll cover in this course. We'll cover the principles uncovered by a human factors engineering and human computer interaction research. And we'll cover the methods used in the HCI. We're gathering user requirements, developing designs, and evaluating new interfaces.
36
3713 - Learning Outcomes: Effectiveness
38The first part of this learning outcome to design needed some definition, but the second part seems pretty straightforward, right? Not exactly. Effectiveness is defined in terms of our goal. The most obvious goal here might be usability and for a lot of that's exactly what we're interested in. If I'm designing a new thermostat, I want the user to be able to create the outcome they want as easily as possible. But maybe usability isn't my goal, maybe it's research. Maybe I'm interested in investigating what makes people think that the thermostat is working correctly. In that case, I might deliberately create some thermostats that are harder to read, just to see how that changes people's perceptions of the system. Or it could be that my goal isn't to make the certain activity easier but rather to change that activity. Maybe I'm interested in reducing a home's carbon footprint. In that case, my goal is to get people to use less electricity. I might design the interface of the thermostat specifically to encourage people to use less. Maybe I'd show them a comparison to their neighbor's usage, or allow them to set energy usage goals. Or I could make the thermostat physically harder to turn up and down. So effectiveness is very much determined by the goal that I have in mind. We'll generally assume that our goal is usability, unless we state otherwise. But we'll definitely talk about some of those other goals as well.
39
4014 - Learning Outcomes: Between Humans and Computer
41The final part of our desired learning outcome is between humans and computers. We want to design effective interactions between humans and computers. Well, what is important to note here, is where we're placing the emphasis. Note that we didn't say designing effective interfaces, because that puts the entire focus on the interface. We're deeply interested in the human's role in this interaction. So rather than designing interfaces, designing programs, designing tools, we're designing interactions. We're designing tasks. We're designing how people accomplish their goals, not just the interface that they use to accomplish their goals. Take our thermostat for example. When we started this process, our goal shouldn't be to design a thermostat. Our goal should be to design the way in which a person controls the temperature in their home. That subtle shift in emphasis is powerful. If you set out to design a better thermostat, you might design a wall-mounted device that's easier to read or easier to use. But if you set to design a better way for people to control the temperature in their home, you might end up with Nest. A device that learns from the user and starts to control the temperature automatically.
42
4315 - Learning Strategies: Video Material
44Learning strategies are how we plan to actually impart that knowledge to you. This is how we attempt to help you achieve the learning goals and learning outcomes. Within these videos, we'll use a number of different strategies to try to help you understand the core principles and methodologies of HCI. We'll use learning by example. Every lesson and, in fact, this course, as a whole. Is organized around a collection of running examples that will come up over and over again. We use learning by doing. Throughout the course we'll ask you to engage in designing interactions to solve different problems in different contexts. These aren't required, since there's really no way we can verify if you've done them, but we really hope you'll take a few minutes and think about these. We'll also use learning by reflection a lot. We'll ask yo to reflect on times when you've encountered these things in your own every day life. These strategies are useful because they connect to your own personal experiences but once again, there's a danger here. One of the recurrent points in HCI is that when you are designing interactions, you are not your own user. Focusing too much on your own experiences can give you a false sense of expertise. So I'll use some strategies to help take you out of that comfort zone and confront how little you might understand these tasks with which you thought you were so familiar.
45
4616 - Learning Strategies: Georgia Tech
47Within the full course at Georgia Tech, there are a number of other strategies in which you'll engage as well. First, we're really passionate about leveraging the student community in this class to improve the experience for everyone. Taking this class with you are people with experience in a variety of industries, many of whom have significant experience in HCI. So some strategies we'll use include peer learning, collaborative learning, learning by teaching, and communities of practice. You'll learn both from each other and with each other. You'll play the role of student, teacher, and partner, and you will learn from each perspective. In addition, the entire course is built around the idea of project-based learning. Early in the semester, you'll form a team and start looking at a problem we've selected, or maybe one in which you're already interested. This project will then become the domain through which you explore the principles and methods of human-computer interaction. Who knows? By the end of the semester, you might even generate something with the potential to go forward as a real-world product, or as a research project.
48
4917 - Learning Assessments
50Learning goals are what we want you to understand. Learning outcomes or what we want you to be able to do. Learning assessments then, are how we evaluate whether you can do what we want you to be able to do and understand what we want you to understand. The learning outcome to this class is to be able to design effective interactions between humans and computers. So the primary assessments in this class are to, say it with me, design effective interactions between humans and computers. You'll start with some relatively small scale tasks, recommending improvements to existing interfaces or or undertaking some small design challenges. But as the semester goes on, you'll scope up towards a bigger challenge. You'll initially investigate that challenge individually and then you'll merge into teams to prototype and evaluate a full solution to the challenge you chose. At the end, you'll be evaluated not just on the final design you generate but on the process by which it was generated.
51
5218 - Course Structure
53We'll close by talking about the overall structure of the content you'll be consuming. The course's lessons are designed to be as independent as possible, so you should be able to skip around if you want, but there's a certain logic to our planned presentation order. We discussed earlier the model HCI, how design informs research and research then informs design, so we'll start by discussing some of the core design principles of HCI. Then we'll discuss the research methodologies for uncovering new user information, the interative design lifecycle. We'll close by giving you the opportunity to peek at what's going on in the HCI community at large.
54
5519 - Introduction to Exploring HCI
56Computers are finding their way into more and more devices, and as a result HCI is becoming more and more ubiquitous. It used to be that you wouldn't really need to think too much about HCI when designing a car or designing a refrigerator, but more and more computing is pervading everything. At the same time, new technological developments are opening up new areas for exploration. We're seeing a lot of really fascinating progress in areas like virtual reality, augmented reality, wearable devices. As we study HCI, we're going to talk a lot about things you've already used like computers and phones. But we want you to keep in mind some of these more cutting edge application areas as well. After all, if you're really interested in going into HCI professionally, you'll be designing for these new application areas. So we're going to quickly preview some of these. We'll divide them into three areas, technologies, domains and ideas. Technologies are emerging technological capabilities that let us create new and interesting user interactions. Domains are pre-existing areas that could be significantly disrupted by computer interfaces like healthcare and education. Ideas span both of these. They are the theories about the way people interact with interfaces and the world around them. Now, our delineation of this is kind of artificial. There's a lot of overlap. New technologies like augmented reality are what allow emerging ideas like contact sensitive computing to really have the power that they do. But for organization, we'll group our application areas into these three categories. When one of these areas catches your eye, take a little while and delve into it a little bit deeper. Then keep that topic area in mind as you go through the rest of the HCI material. We'll revisit your chosen area throughout the course, and ask you to reflect on the application of the course's principals and methods to your application area.
57
5820 - Technology: Augmented Reality
59Virtual reality generally works by replacing the real world's visual, auditory, and sometimes even all factory or kinesthetic stimuli with it's own input. Augmented reality on the other hand, compliments what you see and hear in the real world. So for example, imagine a headset like a Google Glass that automatically overlays directions right on your visual field. If you were driving, it would highlight the route to take, instead of just popping up some visual reminder. The input it provides complements stimuli coming from the real world, and instead of just replacing them. And that creates some enormous challenges, but also some really incredible opportunities as well. Imagine the devices that can integrate directly into our everyday lives, enhancing our reality. Imagine systems that could, for example, automatically translate text or speech in a foreign language, or could show your reviews for restaurants as you walk down the street. Imagine a system that students could use while touring national parks or museums, that would automatically point out interesting information, custom tailored to that student's own interests. The applications of augmented reality could be truly stunning, but it relies on cameras to take input from the world, and that actually raises some interesting societal problems. There are questions about what putting cameras everywhere would mean. So keep those in mind when we get to interfaces and politics, in unit two.
60
6121 - Idea: Pen- and Touch-Based Interaction
62I always find it interesting how certain technologies seem to come around full circle. For centuries we only interacted directly with the things that we built and then computers came along. And suddenly we needed interfaces between us and our tasks. Now, computers are trying to actively capture natural ways we've always interacted. Almost every computer I encounter now days has a touch screen. That's a powerful technique for creating simple user interfaces because it shortens the distance between the user and the tasks they’re trying to accomplish. Think about someone using a mouse for the first time. He might need to look back and forth from the screen to the mouse, to see how interacting down here, change things he sees up here. With a touch based interface, he interacts the same way he uses things in the real world around him. A challenge can sometimes be a lack of precision, but to make up for that we've also create pen based interaction. Just like a person can use a pen on paper, they can also use a pen on a touch screen. And in fact, you might be quite familiar with that, because most Udacity courses use exactly that technology. They record someone writing on a screen. That gives us the precision necessary to interact very delicately and specifically with our task. And as a result tablet based interaction methods have been used in fields like art and music. Most comics you find on the internet are actually drawn exactly like this, combining the precision of human fingers with the power of computation.
63
6422 - Domain: Healthcare
65A lot of current efforts in healthcare are about processing the massive quantities of data that are recorded everyday. But in order to make that data useful, it has to connect to real people at some point. Maybe it's equipping doctors with tools to more easily visually evaluate and compare different diagnoses. Maybe it's giving patients the tools necessary to monitor their own health and treatment options. Maybe that's information visualization so patients can understand how certain decisions affect their well-being. Maybe it's context aware computing that can detect when patients are about to do something they probably shouldn't do. There are also numerous applications of HCI to personal health like Fitbit for exercise monitoring or MyFitnessPal for tracking your diet. Those interfaces succeed if they're easily usable for users. Ideally, they'd be almost invisible. But perhaps the most fascinating upcoming intersection of HCI and health care is in virtual reality. Virtual reality exercise programs are already pretty common to make living an active lifestyle more fun, but what about virtual reality for therapy? That's actually already happening. We can use virtual reality to help people confront fears and anxieties in a safe, but highly authentic place. Healthcare in general is concerned with the health of humans. And computers are pretty commonly used in modern healthcare. So the applications of human computer interaction to healthcare are really huge.
66
6723 - Domain: Security
68Classes on network security are often most concerned with the algorithms and encryption methods that must be safeguarded to ensure secure communications. But the most secure communication strategies in the world are weakened if people just refuse to use them. And historically, we've found people have very little patience for instances where security measures get in the way of them doing their tasks. For security to be useful it has to be usable. If it isn't usable, people just won't use it. XEI can increase the usability of security in a number of ways. For one, it can make those actions simply easier to perform. CAPTCHAs are forms that are meant to ensure users are humans. And they used to involve recognizing letters in complex images, but now they're often as simple as a check-box. The computer recognizes human-like mouse movements and uses that to evaluate whether the user is a human. That makes it much less frustrating to participate in that security activity. But HCI can also make security more usable by visualizing and communicating the need. Many people get frustrated when systems require passwords that meet certain standards or complexity, but that's because it seems arbitrary. If the system instead expresses to the user the rationale behind the requirement, the requirement can be much less frustrating. I've even seen a password form that treats password selection like a game where you're ranked against others for how difficult your password would be to guess. That's a way to incentivize strong password selection making security more usable.
69
7024 - Domain: Games
71Video games are one of the purest examples of HCI. They're actually a great place to study HCI, because so many of the topics we discuss are so salient. For example, we discussed the need for logical mapping between actions and effects. A good game exemplifies that. The actions that the user takes with the controller should feel like they're actually interacting within the game world. We discussed the power of feedback cycles. Video games are near constant feedback cycles as the user performs actions, evaluates the results and adjust accordingly. In fact, if you read through video game reviews you'll find that many of the criticisms are actually criticisms of bad HCI. The controls are tough to use, it's hard to figure out what happened. The penalty for failure is too low or too high. All of these are examples of poor interface design. In gaming though there's such a tight connection between the task and the interface. Their frustrations with a task can help us quickly identify problems with the interface.
72
7325 - Introduction to Design Principles
74For this portion of our conversation about human computer interaction, we're going to talk about some established principals that we'd uncovered after decades of designing user interfaces. We want to understand the fundamental building blocks of HCI, and separately we'll talk about how to build on those foundations to do new research and new development. To get started, though, let's first define some of the overarching ideas of design principles. In this lesson, we're going to talk about the way we focus on users and tasks in HCI, not on tools and interfaces on their own. We're going to talk about the role of the interface and how it mediates between user and the task. We're going to discuss different views on the user's role in the system. And we're going to talk about user experience more generally and how it exists at several different levels. Along the way, we'll tackle some design challenges, reflect on our own experiences, and try to apply what we learn to the broader field of HCI.
75
7626 - Interfaces: Between Users and Tasks
77At the heart of Human Computer Interaction is the idea that users use interfaces to accomplish some task. In general, that interface wouldn't actually have to be technological. This cycle exists for things like using pencils to write things or using a steering wheel to drive a car. But in HCI, we're going to focus on interfaces that are in some way computational or computerized. What's most important here though is our focus on the interaction between the user and the task though the interface, not just the interaction between the user and the interface itself. We're designing interfaces, sure, but to design a good interface, we need to understand both the users goals and the tasks they're trying to accomplish. Understanding the task is really important. One of the mistakes many novice designers make, is jumping too quickly to the interface, without understanding the task. For example, think about designing a new thermostat. If you focus on the interface, the thermostat itself, you're going to focus on things like the placement of the buttons or the layout of the screen, on whether or not the user can actually read what's there, and things like that. And those are all important questions. But the task is controlling the temperature in an area. When you think about the task rather than just the interface, you think of things like nest, which is a device that tries to learn from its user and act autonomously. That's more than just an interface for controlling whether the heat or the air conditioning is on. That's an interface for controlling the temperature in your house. By focusing on the task instead of just the interface, we can come up with more revolutionary designs like the Nest rather than just iterative improvements to the same thermostats we've been using for years.
78
7927 - Exercise: Identifying a Task
80Let's try identifying a task real quick. We're going to watch a short clip of Morgan. Watch what she does, and try to identify what task she is performing. What was the task in that clip?
81
8228 - Exercise: Identifying a Task Solution
83If you said she's swiping her credit card, you're thinking a little too narrowly. Swiping her credit card is just how she accomplishes her task. We're interested in something more like she's completing a purchase. She's purchasing an item. She's exchanging goods. Those all put more emphasis on the actual task she's accomplishing and let us think more generally about how we can make that interface even better.
84
8529 - Usefulness and Usability
86The ultimate goal of design in HCI is to create interfaces that are both useful and useable. Useful means that the interface allows the user to achieve some task, but usefulness is a pretty low bar. For example, a map is useful in finding your way from one place to another, but it isn't the most useable thing in the world. You have to keep track of where you are, you have to plot your own route. And you have to do all of this while driving the car. So before GPS navigation, people would often manually write down the turns before they actually started driving somewhere that they hadn't been before. So our big concern is usability. That's where we get things like navigation apps. Notice how we have to focus on understanding the task when we're performing design. If we set out to design a better map. We probably wouldn't have ended up with a navigation app. It was through understanding the task of navigation itself that we realized we could offload a lot of the cognitive load of navigation onto the interface, closing the loop between the user and the task of navigation.
87
8830 - Views of the User: Processor
89In looking at human-computer interaction, it's important that we understand the role that we expect the human to play in this overall system. Let's talk about three different possible types of roles the human can play, processor, predictor, and participant. First, we might think of the human as being nothing more than a sensory processor. They take input in and they spit output out. They're kind of like another computer in the system, just one that we can't see the inside of. If we are designing with this role in mind then our main concern is that the interface fit within known human limits. These are things like what humans can sense, what they can store in memory, and what they can physically do in the world. In this case, usability means that the interface is physically usable. User can see all the colors, touch all the buttons, and so on. With this model, we evaluate our interfaces with quantitative experiments. That means we take numeric measurements on how quickly the user can complete some task or how quickly they might react to some incoming stimulus. Now, as you might have guessed, the processor view is not the one we'll generally take when we talk about good design. Instead, we'll probably divide our time pretty equally between the other two perspectives.
90
9131 - Views of the User: Predictor
92A second way of viewing the human is to view them as a predictor. Here, we care deeply about the human's knowledge, experience, expectations, and their thought process. That's why we call them the predictor. We want them to be able to predict what will happen in the world as a result of some action they take. So we want them to be able to map input to output. And that means getting inside their head. Understanding what they're thinking, what they're seeing, what they're feeling when they're interacting with some task. If we're taking this perspective, then the interface must fit with what humans know. It must fit with their knowledge. It must help the user learn what they don't already know and efficiently leverage what they do already know. And toward that end, we evaluate these kind of interfaces with qualitative studies. These are often ex situ studies. We might perform task analyses to see where users are spending their time. Or perform cognitive walk-throughs to understand the user's thought process throughout some task. We can see pretty clearly that this view gives us some advantages over viewing the user simply as a sensory processor, just as another computer in the system. However, here we're still focusing on one user and one task. And sometimes that's useful. But many times we want to look even more broadly than that. That's when we take the third participant peel.
93
9432 - Views of the User: Participant
95A third view on the user is to look at the user as a participant in some environment. That means we're not just interested in what's going on inside their head. We're also interested in what's going on around them at the same time, like what other tasks or interfaces they're using, or what other people they're interacting with. We want to understand for example, what's competing for their attention? What are their available cognitive resources? What's the importance of the task relative to everything else that's going on? So if we take this view, then our interface must fit with the context. It's not enough that the user is able to physically use the system and knows how to use the system. They must be able to actually interact with the system in the context where they need it. And because context is so important here, we evaluate it with in situ studies. We can't simply look at the user and the interface in a vacuum. We have to actually view and evaluate them in the real world using the interface in whatever context is most relevant. If we're evaluating a new GPS application, for example, we need to actually go out and look at it in the context of real drivers driving on real roads. The information we get from them using the app in our lab setting isn't as useful as understanding how they're going to actually use it out in the real world. These are in situ studies, which are studies of the interface and the user within the real complete context of the task.
96
9733 - Good Design, Bad Design
98It sounds funny, but which view you take on the user can have a huge impact on the success of the interface. If you view the user just as a sensory processor, you might think that we only need to alert them a second before the upcoming turn because, after all, human reaction time is less than a second. If you view the user as a predictor, you understand they need time to slow the car down and actually make the turn. So they might need a few more seconds to execute the action of turning before being alerted they need to turn. And if you view the user as a participant, you'll understand this is happening while they're going 50 miles down the road with a screaming toddler in the backseat, trying to merge with the driver on a cell phone and the other one eating a cheeseburger. So it would probably be a good idea to give them a few or more reminders before the turn and plenty of time to get in the right position.
99
10034 - Reflections: Views of the User
101Let's take a moment to reflect on when you've encountered these different views of the user in your own history of interacting with computers. Try to think of a time when a program, an app or a device clearly treated you as each of these types of users for better or for worse.
102
10335 - Reflections: Views of the User Solution
104For me, we have a system at Udacity we use to record hours for those of us that work on some contract projects. It asks us to enter the number of hours of the day we spend on each of a number of different types of work. The problem is that, that assumes something closely resembling the processor model. A computer can easily track how long different processes take. But for me, checking the amount of time spent on different tasks can be basically impossible. Checking my e-mails involves switching between five different tasks a minute. How am I suppose to track that? The system doesn't take into consideration a realistic view of my role in the system. Something more similar to the predictor view would be, well, the classroom you're viewing this in. Surrounding this video are a visual organization of the lesson's content, a meter measuring your progress through the video, representations of the video's transcript. These are all meant to equip you with the knowledge to predict what's coming next. This classroom takes a predictor view of the user. It offloads some of the cognitive load onto the interface allowing you to focus on the material. For the third view I personally would consider my alarm clock an example. I use an alarm clock app called Sleep. It monitors my sleep cycles, rings at the optimal time and tracks my sleep patterns to make recommendations. It understand its role as part of a broader system needed to help me sleep. It goes far beyond just interaction between me and an interface. It integrates into the entire system.
105
10636 - User Experience, Sans Design
107By my definition, user experience design is attempting to create systems that dictate how the user will experience them. Preferably that the user will experience them positively. User experience in general, though, is a phenomenon that emerges out of the interactions between humans and tasks via interfaces. We might attempt to design that experience. But whether we design it or not, there is a user experience. It's kind of like the weather, there's never no weather, there's never no user experience. It might be a bad experience if we don't design it very well. But there's always some user experience going on and it emerges as a result of the human's interactions with the task via the interface. But user experience also goes beyond this simple interaction. It touches on the emotional, personal, and more experiential elements of the relationship. We can build this by expanding our understanding of the scope of the user experience. For just a particular individual, this is based on things like the individual's age, sex, or race, personal experiences, gender, expectations for the interface, and more. It goes beyond just designing an interface to help with a task. It touches on whether the individual feels like the interface was designed for them. It examines whether they're frustrated by the interface or joyous about it. Those are all parts of this user experience. We can take this further and talk about user experience at a group level. We can start to think about how interfaces lead to different user experiences among social or work groups. For example, I've known that school reunions seem to be much less important to people who've graduated within the past 15 years. And I hypothesize it's because Facebook and email have played such significant roles in keeping people in touch. It's fundamentally changed the social to group user experience. Those effects can then scope all the way up to the societal level. Sometimes these are unintended. For example, I doubt that the creators of Twitter, foresaw when they created their tool, how it would play a significant role in big societal changes like the Arab spring or, sometimes these might be intentional. For example, it was a significant change when Facebook added new relationship statuses to its profiles to reflect things like civil unions. That simultaneously reflected something that was already changing at the societal level. But it also participated in that change and helped normalize those kinds of relationships. And that then relates back to the individual by making sure the interface is designed such that each individual feels like it's actually designed with them in mind. The options are there for them to feel like they're properly represented within the system. These are all components of the general user experience that we need to think about as we design interfaces.
108
10937 - Design Challenge: Morgan on the Street
110So keeping in mind everything we've talked about, let's design something for Morgan. Morgan walks to work, she likes to listen to audiobooks, mostly non fiction. But she doesn't just want to listen, she wants to be able to take notes and leave bookmarks. And do everything else you do when you're reading. What would designing for her look like, from the perspectives of viewing her as a processor, a predictor, and a participant? How much this different designs affect user experience as an individual in her local group of friends. And the society as a whole if the design caught on.
111
11238 - Design Challenge: Morgan on the Street Solution
113As a processor, we might simply look at what information is communicated to Morgan, when, and how. As a predictor, we might look instead at how the interface meshes with Morgan's needs with regard to this task, how easy it is to access, how easy the commands are to perform, and so on. As a participant, we might look at the broader interactions between this interface and Morgan's other tasks and social activities. You might look at how increased access to books changes her life in other ways. But really, this challenge is too big to address this quickly. So instead, let's return to this challenge throughout our conversations, and use it as a running dialogue to explore HCI principles and methods.
114
11539 - Introduction to Feedback Cycles
116Feedback cycles are the way in which people interact with the world, and then get feedback on the results of those interactions. We'll talk about the ubiquity of those feedback cycles. Then we'll talk about the gulf of execution, which is the distance between a user's goals and the execution of the actions required to realize those goals. Then we'll talk about the Gulf of evaluation, which is the distance between the effects of those actions and the user's understanding of those results. We'll discuss seven questions we should ask ourselves when designing feedback cycles for users and we'll also look at applications of these in multiple areas of our everyday lives.
117
11841 - Gulf of Execution
119In our feedback cycle diagram, we have on the left, some user and on the right, some task or system. The user puts some input into the system through the interface and the system communicates some output back to the user again through the interface. Incumbent on this are two general challenges, the user's interaction with the task through the interface and the task's return to the user of the output via the interface. The first is called the Gulf of execution. The Gulf of execution can be defined as how do I know what I can do. The user has some goals. How do they figure out how to make those goals a reality? How do they figure out what actions to take to make the state of the system match their goal state? This is the Gulf of execution. How hard is it to do in the interface what is necessary to accomplish the users' goals? Or alternatively, what's the difference between what the user thinks they should have to do and what they actually have to do. Now there are a number of components of this. The first component, they need to be able to identify what their goal is in the context of the system. There might be a mismatch between their own understanding and the system's structure. Think of transitioning from an old-fashioned VCR to a more modern DVR or from a DVR to watching things on-demand. The user needs to think of their goal in terms of their current system. Second, they need to be able to identify the actions necessary to accomplish their goals. Now that they know what their goal is in the context of the system, they need to identify the actions that it will take to make that goal a reality. And third, once I've identified those actions, they need to actually execute the actions within the interface. Again, imagine someone who's learning to use an on demand video interface, when they're used to using things like VCRs and DVRs. Their goal hasn't changed. They want to watch some program that's already aired. But in the context of a VCR or a DVR, their intention might be to record that program. In the context of an on demand video interface, their intentions instead are to call up the existing version of that program. That's a mismatch between what they think their goal is and what their goal is in the context of this new system. But once they understand what the goal means in their current system, they now need to know how to pull up that program. They need to know how to navigate the menus and find the program that they want to watch and then start it playing. And then once they know what to do, they need to actually execute that series of button presses. For example, they might know what actions to perform but they might not know where to find them. That would present a difficulty in executing those actions. So the gulf of execution takes the user from understanding their own goals to understanding their goals in the context of the system, to understanding the actions necessary to realize those goals, to actually executing those actions. And each of these presents some difficulties.
120
12140 - Feedback Cycles are Fundamental
122Feedback cycles are incredibly ubiquitous, whether or not there's a computational interface involved. Everything from reading to driving a car to interacting with other people could be an example of a feedback cycle in action. They're how we learn everything, from how to walk to how to solve a Rubik's cube to how to take the third order partial derivative of a function. I assume, I've never done that. We do something, we see the result, and we adjust what we do the next time accordingly. You may have even seen other examples of this before, too. If you've taken Ashok's and mine knowledge-based AI class, we talk about how agents are constantly interacting with, learning from, and affecting the world around them. That's a feedback cycle. If you've taken cyber physical systems course, you've seen this this without human involved at all, as a system can autonomously read input and react accordingly. Under some definitions, some people would even call this the artificial intelligence, specifically because it mimics what a human actually does. They act in the world and they evaluate the result. In fact, if you look at some of the definitions of intelligence out there, you'll find that many people actually define feedback cycles as the hallmark of intelligent behavior. Or they might define intelligence as abilities that must be gained through feedback cycles. Colvin's definition, for example, involves adjusting to one's environment, which means acting in it and then evaluating the results. Dearborn's definition of learning or profiting by experience is exactly this as well. You do something and experience the results, and learn from it. Adaptive behavior in general can be considered an example of a feedback cycle. Behavior means acting in the world. And adapting means processing the results and changing your behavior accordingly. And most generally, Schank's definition is clearly an ability gained through feedback cycles, getting better over time based on evaluation of the results of one's actions in the world. And Schank's general definition, getting better over time, is clearly something that can happen as a result of participation in a feedback cycle. We find that nearly all of HCI can be interpreted in some ways as an application of feedback cycles, whether between a person and a task, a person and an interface, or systems comprised of multiple people and multiple interfaces.
123
12442 - Gulf of Execution Example
125Let's take a simple example of the gulf of execution. I'm making my lunch, I have my bowl of chili in the microwave. My goal is simple, I want to heat it up. How hard is that? Well, typically when I've been cooking in the past, cooking is defined in terms of the amount of time it takes. So, in the context of this system, I specify my intent as to microwave it for one minute. Now what are the actions necessary to do so? I press Time Cook to enter the time-cooking mode, I enter the time, one minute, and I press Start. I didn't press Start just now, but I would press Start. I specified my intent, microwave for one minute. I specified my actions, pressing the right sequence of buttons, and I executed those actions. Could we make this better? There were a lot of button presses to microwave for just one minute. If we think that's a common behavior, we might be able to make it simpler. Instead of pressing Time Cook one, zero, zero and Start, I might just press one and wait. Watch. So I've narrowed the gulf of execution by shrinking the number of actions required, but I may have enlarged it by making it more difficult to identify the actions required. When I look at the microwave, Time Cook gives me an idea of what that button does. So if I'm a novice at this, I can discover how to accomplish my goal. That's good for the gulf of execution. It's easier to look at the button and figure out what to do than to have to go look, read a manual, or anything like that and find out on your own. But once you know that all you have to do is press one, that's much easier to execute. That's something nice about this interface, it caters to both novices and experts, there's a hard and discoverable way and a short and visible way. But let's rewind all the way back to the goal I set up initially, my goal was to heat up my chili. I specified my intent in terms of the system as microwaving it for one minute. But was that the right thing to do? After one minute, my chili might not be hot enough, this microwave actually has an automatic reheat function that senses the food's temperature and stops when the time seems right. So the best bridge over the gulf of execution might also involve helping me reframe my intention. Instead of going to microwave for one minute, it might encourage me to reframe this as simply heating until ready and letting the microwave do the rest.
126
12743 - Gulf of Evaluation Example
128Let's take a thermostat, for example. I have a goal to make the room warmer, so I do something to my thermostat with the intention of making the room warmer. What does the system do as a result? Well, it turns the heat on, that would be the successful result of my action. But how do I know that the heat was turned on? Well, maybe I can hear it, I might hear it click on. But that's a one time kind of thing and it might be quiet. And if I'm mishearing it, I have no way of double checking it. So I'm not sure if I heard it, and I have to go find a vent and put my hand on it and try to feel the heat coming out. And there's more going on in a heater, it might have worked, but the heater doesn't immediately turn on for one reason or the other. These are signs of a large gulf of evaluation. Neither the sound or the vent are optimal displays because they're either hard to reach or possible to miss. Feeling the heat might be easy to interpret, but hearing the heater turn on might not. So either way, I have to do a lot to evaluate whether or not my action was successful. And this is all for a very small piece of feedback. Ideally if I wasn't successful, we want the system to also tell me why I wasn't successful so I can evaluate what I did wrong and respond accordingly. There's a very large gulf of evaluation if there's no indicator on the actual thermostat. So how can we resolve that? Well, simple. We just mark on the thermostat that the heat is on. That sounds trivial, but nothing in the fundamental design of this system demanded a note like this. It's only in thinking about the system from the perspective of the user that we find that need. I can let you know as well, this system still isn't very ideal. For various reasons, it'll turn the heater on or the air conditioning off even when it hasn't reached the temperature I put in. And it gives me no indication of why. I can look at the system and evaluate that the temperature is set to lower than the current temperature in the room. But at the same time, I can see that the heater isn't on. Under those circumstances, I have no way of knowing if the heater's malfunctioning, if the switch is wrong, or I don't even know. In this case, it might just be that it's set to the wrong mode. The mode is visible, but after I remembered to check it, it appears to be malfunctioning. We can imagine an alternative message on the screen indicating the direction of the relationship or something similar that would give some sign that it's currently set incorrectly.
129
13044 - Good Design, Bad Design: Feedback Cycles
131Good design. A phone that quietly clicks every time a letter is successfully pressed to let you know that the press has been received. Bad design. A phone that loudly shouts every letter you type. P. I. C. Remember small actions get small feedback. The only time you might want your device to yell a confirmation at you is, if you’d just ordered a nuclear launch or something.
132
13345 - Reflections: Feedback Cycles
134Let's pause for a second, and reflect on the roles of gulfs of execution and gulfs of evaluation in our own lives. So try to think of a time when you've encountered a wide gulf of execution, and a wide gulf of evaluation. This doesn't have to be a computer, it could be any interface. In other words, what was a time when you were interacting with an interface, but couldn't think of how to accomplish what you wanted to accomplish? What was a time when you were interacting with an interface and couldn't tell if you'd accomplished what you wanted to accomplish?
135
13646 - Reflections: Feedback Cycles Solution
137It's not a coincidence that I'm filming this in my basement. This actually happened to me a few weeks ago. The circuit to our basement was tripped, which is where we keep our modem, so our internet was out. Now this is a brand new house and it was the first time we tripped a breaker, so I pulled out my flashlight and I opened the panel. And none of the labels over here clearly corresponded to the breaker I was looking for over here. I ended up trying every single one of them and still it didn't work. I shut off everything in the house. Why didn't it work? In reality, there was a reset button on the outlet itself that had to be pressed. The only reason we noticed it was because my wife noticed something out of the corner of her eye turning on and off as I switched these. That was a terribly large gulf of execution. I knew what I wanted to accomplish, I could translate it into the system's terms easily, reset a breaker. But figuring out the actions to accomplish that goal was very difficult. That's a large gulf of execution. How was that? So I have no way of knowing if that was good or not? Isn't that a terrible gulf of evaluation? I joke, but a lack of feedback on your performance at a task, whether it be filming, like I'm doing now or doing a project like you’ll do later in our material, presents the same kind of poor gulf of evaluation.
138
13947 - Feedback Cycles in David's Car 1
14015 years ago we might not have talked about cars in the context of discussing HCI, but nowadays this is basically a computer on wheels. So let's talk a little bit about how feedback cycles apply here. Let's start with the ignition. The button that I start my car is right here. Why is it located there?
141
14248 - Feedback Cycles in David's Car 1 Solution
143Before cars had push button starts, this is where you inserted the key to turn on the ignition. Why? I have no idea. But I do know that now, the start button can be placed in any number of different locations. So why do we put it where we've always put it? Well, the reason is, that's where the driver expects it to be placed. We help them across the gulf of execution by designing a system that's consistent with their expectations about how it should work. It makes it easier for them to translate their intentions into actions. Now, other times we might violate this principle because of some other benefits we hope to gain. But generally speaking, when all else is equal, we want to stay consistent with the way users expect our systems to work.
144
14549 - Feedback Cycles in David's Car 2
146So we know where the ignition button is. Let's press it. Do you think the car turned on?
147
14850 - Feedback Cycles in David's Car 2 Solution
149Well, what do we know? We know the car was off. We know this is clearly the power button based on how it's labeled and where it's located. And most importantly, when I pressed it we heard kind of a happy confirmation-y sound. So did the car turn on? Actually, it didn't. To turn this car on you have press the brake petal while pressing the on button. The car doesn't do a great job of helping us across that goal of execution. There's no indicator that you're doing it wrong until you've actually already done it wrong. But the car does give us a short gulf of evaluation. If you do it incorrectly, an alert pops up on the dashboard letting you know you need to press the brake pedal and then press the on button. The output presented is easy to interpret. As presented in the context of when you need to know that information, so you kind of understand that it’s a response to what you just did. So here we have some trouble with the gulf of execution but the gulf of evaluation is still pretty short. So now that I see this message I press down the brake pedal, press the on button and now the car is on.
150
15151 - Feedback Cycles in David's Car 3
152So now that we've seen the way this feedback cycle currently works, let's talk about improving it. How might we make this feedback cycle even better? How might we narrow the gulf of execution and the gulf of evaluation?
153
15452 - Feedback Cycles in David's Car 3 Solution
155So here are a few ideas that I had. We know that the screen can show an alert when you try to turn the car on without pressing the brake pedal down. Why not show that alert as soon as the driver gets in the car every time? That doesn't widen the gulf of execution for an expert user, but it does narrow it for a novice user, because even a novice can see that alert the first time they get in the car. But what still throws me off to this day is the sound the car makes when you try and turn it on. Watch. Now it turned on. So it plays the same sound initially when you press the button and then plays a different follow up sound to confirm that the car actually turned on. I know why they do this, that one sound just confirms that you pressed the button successfully while the other sound confirms that the car turned on. But for me, I would just as soon have two different sounds confirm whether or not you just pressed the button or whether the car turned on. That way, just the presence of a sound confirms the fact that the button was pressed and the nature of the sound confirms the effect of that press.
156
15753 - Design Challenge: Credit Card Readers 1
158Lately I've encountered another interesting example of feedback cycles in action. You may have actually seen this before as well. They're the new credit card readers. My wife sells arts and crafts at local events, and so she has these Square readers that can scan credit cards on her phone. One version lets you swipe, and the new version lets you insert the card. So let's check this out real quick. With the swipe version you just insert the card and pull it through, just like a traditional card reader. The problem is there's typically no feedback on whether you're swiping correctly. And what's more is you can be wrong in both directions. You can be both too fast or too slow. So you may have had a time when you were trying to swipe a credit card on some kind of reader, and you kept doing it more and more slowly and deliberately, thinking that the problem was that you had done it too fast originally. And then you discover that you've actually been going too slowly all along and your slowing down was actually counterproductive. There's no feedback here and the space and acceptable input is bounded on both sides. You have to go above one speed and below another speed. But now credit card readers are moving to this model where you just insert the card. You try, at least. In terms of feedback cycles, in what ways is this actually better?
159
16054 - Design Challenge: Credit Card Readers 1 Solution
161First, in terms of the gulf of execution, the insertion method is actually physically easier to do. While you can be both too fast and too slow with the sliding method, you can't push it too far in with the insertion method. So you know if there's an error, it's because the card isn't far enough into the reader. And second, there's rich feedback with the insertion method. It doesn't even have to come from the screen telling you that you didn't do it correctly. You feel the card stop when it's far enough into the reader. You have immediate physical feedback on whether you're putting it in the right place, and whether you've actually put it far enough in, rather than delayed feedback asking you to try again after some kind of waiting period.
162
16355 - Design Challenge: Credit Card Readers 2
164So, using the insertion method is significantly easier. However, the insertion method introduces a new problem. With the sliding method, I never had to actually physically let go of my card, so there was little chance of me walking away without it. With the insertion method, I insert the card and I wait. I'm not used to having to remember to retrieve my card from the card reader. Now this isn't quite as big a deal with these new portable readers, but for the mounted ones you see in stores it can be far more problematic. So how can we build some feedback into the system to make sure people remember their cards when they walk away?
165
16656 - Design Challenge: Credit Card Readers 2 Solution
167There are a few things we could do here. We might build some kind of buzzer into the card reader to let the customer know when they can take their card out. That would make sure that they don't leave without it. ATM machines often do this, actually. They'll ring a buzzer until the card and the cash are removed. But that's noisy and potentially irritating. It would mess with the ambiance of a restaurant or something like that. We could do something super complicated, like pair the credit card with a smartphone and ring the phone when it gets too far away from the credit card. But that requires adding some new technology to every single credit card, which could be a pretty big expense. So what about something simpler? Why not force a customer to remove the credit card in order to get the receipt and their goods? Unless they're going to walk away without what they came to buy, that'll ensure that they remember their card.
168
16957 - Design Challenge: Credit Card Readers 3
170Now notice one last thing about this example. We've been discussing how to make the process of sliding or swiping a credit card easier. What's wrong with that question?
171
17258 - Design Challenge: Credit Card Readers 3 Solution
173The problem is that we're not focused on the right task. Our task shouldn't be to swipe a credit card, or insert a credit card, or anything like that. Our task should be how to most easily pay for purchases. And possibly the easiest way to do that would be to design a system that lets you just tap your phone against the reader, this reader actually does that. That way, we can use the thing that people have on them at all times. Now maybe that's isn't the best option for various other reasons, but the important thing is we need to focus on what we're really trying to accomplish. Not just how we've done it in the past. We can make incremental improvements just sliding or swiping or inserting a credit card all we want. But we should always keep our eyes on the underlying task that the user needs to accomplish.
174
17559 - Introduction to Direct Manipulation and Invisible Interfaces
176Today we'll talk about two applications of good feedback cycles. Direct manipulation and invisible interfaces. Direct manipulation is the principle that the user should feel as much as possible like they're directly controlling the object of their task. So for example, if you're trying to enlarge an image on your phone, it might be better to be able to drag it with your fingers rather than tapping a button that says, zoom in. That way you're really interacting directly with the photo. New technologies like touch screens are making it more and more possible to feel like we're directly manipulating something, even when there's an interface in the way. At their best, the interface actually disappears, which is what we mean by an invisible interface. With an invisible interface the user has to spend no time thinking about the interface that they're using. All their time is dedicated to thinking about the task that they're performing.
177
17860 - Direct Manipulation The Desktop Metaphor 1
179Our goal is to narrow the gulf of execution and the gulf of evaluation as much as possible. And arguably the ultimate form of this is something called direct manipulation. Now today direct manipulation is a very common interaction style. But in the history of HCI it was a revolutionary new approach. Now to understand direct manipulation, let's talk about the desktop metaphor. The files and folders on your computer are meant to mimic physical files and folders on a desktop. So, here are on my physical desktop, I have some files. What do I do if I want to move them? Well, I pick them up and I move them. What do I do if I want to put them in a folder? I pick them up and put them in the folder. I'm physically moving the files from where they are to where I want them to be. If files and folders on a computer are meant to mimic files and folders on a physical desk, then shouldn't the act of moving them also mimic the real world action of moving them? Wouldn't it narrow the gulf execution to leverage that real world experience and that real world expectation?
180
18161 - Direct Manipulation The Desktop Metaphor 2
182Files and folders on my computer are meant to mimic files and folders on my physical desk. So we ideally want the action of moving them around on my computer to mimic the action of moving them around on my physical desk. But it wasn't always like this. Before graphical user interfaces were common, we moved files around using command line interfaces like this. The folder structure is still the same on the operating system. But instead of visualizing it as folders and icons, I'm interacting with a text-based command line. To view the files, I might need to type a command like ls, which I just have to remember. If I don't remember that command, I don't have much recourse to go find out what I'm supposed to be doing. To move a file, I need to type something like this. I have to type the command, the file I want to move, and the folder I want to move it to. Again, if I forget the name of that command, or the order of the parameters to provide, there's not a whole lot I can to to recover from that. I need to run off to Google and find out what the correct order of the commands was. Which is actually what I did before filming this video because I don't actually use the terminal very often. Then when I execute that command, there's not a lot of feedback to let me know if it actually executed correctly. I might need to change folders to find out. There I see the files present in that folder but I had to go and look manually. There's nothing really natural about this. Now don't get me wrong, once you know how to interact with this interface, it's very efficient to use. But when you're a novice at it, when you've never used it before, this is completely unlike the task of managing physical files on your real desk. Then, the computer mouse came along. And with it came the ability to move a mouse around the screen. Equipped with this, my action in moving files and folders becomes much more direct. I can actually just click the file I want to move and drag it into the new folder. I get instant feedback by the fact that the file disappeared as soon as I dragged it over. And there was a sound effect that you may or may not have been able to hear. So now instead of typing in some cryptic command that I just have to be able remember, I can just click on the file I want to move, and physically drag it to the folder in which I want to have it. That's a very natural interaction, it mimics what I do on my physical desk. Moving the mouse around is a lot better than having to type in those commands, but the gulf of execution and evaluation are still present, especially for some novice users. There's still some interpretation that has to happen to understand that when I move my hand a little left on the mouse, the cursor on screen will move to the left as well. And while clicking feels kind of like grabbing, there's still some interpretation there. It's more direct than the command line, but there's still a gap. The modern touchscreens made direct manipulation more direct than ever. Let's say I want to put an icon into a folder on my screen. How do I do it? I hold down the icon, and I drag it to the screen. The fact that if I wanted to move something around my desk, I would have to hold it down, means that this is almost entirely direct manipulation. I don't need any prior knowledge to attempt to do what feels natural for moving that icon into that folder. That gives us a nice, general heuristic to keep in mind. How do we help the user interact most closely with the target of their task? How do we make it so they're manipulating it as directly as possible?
183
18462 - Reflections: Direct Manipulation
185Take a moment real quick and reflect on some of the tasks you perform with computers day-to-day. What are some of the places where you don't interact through direct manipulation? If you're having trouble thinking of one, think especially about places where technology is replacing things you used to do manually. Chances are, the physical interface was a bit closer to the task than the new technical one. How can the technical interface better leverage direct manipulation?
186
18763 - Reflections: Direct Manipulation Solution
188When I was writing the script for this exact video, I was interrupted by a text message from a friend of mine. And in the reply I was writing, I wanted to include a smiley face. We know that using emojis and emoticons tends to humanize textual communication. On my phone, the interface for inserting an emoji is to tap an icon to bring up a list of all the emojis and then select the one that you want. When I'm reacting to someone in conversation, I'm not mentally scrolling through a list of all my possible emotions and then choosing the one that corresponds. I'm just reacting naturally. Why can't my phone capture that? Instead of having to select smiling from a list of emotions, maybe my phone could just have a button to insert the emotion corresponding to my current facial expression. So to wink, I would just wink. To frown, I would just frown. It wouldn't be possible to capture every possible face, but for some of the most commonly used ones, it might be more efficient.
189
19064 - Babies and Direct Manipulation
191There may be no better example of the power of direct manipulation than watching a baby use an interface. Let's watch my daughter, Lucy, try and use her Kindle Fire tablet. My daughter Lucy is 18 months old, yet when I give her an interface that uses direct manipulation, she's able to use it. She wouldn't be able to use a keyboard or a mouse yet, but because she's directly interacting with the things on the screen, she can use it. Actually, there might be an even better example of direct manipulation in action. There are games made for tablet computers for cats. Yes, cats can use tablet computers when they use direct manipulation.
192
19365 - Exercise: Direct Manipulation
194Let's try a quick exercise on direct manipulation. The Mac touchpad is famous for facilitating a lot of different kinds of interactions. For example, I can press on it to click, press the two fingers to right-click. I can pull up and down with two fingers to scroll up and down. I can double tap with two fingers to scroll in and out a little bit. And I can pinch to zoom in and out a lot more. Which of these are good examples of direct manipulation in action?
195
19666 - Exercise: Direct Manipulation Solution
197Now there's some room for disagreement here, but I think these five seem to be pretty cut and dry. We can think about whether or not these are direct manipulation by considering whether or not what we're doing to the touchpad is what we'd like to do to the screen itself. For clicking, I would consider that direct manipulation because just as we press directly on the screen we're pressing directly on a touchpad. Right-clicking though, the two finger tap, doesn't really exemplify direct manipulation, because there's nothing natural about using two fingers to bring up a context menu as opposed to using one to click. We have to kind of learn that behavior. Scrolling makes sense because with scrolling it's like I'm physically pulling the page up and down to see different portions of it. The two finger tap for zooming in and out a little bit though isn't really direct manipulation, because there's no real clear reason that needs to zoom in, zoom out. Pinching on the other hand though, makes sense. Because it's as if I'm physically grabbing the page and shrinking and enlarging it. So some of these I would say are pretty good examples of direct manipulation. While others are things that we kind of have learn to do.
198
19967 - Making Indirect Manipulation Direct
200The Mac Touchpad has some interesting examples of how you can make indirect manipulation feel more direct. For example, if I swipe from the right to the left on the touchpad with two fingers, it pulls up this notification center over on the right. This feels direct because the notification center popped up in the same place on the screen that I swiped on the touchpad. The touchpad is almost like a miniature version of the screen. But they could have placed a notification center anywhere and used any kind of interaction to pull it up. This isn't like scrolling where there is something fundamental about the content that demands a certain kind of interaction. They could have designed this however they wanted. But by placing the notification center there and using that interaction to pull it up, it feels more direct. Now, animation can also help us accomplish this. On the Touchpad, I can clear the windows off my desktop by kind of spreading out my fingers on the touchpad, and the animation shows them going off to the side. And while that's kind of like clearing off your desk, I'd argue it's not close enough to feel direct except that the animation on screen mimics that action as well. The windows could have faded away or they could have just slid to the bottom and still accomplish the same function of hiding what's on my desktop. But the animation they chose reinforces that interaction. It makes it feel more direct. The same thing actually applies with Launchpad, which we bring up with the opposite function by pinching our fingers together. The animation looks kind of like we're pulling back a little bit or zooming out and we see the launch pad come into view, just as the gesture is similar to zooming out on the screen. So direct manipulation isn't just about designing interactions that feel like you're directly manipulating the interface. It's also about designing interfaces that lend themselves to interactions that feel more direct.
201
20268 - Invisible Interfaces
203Whether through using direct manipulation, through innovative approaches to shrinking these gulfs or through the user's patience and learning, our ultimate goal is for the interface between the user and the task to become invisible. What this means is that even though there is an interface in the middle, the user spends no time thinking about it. Instead, they feel like they're interacting directly with the task rather than with some interface. So for example, I have a stylus and I'm going to write on this tablet computer. I'm interacting with an interface just translating my drawing into data in the system. But for me, this feels just like I'm writing on a normal page. That feels just like writing on paper. This interface between me and the data representation of my drawing underneath is pretty much invisible. I feel like I'm writing on paper. Contrast that with trying to draw with a mouse. That feels extremely unnatural. I'm very well aware of the mouse as the interface between myself and this drawing task. So the direct manipulation facilitated by the stylus gets me much closer to my task and helps the interface disappear between me and what I'm trying to accomplish.
204
20569 - Good Design, Bad Design Invisible Interfaces
206Good design. Interfaces that are metaphorically invisible. Bad design, interfaces that are literally invisible. Well, kind of, just your base interfaces are in one sense literally invisible, that's actually why it's so important to give great feedback. Because otherwise, it's tough to gauge the success of a gesture interaction.
207
20870 - Invisibility by Learning
209We shouldn't fall into the trap of assuming that just because an interface has become invisible, the design is great. Interfaces become invisible not just through great design, but also because users learn to use them. With enough practice and experience, many users will become sufficiently comfortable with many interfaces to feel invisibly integrated in the task. So take driving for example. Lets say I'm driving a car and I discover I'm headed right for someone. What's my reaction? Well I turn the wheel to the side and I press my brake. It's instinctive. I do it immediately, but think about that action. If I was just running down the street and suddenly I saw someone in front of me would it be natural for me to go like that? Of course not. The steering wheel was an interface I used to turn to the left. But it's become invisible during the task of driving because of all my practice with it. But just because the interface has become invisible doesn't mean it's great interface. People spend months learning to drive, they pay hundreds of dollars for classes. And they have to pass a complicated test. Driving is important enough that it can have that kind of learning curve. But for the interfaces that we design, we generally can't expect users to give us an entire year just to learn to use them. We'll be lucky if they give us an entire minute to learn to use them. So our goal is to make our interfaces invisible by design.
210
21171 - Invisibility by Design
212Our goal is to create interfaces that are invisible from the moment the user starts using them. They should feel immediately as if they're interacting with the task underlying the interface. Now this is an extremely tall order and one we honestly probably won't meet very often, but it's the goal. In fact, in my opinion, this is why people tend to underestimate the complexity of HCI. When you do things right, people won't be aware that you've done anything at all. So how do we create interfaces that are invisible from the very first moment the user starts using them? That's precisely what we'll discuss in a lot of our conversations about HCI. We'll talk about principles for creating interfaces that disappear like leveraging prior expectations and providing quick feedback. We'll also talk a lot about how to get inside the user's head and understand what they're seeing when they look at an interface that we can make sure that they're internal mental model matches the system. In fact, if we consider invisibility to be a hallmark of usable design, then this entire course could be retitled Creating Invisible Interfaces.
213
21472 - Reflections: Invisibility by Design
215Reflecting on where we've encountered invisible interfaces is difficult, because they were invisible. What makes them so good is the fact that we didn't have to notice them. But give it a try anyway. Try to think of a time where you picked up a new interface for the very first time and immediately knew exactly how to use it to accomplish the task you had in mind.
216
21773 - Reflections: Invisibility by Design Solution
218One of my favorite examples of an interface that is invisible by design comes from a video game called Portal 2. In lots of video games, you use a control stick to control the camera in game, but different people have different preferences for how the camera should behave. Some feel if you press up, you should look up. Others like myself, feel if you press down you should look up, more like you're controlling an airplane with a joystick. In most games you have to set this manually by going to options, selecting camera controls, and enabling or disabling a y axis and it's just a chore. But in portal two, watch what happens. You will here a buzzer. When you hear the buzzer, look up at the ceiling. Good. This completes the gymnastic portion of your mandatory physical and mental wellness exercise. Did you see that? It was so subtle you might not have even noticed it. A character in the game asked me to look up. The game assumed whichever direction I pressed was the way I would want to press when I want to look up. And set my preference accordingly. No option screen, no changing settings. The game automatically and invisibly had me complete my goal of correctly setting my camera preference.
219
22074 - Design Challenge: The Universal Remote
221For this design challenge, let's tackle one of the most common problems addressed in undergraduate HCI classes, designing a better remote control. Now, these probably aren't very good interfaces. And that's not to say that they're poorly designed, but the constraints on how many different things they have to do and how limiting the physical structure can be, make these difficult to use. You might have seen humorous images online of people putting tape over certain buttons on the controls to make them easier to use for their parents or their kids. How would we design an invisible interface for universal remote control, one that doesn't have the learning curves that these have?
222
22375 - Design Challenge: The Universal Remote Solution
224Personally I think this is a great candidate for a voice interface. And in fact, Comcast, Amazon and others have already started experimenting with voice interfaces for remote controls. One of the challenges with voice interfaces is that generally the commands aren't very discoverable. Generally, if you don't know what you can say, you have no way of finding out. But watching TV and movies is such a normal part of our conversations that we already have a vocabulary of how to say what we want to do. The challenge is for us designers to make a system that can understand that vocabulary. That way when I say, watch Community, it understands that Community is a TV show and it tries to figure out, do I grab it from the DVR, do I grab it from On Demand, do I see if it's on live? The vocabulary for the user was very natural. So for example, watch Conan. Well tonight, a fan named David Joiner thinks he caught a mistake. He says it happened when I was telling a joke recently about Rand Paul. Hey Conan, I was watching your episode on April 17th, and you said that Rand Paul wanted to run for president. I had to put that in there somewhere.
225
22676 - Introduction to Human Abilities
227Human computer interaction starts with human. So it's important that we understand who the human is, and what they're capable of doing. In this lesson, we're going to bring up some psychology of what humans can do. We'll look at three systems. Input, processing, and output. Input is how stimuli are sent from the world, and perceived inside the mind. Processing is cognition, how the brain stores, and reasons over the input it's received. Output is how the brain then controls the individual's actions out in the world. Now, we're going to cover a lot of material at a very high level. If you're interested in hearing more, I recommend taking a psychology class, especially one focusing on sensation and perception. We'll put some recommended courses in the notes.
228
22977 - Information Processing
230In discussing human abilities, we're going to adopt something similar to the processor view of the human. For now we're interested in what they can do, physically, cognitively, and so on. So we're going to focus exclusively on what's going on over here. We're going to look at how the person makes sense of input, and how they then act in the world. And right now, we're not going to worry too much about where that input came from, or what their actions in the world actually do. Notice that in this lesson we're discussing the human, almost the same way we discuss the computer, or the interface, in most lessons. The human is something that produces output and consumes input, just like a computer might be otherwise. But for now, we're only interested in how the human does this.
231
23278 - Sensation and Perception: Visual
233Let's start by talking a bit about what the average person can sense and perceive. So, here we have Morgan again. Morgan has eyes. Morgan's eyes are useful for a lot of things. The center of Morgan's eye is most useful for focusing closely on color or tracking movement. So, we can assume that the most important details should be placed in the center of her view. Morgan's peripheral vision is good for detecting motion, but it isn't as good for detecting color or detail. So while we might use her periphery for some alerts, we shouldn't require her to focus closely on anything out there. As a woman, Morgan is unlikely to be colorblind, she has about a 1 in 200 chance. Men have a much greater prevalence of color blindness at about 1 in 12. Either way, that's a significant body of people. So we want to avoid relying on color to understand the interface. We can use it to emphasize knowledge that it's already present in the system, but using the system shouldn't rely on perceiving color. Sight is directional. If Morgan's looking the wrong way or has her eyes closed, she'll miss visual feedback. As Morgan gets older, her visual acuity will decrease. So if we're designing something with older audiences in mind, we want to be careful of things like font size. Ideally, these would be adjustable to meet the needs of multiple audiences. All together though, Morgan's visual system is hugely important to her cognition. The majority of concepts we cover in HCI are likely connected to visual perception.
234
23579 - Sensation and Perception: Auditory
236Morgan also has ears. Morgan can discern noises based on both their pitch and their loudness. Her ears are remarkably good at localizing sound as well. In fact, she can tell the difference between a nearby quiet sound and a far away loud sound. Even if their relative pitches and loudnesses are the same when they reach her ear. Unlike vision, hearing isn't directional. Morgan can't close her ears or point her ears the wrong direction so she can't as easily filter out auditory information. That might be useful for designing alerts, but it's problematic for overwhelming her or sharing too much information with the people around her.
237
23880 - Sensation and Perception: Haptic
239Morgan's skin can feel things. It can't feel at a distance but it can feel when things are touching right up against it. It can feel a variety of different types of input, like pressure, vibration and temperature. Like listening, Morgan can't easily filter out touch feedback. But unlike listening, touch feedback is generally only available to the person it's touching, so it can be used to create more personal feedback. Traditionally, touch feedback, or haptic feedback, has been very natural. Morgan feels the keys go down as she presses them on keyboard. But with touchscreens, motion controls and virtual reality, touch needs to be more and more designed explicitly into the system if we're to use it.
240
24181 - Design Challenge: Message Alerts
242Let's design something for Morgan real quick. Let's tackle the common problem of being alerted when you've received a text message. Here are the constraints on our design for Morgan. It must alert her whether the phone is in her pocket or on the table. It cannot disturb the people around her. And yes, vibrating loudly against the table counts as disturbing the people around her. You're not restricted to just one modality, though, but you are restricted to the sensors that the phone has available.
243
24482 - Design Challenge: Message Alerts Solution
245Here's one possible design. We know that smartphones have cameras and light sensors on them. We can use that to determine where the phone is, and what kind of alert it should trigger. If the sensor detects light, that means the screen is visible, so it might alert her simply by flashing its flashlight or illuminating the screen. If the sensor does not detect light, it would infer that the phone is in her pocket and thus, would vibrate instead. Now, of course, this isn't perfect. It could be in her purse, or she could have put it face down. That's why we iterate on a design like this, to improve it based on the user's experiences.
246
24783 - Memory: Perceptual Store
248After the perception portion of this model comes the cognition portion, starting with memory. There are lots of different models of memory out there. For our purposes we're going to talk about three different kinds of memory, the perceptual store or working memory, the short-term memory, and the long term memory. Some scientists argue that there are other types of memory as well, like an intermediate sort of back of the mind memory. But the greatest consensus is around the existence of at least these three kinds. So let's start with the first, the perceptual store or the working memory. The perceptual store is a very short term memory lasting less than a second. One of the most common models of working memory came from Baddeley and Hitch in 1974. They described it as having three parts. First, there's the visuospatial sketchpad which holds visual information for active manipulation. So for example, picture a pencil. The visuospatial sketchpad is where you're currently seeing that pencil. A second part is the phonological loop. The phonological loop is similar, but for verbal or auditory information. It stores the sounds or speech you've heard recently, such as the sound of me talking to you right now. A third part is the episodic buffer. The episodic buffer takes care of integrating information from the other systems as well as chronological ordering to put things in place. Finally all three of these are coordinated by a central executive. So let's try an example of this. I'm going to very quickly show you a picture and ask you a question about it. Don't focus on any particular portion of the picture, try to view it as a whole. What was the score on the scoreboard?
249
25084 - Memory: Perceptual Store Solution
251As you can now see, the score was 0 to 0. Now, as you tried to reason over that, what you probably did was picture the image in your mind. That was trying to reason over what was stored in the perceptual buffer, and it decayed very quickly. However, if you're a fan of baseball, you probably had a better chance of getting that right. That's because you have some domain expertise. You're better able to process images about that domain more quickly. You might, for example, have recognized that most of the innings weren't marked. So that increases the odds that the score of the game was pretty low. This idea is actually the foundation of a fascinating study about chess experts versus novices and recognizing the configuration of chess boards. The study found that experts were far better than novices at remembering realistic chess boards that were only flashed for a short period of time, like the one on the left. But experts were no better than novices at remembering random chessboards. So expertise, or rehearsal, delays the decay of the perceptual buffer.
252
25385 - Memory: Short-Term and Chunking
254When we're designing interfaces, short-term memory is one of our biggest concerns. It's important we avoid requiring the user to keep too much stored in short-term memory at a time. Current research shows that users can really only store four to five chunks of information at a time. For a long time, there was a popular idea that people could store seven, plus or minus two, items in memory at a time. But more recent research suggests that the number is really four to five chunks. There are two principals we need to keep in mind here though. The first, is the idea of chunking. Chunking is grouping together several bits of information into one chunk to remember. So to illustrate this, let's try it out. I'm about to show you six combinations of letters. Try to memorize them and then enter them into the exercise that pops up. Are you ready? Now to keep you from just rehearsing it in your perceptual store until you can reenter it, I'm going to stall and show you some pictures of my cats. There's one. There's both of them, and here's my daughter. Okay, now fill in the words.
255
25686 - Memory: Short-Term and Chunking Solution
257So what happened? Well, what likely happened is that you maybe had only a little bit of trouble remembering the two real words that were listed on the right. You might have had some more trouble remembering the two words that were listed in the middle that were fake words, but did nonetheless look like real words. And you probably had a lot of trouble remembering the two series of letters over on the left. Why is all of that? Well, when it came to memorizing these two words, you were just calling up a chunk that you've already had. You didn't see these as arbitrary collections of letters, you just saw them as words. For the ones in the middle, you've never seen those combinations of letters before, but you could pronounce them as if they were words. So you likely saw them as fake words rather than just random collection of letters. For these over the left though, you had to memorize five individual characters. So that's means that while these four were able to jump in the words or pseudo words. These likely had to be remembered as five chunks each. That's makes this much more difficult to remember than these.
258
25987 - Memory: Short-Term and Recognition
260However, there is a way we can make this easier. So let's ask a different question. Which of these six words did you see in the exercise previously?
261
26288 - Memory: Short-Term and Recognition Solution
263Even if you had trouble just naming these series of letters in the exercise previously. You probably were much more successful at this exercise. Why is that? That's because it's far easier to recognize something you know than to recall it independently. And that's a useful take away for us as we design interfaces. We can minimize the memory load on the user by relying more on their ability to recognize things than to recall them
264
26589 - Memory: Short-Term Takeaways
266So what are the implications of short term memory for HCI? We don't want to ask the user to hold too much in memory at a time, four to five chunks is all. Asking the user to hold ten numbers in short term memory, for example, would probably be too much. But we can increase the user's effective short term memory capacity by helping them chunk things. For example, this is probably by far easier to remember, even though it's the same content. We've shrunk ten items into three. And we've used a format for phone numbers with which you're probably familiar if you're in the United States. If you're from outside the U.S., you might be familiar with a different grouping. But the same principle applies. And finally, when possible, we should leverage recognition over recall. For example, if I ask you to recite the number, maybe you could. In fact, go ahead. Try it. Whether or not you could do that, you almost certainly, though, can pick it from this list. This is one of the reasons why menu bars and tool strips are so ubiquitous in software design. The user doesn't have to remember the icon for a command or the name of an option. They just have to recognize it when they see it.
267
26890 - Memory: Long-Term Memory
269Finally, we have long-term memory. Long-term memory is a seemingly unlimited store of memories, but it's harder to put something into long-term memory, than to put it into short-term memory. In fact, to load something into long-term memory, you generally need to put it into short-term memory several times. To demonstrate this, I'm going to describe something called lightner system. The lightner system is a way of memorizing key value pairs, or in other words memorizing flashcards. Those can be words and their definitions, countries and their capitals, laws and their formulas, anything where you're given a key and asked to return a value. So I have some flashcards here that have the capitals of the world. What I do is go through each one, read the country, check to see if I remember the capital. And if I do, I'll put it in the pile on the right. I read the country and don't know the capital, I'll put it in the pile on the left. So let me do that real quick. Now tomorrow, I will just go through the pile on the left. Any that I remember from the pile on the left tomorrow, I'll move to the pile on the right. Any that I still don't remember, will stay in the pile on the left. So I'm focusing my attention on those that I don't yet know. In four days, I'll go through the pile on the right. And any that I don't remember then, I'll move back to my pile on the left, to remind me to go through them each day. So the things that I remember least, are most often loaded in the short-term memory, solidifying them in my long-term memory. Now in practice, you wouldn't just do this with two piles, you'd do a three, or four, or five. And the long restoration pile you'd might only go through yearly, just to see if it's decayed yet.
270
27191 - Cognition: Cognitive Load
272To talk about cognitive load, let's think for a moment of the brain like it's a computer. The community is actually divided on whether or not the brain actually operates this way, but for the purposes of this explanation, it's a useful metaphor. So your brain has a certain number of resources available to it, the same way your computer has a certain number of processor resources available to it. Each thing that the brain is working on takes up some of those resources. Let's say your at home in a quiet area, working on a calculus problem that requires 60% of your cognitive resources. In that setting, you have plenty of resources to solve that problem. However, then you go to take a calculus test. Now you have some stress in there. Now you're stressing about the impact this test is going to have on your grade. You're stressing about how well other people seem to think they are doing on it. Whether or not other people seem to be struggling while you struggle. This is taking up a lot of your cognitive resources. Here we see the stress taking up 50% of the cognitive resources you have. Now you don't have sufficient resources to complete the problem successfully. I hypothesize that's why test taking anxiety can have such a negative effect. It takes resources away from actually working on the test. You can apply these same principles to the presence of distractions, anxiety disorders and more. Cognitive load has two major applications to our working design interfaces. One, we want to reduce the cognitive load posed by the interface, so that the user can focus on the task. Second, we want to understand the context of what else is going on while users are using our interface. We need to understand what else is competing for the cognitive resources users need to use our interface. If we're designing a GPS or navigation system for example, we want to be aware that the user will have relatively few cognitive resources because they're focusing on so many things at once.
273
27492 - Reflections: Cognitive Load
275Let's take a second and reflect on cognitive load. Try to think of a task where you've encountered a high cognitive load. What different things did you have to keep in mind at the same time? And how could an interface have actually helped you with this problem?
276
27793 - Reflections: Cognitive Load Solution
278Computer programming is one task with an incredibly high cognitive load. At any given time, you're likely holding in working memory your goals for this line of code, your goals for this function, your goals for this portion of the program as a whole, the variables you've created and a lot more. That's why there's so many jokes about how bad it is to interrupt a programmer, because they have so much in working memory that they lose when they transition to another task. But there are ways good IDEs can help mitigate those issues. For example, inline automated error checking is one way to reduce the cognitive load on programmers, because it lets them focus more on what they're trying to accomplish rather than the low level syntax mistakes. In that way, the IDE offloads some of the responsibility from the user to the interface. Now we could phrase that a little bit differently too. We could describe this as distributing the cognitive load more evenly between the different components of the system, myself and the computer. That's a perspective we discuss when we talk about distributed cognition.
279
28094 - Motor System
281So our user has received some input. It's entered her memory, she cognitively processed it. Now it's time to act in the world in response. In designing interfaces, we're also interested in what is physically possible for users to do. This includes things like, how fast they can move, or how precisely they can click or tap on something. For example, here are two versions of the Spotify control widget that appears on Android phones. On the left is the version that's available in the tray of the phone that you can access at any given time by swiping down on the phone screen. And on the right is the version that appears on the lock screen when you turn on a locked phone while it's playing music. In each case, the X closes the app, which is consistent with a lot of other applications. The forward, back and pause buttons are similarly consistent with their usual meanings. I don't actually know what the plus sign here does. It's doesn't have a clear mapping to some underlying function. Now note on the left, we have the close button, in the top right corner. It's far away from anything else in the widget. On the right, the close button is right beside the skip button. I can speak from considerable personal experience, and say that the level of specificity or the level of precision required to tap that X, instead of tapping the skip button, is pretty significant. Especially if you're using this while running or driving, or anything besides just sitting there, interacting directly with your phone. The precision of the user's ability to tap on a button is significantly reduced in those situations. And in this case, that can lead to the quick error of closing the application when all you're trying to do is skip forward to the next song. This isn't an error in the perception of the screen. It's not an error in their memory of the controls. They're not thinking that the X button actually is the skip button. This is just an error in what they're physically able to perform at a given time. The interface relies on more precision than they would have in many circumstances. So this design doesn't take into consideration the motor system of the user or the full context surrounding usage of this application. This isn't as significant in the design on the left, because there's more room around that close button. If I aim for the forward button and miss, the worst that's going to happen is I might pause it. I'm not going to close it by accident. This is one example of how we need to be aware of the constraints on the user's motor system. What they can physically do, how precise or accurate they can be, and so on. And we have to be aware of that in the context where the application is going to be used as well. These buttons are no smaller than the keys on a smart phone keyboard but we expect more specificity when they're sitting there typing with their thumbs, as opposed to reaching over and interacting real quick on something on the lock screen. Now of course, there might be other constraints around this. There might be a reason why this button's placed there. There might be some constraint in the Android system that doesn't let them use more than one row of the lock screen. In that case, we would need to make our interface more tolerant of errors. Maybe require a double tap to close the app, or maybe we mute it when it's pressed and then gives the user five seconds to confirm that that's actually what they want to do. Those are ways of reducing the penalty for errors.
282
28395 - Introduction to Design Principles
284Over the many years of HCI development, experts have come up with a wide variety of principles and heuristics for designing good interfaces. None of these are hard and fast rules like the law of gravity or something. But they're useful guidelines to keep in mind when designing our interfaces. Likely, the most popular and influential of these is Don Norman's six principles of design. Larry Constantine and Lucy Lockwood have a a similar set of principles of user interface design, with some overlaps but also some distinctions. Jacob Nielsen has a set of Ten Heuristics for user interface design that can be used for both design and evaluation. And while those are all interested in general usability, there also exists a set of seven principles called Principles of Universal Design. These are similarly concerned with usability, but more specifically for the greatest number of people. Putting these four sets together, we'll talk about 15 unique principles for interaction design.
285
28696 - Discoverability
287Our first principle is discoverability. Don Norman describes it by asking, is it possible to even figure out what actions are possible and where and how to perform them? Nielsen has a similar principle. He advises us to minimize the user's memory load by making objects, actions, and options visible. Instructions for use of the system should be visible or easily retrievable whenever appropriate. In other words, when the user doesn't know what to do, they should be able to easily figure out what to do. Constantine and Lockwood have a similar principle called the visibility principle. The design should make all needed options and materials for a given task visible without distracting the user with extraneous or redundant information. The idea behind all three of these principles is that relevant function should be made visible, so the user can discover them as opposed to having to read about them in some documentation or learn them through some tutorial. Let's take an example of this real quick. Here in PowerPoint, there are a number of different menus available at the top, as well as some toolbars. The effect here is that I can browse the different functions available to me. I can discover what's there. For Nielsen, this means that I don't have to remember all of these. I just have to recognize them when I see them in the tool bars. For example, I don't have to remember Arrange as some keyboard I have to type in manually to bring up some ideas about how I might arrange things. All I have to do is recognize Arrange as the right button when I see it. Now while this might be true at the application level, it's not often true at the operating system level, because the operating system doesn't command so much screen real estate all the time and probably for good reason. So for example, on a Mac, I can use Command Shift 4 to take a screen shot only of a certain area of my screen. However, the only way I know of to find that is to Google it or read it in a manual. It isn't discoverable or visible on it's own. And you might never even realize it's possible. So the principle of discoverability advocates that functions be visible to the user, so that they can discover them, rather then relying on them learning them elsewhere. I actually use a PC more than a Mac. And whenever I come back to my Mac after not using it for awhile, I have to Google that again. I know it's possible, but I never remember the command that actually makes it happen. Constantine and Lockwood's principle of visibility would add on to this that we shouldn't get too crazy. We want to make functions discoverable, but that doesn't mean just throwing everything on the screen. We want to walk a line between discoverability, and simplicity
288
28997 - Design Challenge: Discovering Gestures
290Discoverability is one of the challenges for designing gesture-based interfaces. To understand this, let's watch Morgan do some ordinary actions with her phone. We just saw Morgan do four things with the phone. Reject a call, take a screenshot, take a selfie, and make a phone call. For each of those, this phone actually has a corresponding gesture that would have made it easier. She could have just turned the phone over to reject the call or said, shoot, to take the selfie. The problem is that these are not discoverable. Having a menu of voice commands kind of defeats the purpose of saving screen real estate and simplicity through gestures and voice commands. So, brainstorm a bit. How would you make these gesture commands more discoverable?
291
29298 - Design Challenge: Discovering Gestures Solution
293There's a lot of ways we might do this, from giving her a tutorial in advance, to giving her some tutoring in context. For example, we might use the title bar of the phone to just briefly flash a message letting the user know when something they've done could have been triggered by a gesture or a voice command. That way, we're delivering instruction in the context of the activity. We could also give a log of those so that they can check back at their convenience and see the tasks they could have performed in other ways.
294
29599 - Simplicity
296There often exists a tension between discoverability and simplicity. On the one hand, discoverability means you need to be able to find things. But how can you find them if they're not accessible or visible? That's how you get interfaces like this with way too many things visible. And ironically as a result, it actually becomes harder to find what you're looking for because there's so many different things you have to look at. This is where the principle of simplicity comes in. Simplicity is part of three of our sets of principles, Nielsen's, Constantine and Lockwood's, and the universal design principles. Nielsen writes specifically about dialogues. He says that the dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information competes with the relevant units of information, and diminishes their relative visibility, which we see with all those toolbars Constantine and Lockwood establishes as their simplicity principle. They say the design should make simple common tasks easy. Communicating clearly and simply in the user's own language and providing good shortcuts. Universal design is concerned with simplicity as well. Their principle of simple and intuitive use advocates the use of design easy to understand regardless of the user's experience, knowledge, language skills, or current concentration level. And in this principle you can see universal design's special concern with appealing to users of a variety of different levels of expertise, ages, disabilities, and so on. Now in some ways, these principles are about designing interfaces but they cover other elements as well. One example of this is the infamous blue screen of death from the Windows operating systems. On the left we have the blue screen of death as it appeared in older versions of Windows. And on the right we have how it appears now on Windows 10. There are a lot of changes here. The blue is softer and more appealing. The description of the error is in plain language. But the same information is still provided, it's just de-emphasized. This is a nice application of Nielsen's heuristic. The user should only be given as much information as they need. Here, the information that most users would need, which is just that a problem occurred and here's how close I am to recovering from it, are presented more prominently than the detailed information that might only be useful to an expert. Another interesting application of simplicity in action came when New York tried to create simpler signs to represent its allowed parking schedule. Navigating the sign on the left is pretty much impossible. But it's pretty easy to interpret the one on the right. The universal design principle of simplicity is particularly interested in whether or not people of different experiences, levels of knowledge, or languages can figure out what to do. Navigating this sign requires a lot of cognitive attention and some language skills. Whereas I would hypothesize that even someone who struggles with English might be able to make sense oft the sign on the right. These two signs communicate the same information, but while the one on the left requires a lot of cognitive load and language skills, the one on the right can probably be understood with little effort and little experience.
297
298100 - Mapping
299Norman and Nielsen both talk about the need for a mapping between interfaces and their effects in the world. Norman notes that mapping is actually a technical term coming from mathematics that means a relationship between the elements of two sets of things. In this case, our two sets are the interface and the world. For example, these book icons might help you map these quotes to the books from which they were taken. Nielsen describes mapping by saying the system should speak the users' language, with words, phrases, and concepts that are familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. A great example of this, is the fact that we call cut, copy, and paste, cut, copy and paste. Surely there could have been more technical terms like duplicate instead of copy. But using cut, copy, and paste forms a natural mapping between our own vocabulary and what happens in the system. Note that these two principles are subtly different, but they're actually strongly related. Nielsen's heuristic describes the general goal, while Norman's principle describes one way to achieve it. Strong mappings help make information appear in natural and logical order. A great example of this is setting the arrangement of different monitors. This actually comes from my display in my home office. This visualization creates a very natural mapping between the way the system treats the monitors, and they way they're actually laid out in the world. If there's a mismatch, or if something doesn't make sense, I can easily look at this and map it with the arrangement of the monitors in front of me and figure out what's going on. This could instead be shown as just a list of pixel locations. And that would still present all the exact same information, but in a way that isn't as easily mapped out to the real world. Now, mappings and affordances are similar principles, but they have a clear and important difference. We can see that difference in our color meter again. Affordances were about creating interfaces where their designs suggested how they're supposed to be used. The placement of this notch along this horizontal bar, kind of affords the idea that it could be dragged around. The horizontal bar visualizes the space which makes it seem like we could move that notch around to set our color. However, that design on its own wouldn't necessarily create a good mapping. Imagine, if instead of the bar fading from white to black, it was just white the entire way. It would still be very obvious how you're supposed to use it. But it wouldn't be obvious what the effect of using it would actually be. It's the present of that fade from white to black that makes it easier to see what will happen if I actually drag that around. I can imagine it's going to make the colors fade from white to black. That creates the mapping to the effect of dragging it around on that meter. So mapping refers to creating interfaces where the design makes it clear what the effect will be when using them, not just creating interfaces where it's clear how you're supposed to use them. With this color meter, the arrangement of the controls makes clear what to do and the visualization underneath, makes it clear what will happen when I do it.
300
301101 - Design Challenge: Mapping and Switches
302A good example of the difference between affordances and mappings is a light switch. A light switch very clearly affords how you're supposed to use it. You're supposed to flip it. But these switches have no mapping to what will happen when I switch them. I can look at it and clearly see what I'm supposed to do. But I can't tell what the effect is going to be in the real world. Contrast with the dials on my stove. There are four dials and each is augmented with this little icon that tells you which burner is controlled by that dial. So there's a mapping between the controls and the effects. So how would you redesign these light switches to create not only affordances but also mappings. If relevant, this one turns on the breakfast room light, this one turns on the counter light and this one turns on the kitchen light.
303
304102 - Design Challenge: Mapping and Switches Solution
305There are a few things we could do actually. Maybe we could put a small letter next to each light switch that indicates which light in the room that switch controls. K for kitchen, C for counter top, B for breakfast room. Maybe we actually put icons that demonstrates which kind of light is controlled by each switch. So the counter top lights are kind of sconce lights, so maybe we put an icon that looks like the counter top lights. But likely the easiest thing is actually the way the system really was designed. I just didn't notice it until I started writing this video. The lights from left to right in the room are actually controlled by the light switches from left to right on the wall. This switch controls the light over there. This switch controls the light right here. And this switch controls the light back there. That actually forms a pretty intuitive mapping.
306
307103 - Perceptibility
308Our next principle is perceptibility. Perceptibility refers to the user's ability to perceive the state of the system. Nielsen states that the system should always keep users informed about what is going on, through appropriate feedback within reasonable time. That allows the user to perceive what's going on inside the system. Universal design notes that the design should communicate necessary information effectively to the user, regardless of ambient conditions or the user's sensory abilities. In other words, everyone using the interface should be able to perceive the current state. Note that this is also similar to Norman's notion of feedback. He writes that feedback must be immediate, must be informative, and that poor feedback can be worse than no feedback at all. But feedback is so ubiquitous, so general, that really, feedback could be applied to any principle we talk about in this entire lesson. So instead we're going to reserve this more narrow definition for when we talk about errors. And our lesson on feedback cycles covers the idea of feedback more generally. Things like light switches and oven dials, actually do this very nicely. I can look at a light switch and determine whether the system it controls is on or off, based on whether the switch is up or down. Same with the oven dial. I can immediately see where the dial is set. But there's a common household control, that flagrantly violates this principle of perceptibility. Here's our ceiling fan, you might have one just like it. It has two chains. One controls the light, one controls the fan speed. But both only when the switch on the wall is on. Now first, the mapping here is awful. There's no indication which control is which. But worse, the fan chain, which is this one, doesn't give any indication of which setting the fan is on currently. I don't honestly even know how many settings it has. I don't know if pulling it makes it go up and then down, up and then off, down and then off. Whenever I use it, I just pull it, wait ten seconds and see if I like the speed, and then pull it again. And this is all only if the wall switch is on. Now, of course people have resolved this with dials or other controls, and yet these dang chains still seem to be the most common approach despite this challenge of perceptibility.
309
310104 - Equity
311The principle of flexibility in some ways appears to clash with the principle of equity. But both come from the principles of universal design. The principle of flexibility said the design should accommodate a wide range of individual preferences and abilities. But the principle of equity says the design is useful and marketable to people with diverse abilities, and it goes on to say we should provide the same means for all users, identical whenever possible and equivalent when not. And we should avoid segregating or stigmatizing any users. Now, in some ways, these systems might compete. This says we should allow every user to use the system the same way, whereas this one says that we should allow different, flexible methods of interacting with the system. In reality, though, these are actually complementary of one another. Equity is largely about helping all users have the same user experience, while flexibility might be a means to achieve that. For example, if we want all our users to enjoy using our interface, keeping things discoverable for novice users and efficient for expert users allows us to accommodate a wide range of individual preferences and abilities. User experience in this instance means treating every user like they're within the target audience and extending the same benefits to all users, including things like privacy and security. We might do that in different ways, but the important note is that the experience is the same across all users. That's what equity is about. One good example of equity in action are the requirements for password resets. We want to design a system so that both expert and novice users experience the same level of security. Security is part of the user experience. Now, experts, we would assume, understand the value of a complex password. Novices might not. So if we don't have requirements around passwords, novices might not experience the same level of security as experts. So password requirements can be seen as a way of making sure the user experience across novices and experts is the same with regard to security. In the process, we might actually frustrate novice users a little bit. You could actually see this as a violation of the flexibility principle, that we're not flexibly accommodating in the kind of interaction that novices want to have. But the important thing, is we're extending the same security benefits to everyone, and that's equitable treatment. And that's also a good example of how at times, the different design principles will appear to compete, and you have to decide what the best approach is going forward.
312
313105 - Ease and Comfort
314Ease and comfort are two similar ideas that come from the principles of universal design. And they also relate to equitable treatment, specifically in terms of physical interaction. The ease principle, which interestingly uses the word comfort, says the design can be used efficiently and comfortably and with a minimum amount of fatigue. The comfort principle notes that appropriate size and space is provided for approach, reach, manipulation and use regardless of the user's body size, posture or mobility. Now, in the past, these principles didn't have an enormous amount of application to HCI. Because we generally assume that the user was sitting at their desk with a keyboard and a monitor. But as more and more interfaces are becoming equipped with computers, we'll find HCI dealing with these issues more and more. For example, the seat control in your car might now actually be run be a computer that remembers your settings and restores them when you get back in the car. That's an instance of HCI trying to improve user ease and comfort in a physical area. Mobile interfaces are great examples of this as well. When deciding the size of buttons on a mobile interface, we should take into consideration that some users might have tremors that make it more difficult to interact precisely with different buttons. As we get into areas like wearable computing and virtual reality, these issues of ease and comfort are going to become more and more pertinent.
315
316106 - Norman's Four Types of Constraints
317Norman takes us a step further though, when he breaks down constraints into four sub-categories. These aren't just about preventing wrong input. They're also about insuring correct input. They're about making sure the user knows what to do next. Physical constraints are those that are literally physically prevent you from performing the wrong action. A three-prong plug, for example, can only physically be inserted in one way, which prevents mistakes. USB sticks can only be physically inserted one way all the way. But the constraint doesn't arise until you've already tried to do it incorrectly. You can look at a wall outlet and understand if you're trying to put it incorrectly. But it's harder to look at a USB and know whether you're trying to insert it the right way. A second kind is a cultural constraint. These are those rules that are generally followed by different societies, like facing forward on escalators, or forming a line while waiting. In designing we might rely on these, but we should be careful of intercultural differences. A third kind of constraint is a semantic constraint. Those are constraints that are inherent to the meaning of a situation. They're similar to affordances in that regard. For example, the purpose of a rear view mirror is to see behind you. So therefore, the mirror must reflect from behind, it's inherent to the idea of a rear view mirror, that it should reflect in a certain way. In the future that meaning might change, autonomous vehicles might not need mirrors for passengers, so the semantic constraints of today, might be gone tomorrow. And finally the fourth kind of constraint is a logical constraint. Logical constraints are things that are self-evident based on a situation, not just based on the design of something like a semantic constraint, but based on the situation at hand. For example, imagine building some furniture. When you reach the end, there's only one hole left, and only one screw. Logically, the one screw left is constrained to go in the one remaining hole. That's a logical constraint.
318
319107 - Reflections: Constraints
320A lot of the principles we talk about are cases where you might never even notice if they've been done well. There are principles of invisible design, where succeeding allows the user to focus on the underlying tasks. But constraints are different. Constraints actively stand in the user's way and that means they've become more visible. That's often a bad thing, but in the case of constraints it serves the greater good. Constraints might prevent users from entering invalid input or force users to adopt certain safeguards. So of all the principles we've discussed, this might be the one you've noticed. So take a second, and think. Can you think of any times you've encountered interfaces that had constraints in them?
321
322108 - Reflections: Constraints Solution
323I have kind of an interesting example of this. I can't demonstrate it well because the car has to be in motion, but on my Leaf there's an option screen, and it lets you change the time and the date, and some other options on the car. And you can use that option screen until the car starts moving. But at that point, the menu blocks you from using it, saying you can only use it when the car is at rest. That's for safety reasons. They don't want people fiddling with the option screen while driving. What makes it interesting, though, is it's a constraint that isn't in the service of usability, it's in the service of safety. The car is made less usable to make it more safe.
324
325109 - Feedback
326Second, the system should give plenty of feedback so that the user can understand why the error happened and how to avoid it in the future. Norman writes that feedback must be immediate and it must be informative. Poor feedback can be worse than no feedback at all. Because it's distracting, uninformative, and, in many cases, irritating and anxiety-provoking. If anything has ever described the classic Windows Blue Screen of Death, it's this. It's terrifying. It's bold. It's cryptic. And it scares you more than it informs you. Nielsen writes that error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Note this tight relationship with recoverability. Not only should it be possible to recover from an error, the system should tell you exactly how to recover from an error. That's feedback in response to errors. For Constantine and Lockwood, this is the feedback principle. The design should keep users informed of actions or interpretations, changes of state or condition, and errors or exceptions... through clear, concise, and unambiguous language familiar to users. Again, the old Windows blue screen of death doesn't do this very well. Because the language is not familiar, it's not concise, and it doesn't actually tell you what the state or condition is. The new one does a much better job of this. Notice as well that Norman, Constantine, and Lockwood are interested in feedback more generally, not just in response to errors. That's so fundamental that we have an entire lesson on feedback cycles that really is more emblematic of the overall principle of feedback. Here we're most interested in feedback in response to errors, which is a very important concept on its own
327
328110 - Documentation
329Finally, Nielsen has one last heuristic regarding user error, documentation. I put this last for a reason, one goal of usable design is to avoid the need for documentation altogether. We want users to just interact naturally with our interfaces. In modern design, we probably can't rely on users reading our documentation at all unless they're being required to use our interface altogether. And Nielsen generally agrees. He writes that even though it's better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on user's task, list concrete steps to be carried out, and not be too large. I feel modern design as a whole has made great strides in this direction over the past several years. Nowadays, most often, when you use documentation online or wherever you might find it, it's framed in terms of tasks. You input what you want to do, and it gives you a concrete list of steps to actually carry it out. That's a refreshing change compared to older documentation, which was more dedicated to just listing out everything a given interface could do without any consideration to what you were actually trying to do.
330
331111 - Introduction
332Today we're going to talk about mental models and representations. A mental model is the understanding you hold in your head about the world around you. Simulating a mental model allows you to make predictions and figure out how to achieve your goals out in the real world. A good interface will give the user a good mental model of the system that it presents. In order to develop good medal models we need to give users good representations of the system with which they're interacting. In that way, we can help users learn how to use our interfaces as quickly as possible. So that's what we'll talk about in this lesson, creating representations that help users develop accurate mental models of our systems. We'll start by talking about mental models in general and how they apply to the interfaces with which we're familiar. Then we'll talk about how representations can make problem solving easier or harder. After that, we'll talk about how metaphors and analogies can be useful tools to create good representations that lead to accurate mental models. Then we'll discuss how user error can arise either from inaccuracies or mistakes in the user's mental model, or just from accidental slips, despite an accurate mental model. Finally, we'll close by discussing learned helplessness, one of the repercussions of poor interface design, as well as expert blindspot, which is one of the reasons why poor design can occur.
333
334112 - Mental Models
335A mental model is a person's understanding of the way something in the real world works. It's an understanding of the processes, relationships and connections in real systems. Using mental models we generate expectations or predictions about the world and then we check whether the actual outcomes match our mental model. So I'm holding this basketball because generally, we all probably have a model of what will happen if I try to bounce this ball. You didn't have to see it come up to know what would happen. You use your mental model of the world to simulate the event. And then you use that mental simulation to make predictions. When reality doesn't match with our mental model, it makes us uncomfortable. We want to know why our mental model was wrong. Maybe it makes us curious. But when it happens over and over, it can frustrate us. It can make us feel that we just don't and never will understand. As interface designers, this presents us with a lot of challenges. We want to make sure that the users mental model in our systems matches the way our systems actually work. We can do that in two primary ways, one by designing systems that act the way people already expect them to act. And two, by designing systems that, by their very nature, teach people how they'll act. That way we can minimize the discomfort that comes from systems acting ways that users don't expect.
336
337113 - Mental Models and Education
338Mental models are not a uniquely HCI principle. In fact, if you search for mental models online, you'll probably find just as much about them in the context of education, as the context of HCI. And that's actually a very useful analogy to keep in mind. When you're designing an interfce you're playing, very much, the role of an educator. Your goal is to teach your user how the system works through the design of your interface. But unlike a teacher, you don't generally have the benefit of being able to stand here and explain things directly to your user. Most users don't watch tutorials or read documentation or if they do, they don't want to. You have to design interfaces that teach users while they're using them. That's where representations come in. Good representations show the user exactly how the system actually works. It's an enormous challenge, but it's also incredibly satisfying when you do it well.
339
340114 - Mental Models in Action
341So let's talk a little bit about mental models in the context of the climate control systems we see on automobiles. So this is my old car, it's a 1989 Volvo. It, sadly, does not run anymore. But let's talk about how the climate control system would work back when it did run. So, it's a hot day outside. Looking at these controls, how would you make the air temperature colder and the air come out faster? The natural thought to me would be to turn the fan speed up over on the right, and the air temperature to the blue side over on the left. But this doesn't actually make the temperature any colder, it just disables the heat. This dial over here in the top right, has to be turned on to make the air conditioning actually work. So just turning this thing over to the blue side doesn't actually turn on the air conditioning. So to make it colder, you have to both slide this lever over to the left, and turn this dial to the red area. It's kind of hard to see in this, but this little area over here on the left side of this dial is actually red. The red area on the air conditioning control designates the maximum coldness. What? This also means you can turn on both the heat and the air conditioning at the same time and have neither of them blowing out if your fan is turned off. None of these really match my mental model of how this system works and the colors used here do nothing to correct my mental model. There's a control here that if you turn it to blue doesn't make the car any colder. And if you turn this other control to red, it does make the car colder. What? So back in 1989, there was a lot of room for improvement on designing the climate control system for a car like this. Let's see if we actually did improve that by talking about my new car, which is a 2015 Nissan Leaf. So in the 26 years since my old Volvo came out, have we gotten better at this? Well yeah, we've gotten a good bit better, although there's still a good bit of room for improvement. So, here's the climate control system from my Leaf. I have one dial, that turns the fan speed up and down. One dial that turns the temperature of the air coming out up and down. And so as far as that's concerned, it's pretty simple. But this interface still has some things that are pretty confusing. So for example, it has an automatic mode, where it tries to adjust the air temperature and the fan speed to bring the temperature of the car to the temperature that I want. So I press auto. Now it's going to change the fan speed, and change the air temperature, if I didn't already have it at the lowest, to try and get the car cooler faster. The problem is that I want to turn auto off, I don't actually know how to do it. Pressing auto doesn't actually turn it off. If I turn it so that it doesn't only circulate air inside the car, then it turns auto off. But that might not be what I wanted. Maybe I wanted it to go to a certain air temperature without just circulating the air in the car. I turn auto back on, it's going to turn that back on. Don't know why. So right now, as far as I know, the only way to turn auto off is to turn the circulation mode off. It also lets me turn AC and heat on at the same time, which I don't understand at all. Why would I ever need that? So there are some things that the system really should do better, or some things that it should constrain so the user doesn't do things that don't make sense in the context of wanting to set the temperature.
342
343115 - Representations
344The most powerful tool in our arsenal to help ensure users have effective mental models of our systems is representation. We get to choose how things are visualized to users, and so we get to choose some of how their mental model develops. Using good representations can make all the difference between effective and ineffective mental models. So to take an example, let's look at some instructions for assembling things. So here are the instructions for a cat tree that I recently put together. At first, I actually thought this was a pretty good representation. You can kind of see how things fit together from the bottom to the top. The problem is that this representation doesn't actually map the physical construction of the cat tree itself. You can even see some bizarre mismatches even within this representation. Up here, it looks like this pillar is in the front, but the screw hole that goes into it is actually shown in the back. But we're not looking up into the bottom of that piece, because in the middle piece, they actually map up pretty well. At least with the way they're shown here. Again, that isn't the way the actual piece works. So anyway, the point is, this is a poor representation for the way this furniture actually worked, because it wasn't a real mapping between this representation and the real pieces. Lately I also put together some office furniture, and that actually had a very good representation. These are two of the steps from a hutch I put together to go over my desk. For the piece on the left, there was a perfect mapping between the way this piece worked and the way the screw holes were actually aligned on the piece. One clever thing they did is they actually showed this little screw hole right here that isn't used for this step. That helped me understand the mapping between this piece and my piece. And understand that when I saw that screw hole that didn't have a screw for it, that was okay. It would be natural to think we only need to show what users actually need to do. But including that screw hole helps users understand the mapping between this representation and the actual piece. This more complicated step over on the right actually ended up being pretty intuitive as well. Although it's small and the details hard to see, the arrows they put along here made it pretty easy to see the direction you had to move things in order to put these pieces together. That's especially useful in places like up here, where the screw hole actually isn't visible in this diagram. But I can see that there is a screw hole here because of the way they represented this screw going into that hole. I can look at the arrangement of these pieces and get a good feel for how the pieces are meant to fit together. So this representation helps me understand the problem in a way that the other representation did not.
345
346116 - Representations for Problem Solving 1
347A good representation for our problem will make the solution self-evident. Let's take a classic example of this. A hiker starts climbing a mountain at 7 AM. He arrives at the cabin on top at 7 PM. The next day, he leaves the cabin at 7 AM and arrives at the bottom at 7 PM. The question, was the hiker ever at the same point at the same time on both days?
348
349117 - Representations for Problem Solving 1 Solution
350Let's watch that animation again. The hiker goes up the hill on one day, stays the night. And then goes back down the hill the next day. And we want to know, was the hiker ever at the same point at the same time on both days? And the answer is yes. Describe the way we describe it right here, it might actually seem odd that there is a point where the hiker is in the same place at the same time on both days. That seems like a strange coincidence, but what if we tweak the representation a little bit? Instead of one hiker going up and then coming down the next day. Let's visualize the two days at the same time. If we represent the problem like this, we'll quickly see the hiker has to pass himself. To show it again, we know the answer is yes, because there's a time when the hiker would have passed himself if he was going in both directions on the same day. And to pass himself, he has to be in the same point at the same time. That representation took a hard problem and made it very easy.
351
352118 - Representations for Problem Solving 2
353For simple problems, identifying a good representation can be easy. But what about for more complex problems? For those problems, we might need some examples of what makes a good representation. So let's try a complex example. We'll use a problem with which you might be familiar. For now, I'll call it the circles and squares problem. On one side of a table, I have three circles and three squares. My goal is to move the three circles and three squares to the other side of the table. I can only move two shapes at at time, and the direction of the moves must alternate, starting with a move to the right. The number of squares on either side can never outnumber the number of circles unless there are no circles at all on that side. How many moves does it take to accomplish this? Try it out and enter the number of moves it takes in the box. Or just skip if you give up.
354
355119 - Representations for Problem Solving 2 Solution
356If you solved it, well done on figuring it out despite such a terrible representation. Or congratulations on recognizing by analogy, that it's the same as a problem you've seen in another class. If you skipped it, I don't blame you. It's not an easy problem. But it's even harder when the representation is so poor. There were lots of weaknesses in that representation. Let's step through how we would improve it. The first thing we could do is simply write the problem out. Audio is a poor representation of complex problems. So here's a written representation of the problem. If the trouble you were having solving the exercise was just remembering all the rules, having this written down would be a huge help. But we can still do a lot better than this. Instead, we can represent the problem visually. Here we have the shapes, the three circles and the three squares. And we can imagine actually moving them back and forth. That arrow in the center, represents the direction of the next move. But we can still do better. Right now we have to work to compare the number of squares and circles, so let's line them up. This makes it very easy to compare and make sure that the circles always outnumber the squares. And we can still do the same manipulation, moving them back and forth. Now the only remaining problem is that we have to keep in working memory, the rule that squares may not outnumber circles. There is no natural reason why need more squares than circles, it's just kind of an arbitrary rule. So let's make it more self evident. Let's make the squares wolves, and the circles sheep. As long as the sheep outnumber the wolves, the sheep can defend themselves, kind of. But if the wolves ever outnumber the sheep, they'll eat them. But if there are no sheep, then there's nothing for the wolves to eat, so that's okay. So now we have a new representation of the problem, one that will make the problem much easier to solve. The rules are more obvious, and it's easier to evaluate whether or not they're being met. Finally, we can make this visualization even a little bit more useful, by actually showing the movements between different states. That way we can see that for any state in the problem, there's a finite number of next legal states. This would also allow us to notice when we've accidentally revisited an earlier state, so we can avoid going around in circles. So for example, from this state, we might choose to move the wolf and the sheep back to the left, but we'll immediately notice that would make the state the same as this one. And it's not useful to backtrack and revisit an earlier state. So we know not to do that. So these representations have made it much easier to solve this problem, than just the verbal representation we started with.
357
358120 - Characteristics of Good Representations
359What are the characteristics of a good representation? First, good representations make relationships explicit. Laying things out like this makes it easy to tell that there are more sheep than wolves. Second, good representations bring objects and relationships together. Representing these as wolves and sheep, makes that relationship that the sheep must out number the wolves much more salient than using squares and circles. That brings the objects together with the relationships between them. Third, a good representation excludes extraneous details. For example, sometimes this problem is described in the form of having a river and a boat. But those details aren't actually relevant to solving the problem at all. So, we've left them out of here. All we need to know is they need to move from the left to the right. Doesn't matter if it's a river, doesn't matter if it's a boat, this is all the information that we need. So we left out the extraneous information. Fourth, good representations expose natural constraints. We describe these as sheep and wolves because it makes it easier to think about the rule that wolves may never out number sheep. Now of course, this isn't the best rule because we know that sheep can't actually defend themselves against wolves. Three sheep and one wolf, the wolf would still win. However, if we visualize these as guards and prisoners instead, it involves holding and working memory the idea that prisoners inexplicably won't flee if they're left without any guards. So personally, I think the wolves and sheep metaphor is better. But perhaps the original name of the problem is even better. This was originally described as the cannibals and missionaries problem. It makes more sense that a missionary could defend themselves against a cannibal than a sheep could defend themselves against a wolf. But the cannibals and missionaries problem makes it a little bit dark. So let's stick with sheep and wolves.
360
361121 - Design Challenge: Representations
362So let's take an example of redesigning a representation to create a better mapping with a task. Here we have my circuit breaker. On the left we have a list of breakers, on the right we have what they actually control. To reset a breaker I need to go down the list on the left, find the one I want, count down on the right to find the right breaker, and switch it. How can we make this representation of what each breaker corresponds to better?
363
364122 - Design Challenge: Representations Solution
365There are a number of things we can do here. The simplest change we could make would simply be to make the breakers themselves writable. Instead of writing a list on the left that we have to then map up to the breakers themselves on the right, we could just write on each breaker what it controls. That way we just have to look at the breakers themselves to find the breaker that we're interested in. But then they still have to manually scan through all of them. We could further augment this by having a floor plan over here that actually gives the numbers on the floor plan for the breaker we want. So all I have to do is jump straight to the room that I'm interested in, find the number, go over the the list of breakers, and the label written on it would then confirm that I chose the right one. Now, if we wanted to get really crazy we could actually lay out the breakers themselves to correspond to the floor plan. We can have a floor plan and actually put the breakers on the floors that they control. Or we could even just put the breakers in the rooms themselves. So if the power goes out to a certain room, I just go find the breaker in that room. But there we're starting to run into some of the other constraints on the problems. So it's probably best to stick to what we can control, without requiring that the physical device be manufactured differently in the first place.
366
367123 - Representations in Interfaces
368Representations are all around us in the real world, but they play a huge role in interfaces. Designing representations of the current state of a system is actually one of the most common tasks you might perform as an interface designer. So let's take a look at a few, here's Google Calendar which is a representation of my week. Notice how it actually uses space to represent blocks of time. It allows me to quickly feel how long different things are going to take. An alternate visualization might show an entire month instead of a week, but it would lose those indicators that linked the individual appointments. So it doesn't really represent the structure and pace of my day, the way the weekly calendar does. This representation also allows me to very easily find conflicts in my schedule. So I know when I might need to reschedule something. On Friday I can see that I have a conflict for one of my meetings. And this interface also makes it easy to reschedule. I can pull up the calendar for the other person I'm meeting with and identify places where we both have free in our schedule. Another example of this is the PowerPoint animation pang. The numbers here represent when different animations happen concurrently. The middle icon represents what triggers the animation, and the right icon indicates the general nature of the animation. Whether it's a movement, a highlight or an appearance. The PC version of PowerPoint makes this even better by actually showing you a timeline of the different animations to the right. That lets you very easily visualize when two different things are going to happen at the same time. Or when something waits for something else to happen. These are just two of the many many representations you use whenever you use a computer. Scroll bars for example, are representations of your relative position in a document. Highlighting markers like that rectangle are representations of what you currently have selected. All these representations work together to help your mental model match the real state of the system. Representations when used correctly can make many tasks trivial, or even invisible. And we as interface designers have a lot of control over representations in our designs.
369
370124 - Design Principles Revisited
371In our lesson on design principles, we touch on a number of principles that are relevant to these ideas of mental models, representations, and metaphors. First, the idea that people reason by analogy to pass interfaces, or by metaphors to the real world, is one of the reasons that the principle of consistency is so important. We want to be consistent with the analogies and metaphors that people use to make sense of our interfaces. Second, when we say that an interface should teach the user how the system works, we're echoing the idea of affordances. The way the system looks, should tell the user how it's used. Just by observing the system the, user should be learning how to interact with it. Third, representations are important because they map the interphase, to the task at hand. A good representation is one that users can use predict the outcomes of certain actions. In other words, a good representation let's users predict the mapping between their actions in the interphase, and the outcomes out in the world.
372
373125 - New Functionality Meets Old Interfaces
374In designing interfaces, we want to leverage analogies to the real world, and principles from past interfaces whenever possible, to help the user learn the new interface as quickly as they can. But there's a challenge here. Why are we designing technology if we're not providing users anything new? It's one thing to take the technology they're already using, and make it more usable. But generally, we also want to enable people to do things they've never done before. That means there are no analogies, no expectations, no prior experiences for them leverage. How do you tell someone that's used to control their own thermostat that they don't need to anymore. So, while we need to leverage analogy and prior experience wherever possible. We also need to be aware that eventually, we're going to do something interesting, and they're going to break down. Eventually, we're going to have to teach the user to use the unique elements of our interface.
375
376126 - Types of Slips
377Don Norman further divides slips into two different categories. He describes action-based slips and memory lapse slips. Action-based slips are places where the user performs the wrong action, or performs a right action on the wrong object, even though they knew the correct action. They might click the wrong button, or right-click when they should left-click. A memory lapse slip occurs when the user forgets something they knew to do. For example, they might forget to start a timer on a microwave. They knew what to do, they just forgot about it. So action-based slips are doing the wrong thing, and memory lapse slips are forgetting to do the right thing. In this dialog, clicking No when you mean to click Yes would be an example of an action-based slip. The very existence of this dialog is meant to prevent a memory lapse slip, where a user would forget to save their work before closing.
378
379127 - Types of Mistakes
380Norman also divides mistakes in the multiple categories, in this case, three categories. Rule based mistakes, knowledge base mistakes and memory lapse mistakes. Rule based mistakes occur where the user correctly assesses the state of the world but makes the wrong decision based on it. Knowledge based mistakes occur where the user incorrectly assesses the state of the world in the first place. Memory lapse mistakes are similar to memory lapse slips, but this focuses on forgetting to fully execute a plan not just forgetting to do something in the first place. If the user clicks the wrong button in this dialog, it could be do to multiple different kinds of mistakes. Maybe they correctly knew they wanted to save their changes but they didn't realize that clicking no is actually what would save, that would be a rule-based mistake. They knew they wanted to save, but they made the wrong decision based on that knowledge. Or perhaps they didn't even realize they wanted to save in the first place. Maybe they didn't think they made any changes, when in actuality they did. That would be a knowledge based mistake. They applied the right rule based on their knowledge but their knowledge was inaccurate. If they were to shut down their computer and never come back and answer this dialogue in the first place, that might be considered a memory lapse mistake. They didn't fully execute the plan of closing down the application. So in our designs, we want to do everything we can to prevent all these different kinds of errors. We want to help prevent routine errors by leveraging consistent practices like designing dialogues the way users are used to. We also want to let our interface off load some of the demands on working memory from the user to the computer to avoid memory lapse errors. And we want the leverage good representations to help users develop the right mental of models to minimize these rule-based and knowledge-based errors. And while errors are inevitable, we should make sure to leverage the tolerance principle to make sure the repercussions can never be too bad.
381
382128 - Exercise: Slips vs. Mistakes
383When you're looking to improve an interface, user errors are powerful places to start. They're indicative either of weaknesses in the user's mental model or places where the system isn't capturing the user's correct mental model. So let's try to address an error Morgan's encountering. Morgan usually texts with her boyfriend but she texts with some other people too. But she finds she's often sending the wrong messages to the wrong people. The app by default brings up the last open conversation and usually that's her boyfriend. But sometimes it's someone else and she accidentally messages them instead. First, is this a slip or is this a mistake?
384
385129 - Exercise: Slips vs. Mistakes Solution
386I would argue this is a slip. Morgan knows who she means to message but the phone's behavior tricks her into sending things to the wrong people. What's more, this might be either an action based slip or memory lapse slip. Maybe Morgan is tapping the wrong person, or maybe she's forgetting to check who she's messaging. So take a second and brainstorm a design for this that can prevent this from happening in the future without over complicating the interaction too much. I would argue that the best way to do this is simply to show more pervasive reminders of who Morgan is currently texting. We could show the recipient's picture on the send button, for example. That way, the interaction is no more complex, but Morgan also has to directly acknowledge who she's messaging to send a message.
387
388130 - Learned Helplessness and Education
389Just like mental models, learned helplessness is also a topic related as much to education as it is to HCI. If you've ever spent any time in a teaching role, you very likely encountered students that are very resistant to being taught. And the reason is they have learned that no matter what they do, they never succeed. They've learned to be helpless based on their past experiences. In all likelihood, there have actually been situations where you've been the one learning that you're helpless. In fact, if you're a parent, I can almost guarantee you've been in that situation. There are times when your child was crying and inconsolable and you had no clue why. We had one of those right before we filmed this video. Nothing you did helped. And you learned that you were helpless to figure out what your child wanted. So if you're a parent and you're dealing with learned helplessness as an interface designer, just imagine that you are the user and the interface is your screaming child. What feedback would you need from your child to figure out how you can help them? And how can you build that kind of feedback into your interface?
390
391131 - Expert Blind Spot
392Generally, when we're developing interfaces, we're going to be experts in those domains. It's rare that you design an interface to help people do something that you yourself don't know how to do. But as a result, there's risk for something called expert blind spot. When you're an expert in something, there are parts of the task that you do subconsciously without even really thinking about them. For example, a professional basketball player knows exactly where to place their hands on the ball when taking a shot. I know exactly what to do when I walk in the studio. Amanda knows exactly what to do when she gets behind the camera. And yet, if we were suddenly asked to train someone else, there are lots of things we'd forget to say or lots of things we would assume would just be obvious. That's exactly what you're doing when you're designing an interface. You're teaching the user how to use what you've designed. You're teaching them without the benefit of actually talking to them, explaining things to them, or demonstrating things for them. You're teaching them through the design of the interface. So, you have to make sure that you don't assume that they're an expert too. You have to overcome that expert blind spot because we are not our users. We are not the user. That can be the motto of all of HCI. I am not my user. Say it with me, I am not my user. One more time, I am not my user. Now type it.
393
394132 - Expert Blind Spot Solution
395Now, write it on a Post-it note, and stick it to your monitor. If you wear glasses, write it on the inside of the lens. Record yourself saying it on your phone, and set that as your ringtone. Do whatever you have to do to remember. I am not my user.
396
397133 - Reflections: Learned Helplessness and Expert Blindspot
398In order for us to really sympathize with users suffering from the effects of learned helplessness and expert blind spot, it's important for us to understand what it's like to be in that position. We've all experienced these things at some point in life, although at the time, we might not have understood what was happening. So take a second and reflect on a time when you experienced learned helplessness and the effects of expert blind spot from someone trying to teach you something. It might have been in a class, it might be learning a new skill, or it might be doing something that everyone else seems to do just fine day to day, but for whatever reason, you've always struggled with.
399
400134 - Reflections: Learned Helplessness and Expert Blindspot Solution
401The fact that I'm filming this in the kitchen probably tells you where I experience this. Anything related to cooking, I feel completely helpless. I've given myself food poisoning with undercooked meat lots of times, I once forgot to put the cheese on a grilled cheese sandwich. I accidentally made toast, and it wasn't even good toast. And I've always heard, it's just so easy, just follow the recipe, but no, it's not that easy, because many recipes are written for experts. So for example, here's a recipe from my wife's cookbook. It calls for a medium saucepan. Is this a medium saucepan? I have no idea. Calls for one egg beaten with a splash of water. A splash, like a splash when you over fill a water bottle or a splash when your sibling soaks you at the pool? Pulse to combine. Cook until the edges are golden brown. What's golden brown? Give me a color code and I'll compare it, but otherwise, I don't know where on the spectrum from golden to brown, golden brown lies. These are examples of places where the directions are given in a way that assumes I already have some expertise, that I really don't have.
402
403135 - GOMS Model
404The GOMS model is a human information processor model so it builds off the processor model of the human's role in a system. The GOMS model gets it's name from the four sets of information it proposes gathering about a task. G, stands for the users Goals in the system. O, stands for the Operators the user can perform in the system. M stands for the Methods that the user can use to achieve those goals. And S stands for the Selection rules that the user uses to choose among different competing methods. So the GOMS Model proposes that every human interact with the system has a set of Goals that they want to accomplish. They have sent methods that they can choose from to accomplish those goals. Each of those methods is comprise of a series of Operators that carries out that method. And they have some Selection rules that help them decide what method to use and when. The GOMS model is often visualized like this. The user starts with some initial situation, and they have a goal in mind that they want to accomplish, so they apply their selection of rule to choice between different competing methods to accomplish that goal. Once they've chosen a method, they execute that series of operators and makes that goal a reality
405
406136 - GOMS Model in Action
407We can take the GOMS model and apply it to a number of different domains. So let's take the example of needing to communicate a message to a coworker. We have an initial situation, which is the need to transfer information to a coworker. That carries with it the implicit goal of the information having been transferred. We might have a number of different methods in mind for how we could do that. We could email them, we could walk over and talk to them in person. And we also have some selection rules that dictate how we choose amongst these methods. If what we need to transfer is very time-sensitive, maybe we walk over and talk to them in person or call them on the phone. If the information we need to transfer is complex and detailed, maybe we write them an email. Or if it's more casual, maybe we chat with them or text them. No matter what method we choose, we then execute the series of operators that carries out that method, and the result is our goal is accomplished, the information has been transmitted. Or we could also take the problem of navigation. Our initial situation is the need to get to our destination, which carries with it the implicit goal of having reached our destination. We might have different methods, like take the scenic route, take the highway route, take the surface streets, and some selection rules that might say something like, when it's rush hour on the highway, take surface streets, or if it's not time sensitive, take the scenic route. After choosing, we execute those operators and reach our goal. So in this way, GOMS models capture our goals, our different methods for carrying out those goals, and the individual operators that we use to execute those methods.
408
409137 - Design Challenge: Security System 1
410Let's try this out. We're going to watch Morgan enter the house and undo her security system two different ways. After you watch the video, try to outline Morgan's goals, outcomes, methods, and selection rules. Now try to outline the goals, outcomes, methods and selection rules for these two methods of disabling the security system.
411
412138 - Design Challenge: Security System 1 Solution
413Here's one example of how you might design a GOMS model for disabling a security system. Our initial situation is that we're entering the home with the alarm set and we have two methods for disabling the alarm. We can use the keypad or we can use the keychain. Either way, our goal is that we've entered the home and reenabled the alarm. Our selection rules might be something like if we have our hands full, we're going to use the keypad so that we can get inside and put the stuff down. But if we don't have our hands full, we'll use the keychain. You might come up with other models for this that have either different methods, different operators, different selection rules. There are a lot of different ways we can capture a task with the GOMS model, depending on what you choose to focus on.
414
415139 - GOMS to Cognitive Task Analysis
416Gomes models are human information processor models. This method largely assumes the human is an input output machine, and it doesn't get too much into the internal reasoning of the human. Instead, it distills their reasoning into things that can be described explicitly like goals and methods. Some would argue, myself included, that human reasoning is actually too nuanced and complex to be so simplified. They, or we, advocate other models to get more into what goes on inside the user's head. That's where cognitive task analysis comes in. Cognitive task analysis is another way of examining tasks, but it puts a much higher emphasis on things like memory, attention, and cognitive load. Thus, cognitive task analysis adopts more of the predictor view of the human's role in the system.
417
418140 - Reflections: Task Analysis
419This conflict between more processor-oriented and more predictor-oriented models of the user actually gets at the core of an old battle in psychology between behaviorism and cognitivism. Behaviorism emphasized things that could be observed. We can see what input a person is receiving. We can see the output they're producing. And that might be all we need to understand the design of things. Cognitivism, on the other hand, suggests we can and should get into the mind of what people are actually thinking and how systems like memory and learning and perception actually work. So take a moment and reflect on what you think about this. When designing interfaces, how much attention should you devote to observable goals, operators and methods? And how much do you devote to understanding internal thought processes, like cognition, learning, and memory?
420
421141 - Reflections: Task Analysis Solution
422You can probably guess my bias on this issue, given that I've already badmouthed the processor model and I also teach cognitive systems. So I'm generally going to prefer methods that focus on cognition. I think it's important to note here though that both approaches have significant value. The GOMS model and its emphasis on identifying goals and operators is actually very useful in HCI. Because it forces us to very clearly and deliberately identify user goals and the sequence of actions that accomplish them. We can get so caught up in user experiences that we forget the user experience is born out of individual operators. So while I wouldn't advocate focusing solely on the user as some kind of input output information processor, there's value in defining the user's operation as clearly and specifically as we define a computer's.
423
424142 - Design Challenge: Security System 2
425Let's watch the videos of Morgan disabling her security system again. This time though, let's try to approach this from a more cognitive task analysis perspective. We won't be able to do that fully, because doing a full cognitive task analysis means interviewing, asking the user to think out loud, and more. But we can at least try out this approach. Remember, in doing a cognitive task analysis for a task like this, your goal is to build a model of the sequence of thoughts going on inside the user's head. Pay special attention to what she needs to remember at each step of the process.
426
427143 - Design Challenge: Security System 2 Solution
428What we saw here was that to get inside and disable the alarm, there was a sequence of actions that had to be completed, but some of them could be completed in different orders. If she used the keypad, she had to first unlock the door and then open the door. Then she could either disable the alarm on the keypad or close the door. And after closing the door, she could re-lock the door, though she could also do that before disarming the alarm. So there's some choices there. With the keychain, the sequence of tasks related to the door remain the same, but she had the option of disarming the alarm before even entering. However, that required remembering to do so. When using the keypad, she didn't have to remember because the alarm beeps at her until she turns it off. But she has to remember the key code. Performing these cognitive task analyses gives us the information necessary to evaluate different approaches and look for areas of improvement. For example, if she can disable the alarm just by pressing the keychain button, why does she need to press it at all? Why doesn't it just detect that she's coming in with a keychain in her pocket?
429
430144 - Cognitive Task Analysis Strengths and Weaknesses
431Just like Goms models, cognitive task analysis also have some strength and some weaknesses. One strength is that they emphasize mental processes. Unlike the Goms model, cognitive task analysis puts an emphasis on what goes on inside the users head. It's thus much better equipped to understand how experts think and work. The information it generated is also formal enough to be used for interface design, for comparison in mode alternatives and more. There are disadvantages though. One, cogni-task analysis are incredibly time-consuming to perform. They involve talking to multiple experts for extended period of time, then systematically analyzing the data. A second weakness is that cogni-task analysis risk deemphasizing context. In zooming in on the individual's own thought processes, cogni-task analysis risks deemphasizing details that are out in the world. Like the role of physical capabilities or interactions amongst different people, or different artifacts. And third, like Goms models, cogni-task analysis also isn't well suited to novices. It's well suited to expert users who have very strong models of the way they work and clearly understand their own mental thought processes. But they're not very well suited for novice users who are still trying to learn how to use an interface.
432
433145 - Other Task Analysis Frameworks
434GOMS and cognitive tasks analysis are just two of the many alternatives to understanding how users approach tasks. More in line with the human information processor models, there exist models like KLM, TLM, and MHP, which capture even finer grain actions for estimating performance speed. There are other extensions to GOMS as well that add things like sub goals, or other ways of expressing content like CPM-GOMS and NGOMSL. CPM-GOMS focuses on parallel tasks, while NGOMSL provides a natural language interface for interacting with GOMS models. More on the lines of cognitive models, there exists other methods as well like CDM, TKS, CFM, Applied Cognitive Task Analyses, and Skill-Based Cognitive Task Analyses. CDM puts a focus on places where critical decisions occur. TKS focuses on the nature of humans' knowledge. CFM focuses on complexity. ACTA and Skill-Based CTA are two ways of gathering the information necessary to create a cognitive model. There also exists other frameworks more common in other disciplines, for example, production systems are common to an artificial intelligence. But they're intended to model cognitive systems the same way these cognitive models do. So we can apply production systems here as well and attempt to prescribe rules for users to follow.
435
436146 - Introduction to Distributed Cognition
437In discussing a human-computer interaction, there's often a tendency to look narrowly at the user interacting with the computer. Or slightly more broadly at the user interacting with the task through some computer. But many times we're interested in zooming even further out. We're interested, not only in the interaction between the human, the computer and the task, but also in the context in which that interaction takes place. So today we're going to look at four different models or theories, of the context surrounding ACI. We'll focus primarily on distributed cognition, which is one of the dominant theories on the interplay between multiple agents, artifacts, and contexts. We'll also touch on three other significant theories, social cognition, situated action, and activity theory.
438
439147 - How a Cockpit Remembers Its Speeds
440In order to understand the application of distributed cognition to the cockpit, it's important for us to first understand what challenge it's addressing. The technical reasons for this are a bit complex, and I strongly encourage reading the full paper to get the full picture. But to understand the simplified description I'll give here, here's what you need to know. When a plane is descending for landing, there exists a number of different changes the pilots need to make to the wing configurations. These changes are made at different speeds during the descent. When the plane slows down to a certain speed, it demands a certain change to the wind configuration. The speeds at which these configuration changes must happen differ based on a number of different variables. So for every flight there's a unique set of speeds that must be remembered. That's why the title of this paper is, How a Cockpit Remembers Its Speeds, Speeds, plural. It isn't just remembering how fast it's going now, it's remembering a sequence of speeds at which multiple changes must be made. The configuration changes to the wings must be made during the descent at narrowly defined times. That creates a high cognitive load. Pilots must act quickly. And mistakes could mean the deaths of themselves and hundred of others. So how do they do this? First, the pilots have pages that contain the speeds for their descent, based on different parameters. The cockpit itself has an entire booklet of pages like this. So we know that the cockpit has its pilots who are responsible for actually reasoning over things. But that booklet forms that cockpits long term memory of different speeds for different parameters. Then, prior to the descent, the pilots find the page from that booklet that corresponds to their current parameters. They pull it out and pin it up inside the cockpit. That way, the sheet is accessible to both pilots. And they're able to check one another's actions throughout. This becomes one form of the cockpits short term memory, a temporary representation of the current speeds. At this point, we have to attribute knowledge of those speeds to the cockpit itself. If we were to isolate either pilot, they would be unable to say what the speeds are from memory, but without the pilots to interpret those speeds, the card itself is meaningless. So it's the system of the entire cockpit, including the pilots, the booklet and the current card that remembers the speeds. Then as the pilots begin the descent, they mark the different speeds right on the speedometer with these little speed bugs. The speed bugs tell them which speeds to remember in a way that can just be visually compared. When they see the speedometer pass a speed bug, they know it's time to make a certain change. This is like the working memory for the cockpit. The short-term memory stores the numbers in a way that the pilots can reason over, but the speed bugs on the speedometer store them in a way that they can very quickly just visually compare. They don't need to remember the numbers themselves, or do any math. All they have to do is visually compare the speed bugs to the current position of the speedometer. So what do we see from the system as a whole? Well, we see the long term memory in the book of cards. We see a short term memory in the card they selected. We see a working memory in the speed bugs on the speedometer. And we see decisions on when to make configuration changes distributed across the pilots and these artifacts. No single part of this cockpit, not the pilots, not the speed bugs, not the cards, could perform the action necessary to land a plane on their own. It's only the system as a whole that does so. That's the essence of distributive cognition. The cognition involved in landing this plane is distributed across the components of the system. This is a deeper notion than just using interfaces to help us do tasks. The important thing here is that these different interfaces serve cognitive roles in the system.
441
442148 - Distributed Cognition and Cognitive Load
443Distributed cognition is deeply related to the idea of cognitive load. Recall the cognitive load refers to your minds ability to only deal with a certain amount of information at a time. Distributed cognition suggests that artifacts add additional cognitive resources. That means the same cognitive load is distributed across a greater number of resources. Artifacts are like plugging extra memory into your brain. Driving is a good example of this. Sometimes while driving, you're cognitive load can be very, very high. You have to keep track of the other cars around you. You have to keep track of your own speed to monitor your route planning. You have to make predictions about traffic patterns. You have to pay attention to your own level of gasoline, or in my case, electric charge. You might be attending to something in your car as well, like talking to your passenger, or keeping an eye on your child in the back seat. It can be a big challenge. A GPS is a way of off-loading one of the tasks, navigation, on to another system. And thus, your cognition, is now distributed between you In the GPS. Turn on cruise control and now it's distributed across the car, as well. Your off loading the task of tracking your speed to the car. Every task you also de-artifacts, decreases your own personal cognitive load.
444
445149 - Exercise: Distributed Cognition
446Let's analyze a simple task from the perspective of distributed cognition. Here we see Morgan paying some bills the old fashioned way. For each bill she pulls it off the pile, reads it, writes a check and puts them together in a stack on the right. Where do we delineate this system? What are its parts?
447
448150 - Exercise: Distributed Cognition Solution
449We're interested in any part of the system that performs some of the cognition for Morgan. While the chair, table, and light over head make this possible, they aren't serving any cognitive roles. Morgan herself, of course, is, and two piles of bills are too. They are an external memory of what bills Morgan has already paid, and what she still needs to pay. This way she doesn't have to mentally keep track of what bills she has left to do. The bills themselves remember a lot of the information for her as well like the amounts and the destinations they need to be sent to. What about the pen and checkbook? That's when things start to get a little bit more tricky. The checkbook itself is part of the system because it takes care of the record keeping task for Morgan. Checkbooks create carbon copies, which means Morgan doesn't have to think about tracking the checks manually. The pen is a means of communicating between these systems, which means it's part of our distributed cognition system as well.
450
451151 - Distributed Cognition as a Lens
452Something important to note is that distributed cognition isn't really another design principle. Distributed cognition is more of a way of looking at interface design. It's a way of approaching the problem that puts your attention squarely on how to extend the mind across artifacts. We can actually view many of our design principles as examples of distributed cognition. So this is my computer, and when I set this up, I wasn't thinking about it in terms of distributed cognition. And yet we can use distributive cognition as a lens through which to view this design. For example, I always have my calendar open on the right. That's a way of off loading having to keep track of my daily schedule in working memory. It bugs me if I have a teleconference to attend or somewhere I need to go. In fact I rely on this so much it gets me in trouble. It doesn't keep track of where I need to be for a given meeting and if I fail to keep track of that in working memory I might end up at home when I need to be at Georgia Tech. We can even view trivial things like a clock as an example of distributed cognition that prevents me from having to keep track of the passage of time manually. The point is that distributed cognition is a way of looking at interfaces and interface design that focuses your attention on what systems as a whole can accomplish as opposed to individuals on their own.
453
454152 - Reflections: Distributed Cognition
455Distributed cognition is a fun one to reflect on because we can take it to some pretty silly extremes. We can go so far as to say that I don't heat up my dinner. The system compromised of myself and the microwave heats it up. And I offload the need to track the time to cook on to my microwave's timer. And that's a perfectly valid way of looking at things. But what we're interested in is places where interfaces don't just make our lives more convenient. We're interested in places where they systems comprised of us and interfaces are capable of doing more, specifically because those interfaces exhibit certain cognitive qualities. The systems might perceive, they might remember, they might learn, they might act on our behalf. In some way they're all floating a cognitive task from us. And as a result, the system comprised of us and the interface, is capable of doing more. So reflect on that a bit, what is the place where the system comprised of you and some number of interfaces is capable of doing more than you alone? Specifically, because of the cognitive qualities that the interfaces possess.
456
457153 - Reflections: Distributed Cognition Solution
458Almost any interface on the computer can be analyzed from the perspective of distributed cognition but right now, I'm most interested in my email. My email is an unbelievable extension of my longterm memory because whenever I see anything in email, I know I don't actually need to commit it to my own long-term memory. It's there, it's safe forever and if I ever need to find it again, I'll be able to find it. Now, finding it might take some work sometimes, but rarely as much work as manually remembering it. For me, I also mark messages as unread if I'm the one they're waiting on, or if I need to make sure I come back to them. And so, my email is an external memory of both all my communications via email, and tasks that are waiting on me to move forward.
459
460154 - Distributed Cognition to Social Cognition
461Distributed cognition is concerned with how the mind can be extended by relations with other artifacts and other individuals. Because we're interface designers, we probably focus most of our time on the artifacts part of that. After all, even though we're designing tasks, the artifacts are what we're actually creating that's out in the world. But the other part of distributed cognition, distributing across individuals presents a powerful opportunity as well. This used to be far more important, actually. Before the days of GPS navigation, a different form of navigation assistance existed. It was your spouse or your friend sitting in the passenger seat, reading a map and calling out directions to you. And while mobile devices and artificial intelligence may have replaced humans in some such systems, there are still lot's of places where the role of distributing across humans is crucial. Here's an example of this in action today. At Udacity, we use a tool for managing projects called JIRA. It breaks down projects into multiple pieces that can be moved through a series of steps and assigned to different responsible individuals. The entire value of JIRA is that it manages distributing tasks across members of a team. Thus, when a project is completed, it is completed by the system comprising the individual team members and JIRA itself.
462
463155 - Social Cognition
464The social portion of distributed cognition is concerned with how social connections create systems that can, together, accomplish tasks. So for example, you and your friend sitting in the passenger seat, together form a system capable of navigating to a new destination without a GPS. But social cognition is not only concerned with how social relationships combine to accomplish tasks. It's also concerned with the cognitive underpinning of social interactions themselves. It's interested in how perception, memory, and learning relate to social phenomena. As interface designers though, why do we care? Well, in case you haven't noticed, one of the most common applications of interface design today involves social media. Everything is becoming social. Facebook tries to tell you when your friends are already nearby. Udacity tries to connect you with other students working on the same material as you. Video games are increasingly trying to convince you to share your achievements and highlights with your friends. And yet, often times, our interfaces are at odds with how we really think about social interaction. Designing for this well involves understanding the cognitive underpinnings of social relationships. My Play Station, for example, has a feature for finding my real life friends, and then communicating to them my gaming habits. But really, I probably don't want them to know how much I might play video games. If I come unprepared for recording today, I certainly don't want Amanda to know it was because I was playing Skyrim for six hours last night. So if we're going to design interfaces that integrate with social interactions, we have to understand how social interactions actually work. So an understanding of social cognition is very important if that's the direction you want to take.
465
466156 - Design Challenge: Social Cognition
467Let's talk about challenge of designing for social relationships. I like to play video games. I'm friends with people from work. So it's natural that I might want to play games with people from work. But at the same time, my relationship with people from work isn't purely social. If they see I'm playing a game, maybe they say, hey, David's got some free time. I should ask him to help me out with something. Or if they see I spend a lot of time playing video games, maybe they more generally say hey, David's got plenty of time to take on a new tasks. How do we design a social video gaming system that nonetheless protects against these kinds of perceptions?
468
469157 - Design Challenge: Social Cognition Solution
470There are lot of creative ways we might tackle this problem. One might be a base social video game relationship around something like tender. Tinder, if this is still around by the time your watching this, is a dating app were you express interest in another's in are only connected if they also express interest in you. We can apply the same colonoscopy to video games. You can set it such that My Contacts can't just look up my game playing habits. But if they're also playing or interested in playing, they'll learn that I am playing as well. In terms of social cognition, that's kind of getting at the idea of an in-group. Your behaviors are only seen by those who share them and thus are in no position to judge them.
471
472158 - Situated Action and Memory
473Situated action gives us a valuable lens to examine issues of memory. We mention in our lessons on memory and on design principles that recognition is easier than recall. People have an easier time recognizing the right answer, or option when they see it rather than recalling it from scratch. That's in part because memory is so context dependent. Recognition provides the necessary context to identify the right option. Relying on recall, means there's little context to cue the right answer to the users memory. Now I encountered an interesting example of the value of situated action a little while ago. My mother just had surgery. And so I would often go over to help her out with things. And everytime I would go over, she'd have four, five favors to ask me. Inevitably I would forget a couple of those favors and have to be reminded, but she would always remember. Why was she so much better able to remember the favors than me? Does she just have a better memory? She didn't make a list. She didn't write them down or anything like that. So the distributed cognition perspective doesn't find an external memory being used or anything like that. My hypothesis from the perspective of situated action, is that she has the context behind the tasks. She knows why they need to be done. She knows what will happen if they aren't. For her, they're part of a broader narrative. For me, they're items on a list. I have no context for why they're there. Or what would happen if they're undone. For her, they're easy to remember because they're situated in a larger context. For me, they're difficult because they're isolated.
474
475159 - Activity Theory
476Activity theory is a massive and well developed set of theories regarding interaction between various pieces of an activity. The theory as a whole is so complex that you could teach an entire class on it alone. It predates HCI. And in fact, activity theory is one of the first places the idea of interacting through an interface actually came from. In our conversations about HCI though, there are three main contributions of activity theory that I'd like you to come away with. First, when we discuss designing tasks and completing tasks through an interface, we risk missing a key component. Why? We could jump straight to designing the task, but why is the user completing the task in the first place? That can have significant implications for our design. Activity theory generalizes our unit of analysis from the task to the activity. We're not just interested in what they're doing, but why they're doing it and what it means to them. Our designs will be different, for example, if users are using a system because they're required to or because they choose to. Notice how this is similar to our discussion of distributed cognition, as well. In distributed cognition, we were generalizing the unit of analysis from a person, to a system of people and artifacts. Here, we're generalizing the unit of analysis from a task to an activity surrounding a task. In both ways, we're zooming out on the task and the design space. Second, activity theory puts an emphasis on the idea that we can create low level operations from higher level actions. We saw something similar to this with GOMS models, where methods were made up of operators. This has a special historical significance. Before activity theory and similar theories reached HCI in the 1980s, HCI was largely concerned with minute things, like how quickly a person can click a button or type in a command. Activity theory helped us zoom out from those low level interactions, those low level operators, to general user needs at the action or the activity levels. And third, activity theory points out that actions by the user can actually move up and down this hierarchy. A common example of this is driving a car. The first time you drove a car, shifting gears between park and drive was a very conscious action made up of operators like grabbing the gear shift and moving it in the right direction and letting go. You had to think about how to press the button, which way to push the stick, and when to release it. However, after driving a few times, shifting gears just becomes second nature. It becomes more like an operator. It shifted from being a conscious goal to an operator in your broader driving behavior. Notice a similarity here to our previous discussion on learning curves. How quickly an action moves from being a conscious action to a subconscious operator is also a function of how good the learning curve is on that design. Notice also, this is similar to the question of invisible interfaces. A good invisible interface helps users focus on their actions inside the task, rather than the operators they use to interact with the system.
477
478160 - Introduction to Interfaces & Politics
479In 1980, Langdon Winner published a highly influential essay in which he ask, do artifacts have politics? In other words, do technical devices have political qualities? And the answer is yes. All toasters are democrats. Thermostats, as you might expect, are members of labor party. And pretty surprisingly automobiles are actually green party members. Okay, I'm kidding. That's not what we mean when we ask if artifacts have politics. Here, when we say politics we mean whether artifacts can personify specific forms of authority or power, whether for good or bad. What we're referring to is the fact that artifacts are interfaces we design, change the world around us, just the way politicians or business interests do. Sometimes that's by design, we might design interfaces not for usability, or research, but to create change in the world. Other times that social change happens in ways we didn't anticipate, we design interfaces that are used and affect the world in ways we never anticipated. So in this lesson, we're going to talk about two dimensions of this, designing for change and anticipating the change from our designs. We'll also touch on a field that explores these issues more deeply called Value-Sensitive Design.
480
481161 - Change: A Third Motivation
482Most commonly in HCI, we're interesting in designing for usability. We want to make tasks easier through technology. So in a car, we might be interested in designing a GPS that can be used with the fewest number of taps. Or a dashboard that surfaces the most important information at the right time. Sometimes we're also interested in designing for research, though. We might design a dashboard that includes some kind of visualization of the speed to see if that changes the way the person perceives how fast that they're going. But a third motivation is to somehow change the user's behavior. Designing for change in response to some value that we have. Often times that may actually conflict with those other motivations. If we're trying to discourage an unhealthy habit, we might want to make the interface for that habit less usable. Cars actually have a lot of interfaces created with that motivation in mind. If I started driving without a seatbelt on, my car will beep at me. Some cars will cap your speed at a certain number. Those interfaces serve no usability goals but rather they serve the goal of user safety. Now, that's a simplistic example, but it shows what I call the three goals of HCI. Help a user do a task, understand how a user does a task, or change the way a user does a task due to some value that we hold, like safety or privacy.
483
484162 - Negative Change by Design
485Let's start with the bad news. The ability of interfaces to change behavior can be abused. We're not just talking about places where people put explicit barriers up like blocking certain people from accessing their content. There are instances where people create seemingly normal designs with underlying political motivations. Winner describes one such instance in his essay Do Artifacts Have Politics? Robert Moses was an influential city planner working in New York City, in the early 1900s. As part of his role, he oversaw the construction of many beautiful parks on Long Island. He also oversaw the construction of parkways, roads to bring the people of New York to these parks. That's actually where the word parkway comes from. But something unfortunate happened. The bridges along these parkways were too low for buses to pass under them. As a result, public transportation couldn't really run easily to his parks. And as a result of that, only people wealthy enough to own cars were able to visit his parks. What an unfortunate coincidence, right? The evidence shows it's anything but coincidence. Moses intentionally constructed those bridges to be too low for buses to pass under. As a way of keeping poor people from visiting his parks. His political motivations directly informed the design of the infrastructure and the design of the infrastructure had profound social implications. This is an example of winners technology as a form of social order. The bridges could have been taller. There's nothing inherently political about those bridges. It was the way that they were used that accomplished this political motivation. As an interesting aside, I learned recently that the design of Central Park inside New York City was an example of the exact opposite dynamic. The designers were encouraged to put in places where only carriages could access so affluent people would have somewhere to go away from poor people. But the designers specifically made the entire park accessible to everyone. It's not to hard to imagine things kind of like that happening today either. One of the arguments from proponents of Net neutrality is that without it, companies can set up fast lanes that prioritize their own content or worse severely diminished content of their competitors or content critical of the company.
486
487163 - Positive Change by Design
488We can design for positive social changes well though. This goes beyond just encouraging people to be nice or banning bad behavior. Interfaces can be designed that'll lead to positive social change through natural interaction with the system. One example of this that I like is Facebook's ubiquitous Like button. For years, many people have argued for a Dislike button to compliment the Like button. Facebook has stuck with the Like button though, because by its design, it only supports positive interactions. It dodges cyberbullying, it dodges negativity. For usability purposes, it's a weakness because there are interactions I can't have naturally in this interface. But this specific part of the Like button wasn't designed with usability in mind. More recently, Facebook has added to the like button with five new emotions, love, haha, wow, sad and angry. Even with these five new emotions though, the overall connotation is still positive. For three of them, it's obvious why. Love, haha and wow are more positive emotions. Sad and angry are negative emotions, but used in this context, they take on more of a sympathetic connotation. If someone is ranting about getting into a car accident, it seems to weird to like that. But if you react with this angry emoticon, then you're basically saying you're angry on their behalf. It might be possible to use this for the more negative connotation like if someone said they like a political candidate and you react angrily, then you could be opposing their political view. But in the majority of cases, these are still going to be used in a way that fosters positive interaction. So it seems that this interface was designed to foster positive social interactions online. At the expense of usability, it would come with supporting all social interactions online. This also doesn't have to be strictly about dictating change, but it can also be about supporting change. For example, until a few years ago, Facebook had a more limited set of relationship options. They had married, engaged, in a relationship, single and it's complicated. As it's target audience went from being college students to everyone, they also added separated, divorced and widowed. But it was a couple of years after that that they then added in a civil union and in a domestic partnership. Adding these concepts didn't magically create these social constructs, they existed legally before Facebook added them here. But adding them here supported an ongoing societal trend and gave them some validity. And made people for whom these were the accurate relationship labels feel like they really were part of Facebook's target audience, they were part of modern culture. That an accurate representation of their relationship status was available on this drop down meant they could accurately portray who they were on their Facebook profile. The same can be said for the more recent trend to expand Facebook's gender options to allow people to put in a custom gender. This supports a diverse group of people feeling as if the interface is designed with them in mind. Which in turn supports society's general movement towards acceptance.
489
490164 - Design Challenge: Change by Design
491Let's tackle Change by Design by designing something for Morgan. So Morgan has a desk job. That means she spends a lot of her time sitting. However, for health reasons, it's best for her to get up once per hour and walk around just for a few minutes. There are a lot of way we could tackle this by physically changing the design of her environment to a standing desk or by giving her an app that directly reminds her or rewards her for moving around. But let's try to do something a little bit more subtle. So let's design something for Morgan's smartphone that gets to move around for a couple minutes every hour without directly reminding her to walk around or rewarding her for doing so.
492
493165 - Design Challenge: Change by Design Solution
494So here's one idea. Imagine a weather tracking app that crowdsourced weather monitoring. Every hour participants are buzzed to go outside and let their phone take some temperature readings, maybe take a picture of the sky. That design has nothing at all to do with moving around, but that's the side effect of it. Participation in this seemingly unrelated activity has the benefit of getting people moving. Pokemon GO is a great example of this in a different context. It doesn't spark the same kind of intermittent exercise but it gets people to exercise more generally, all without ever actually telling them to do so.
495
496166 - Positive Change by Happenstance
497Positive change doesn't always have to happen by design though. In fact there are numerous examples of positive change happening more as a bi-product of technological advancement rather than as a goal of it. In Bijker's, of Bicycles, Bakelites and Bulbs, this is the bicycle example. The story looks at what women can do before and after the invention of the bicycle. Before the bicycle, women tend to be pretty reliant on men for transportation. People generally got around with carriages, which were pretty expensive, so only wealthy people would own them. And so, typically men would own them. So if a woman wanted to go to a restaurant or go to a show, she typically had to go either with her spouse or with her father. As a result, society rarely saw women acting individually. They were usually in the company of whoever the prominent male in their life was at the time. But then the bicycle came along. The bicycle was affordable enough and targeted at individuals, so now women could get around on their own. So now a woman could go to a show or go to a restaurant by herself, instead of relying on a man to take her. In the book though, what Bijker covers is not just the fact that this enabled more individual transportation, but rather that this enabled a profound social shift. This technological innovation allowed women to start acting independently. And it also demanded a wardrobe change, interestingly enough, because you couldn't wear a dress on a bicycle. So the invention of the bicycle simultaneously changed women's' attire, and changed the level of independence they could show in modern society. And both these changes force society to challenge traditional gender roles. The bicycle's role in women's liberation was so significant that Susan B Anthony actually once said, I think bicycling has done more to emancipate women than anything else in the world. But when the bicycle was invented, it's doubtful that the inventor sat down and said surely this will be a great way to emancipate women and change our culture's gender roles. That's not what they had in mind. They were inventing a technological device. But as an unintended positive side effect, that technological device profoundly changed society.
498
499167 - Negative Change by Happenstance
500Just as we can create positive changes by accident, if we aren't careful, we can also inadvertently create negative changes as well, or further preserve existing negative dynamics. A good example of this is the proliferation of the Internet in the first place. When the Internet first came along, it piggybacked on existing phone lines. Then it started piggybacking on more expensive cable TV lines. And now it's following along with very expensive fiber optic lines. At every stage of the process, areas with more well developed infrastructure get the latest Internet speeds first. However, generally the areas with well developed infrastructure are the wealthier areas in the first place, either because wealthier citizens paid for the improved infrastructure. Or because people with the means to move wherever they want to move, will move somewhere with better infrastructure. High speed internet access is a big economic boon. And yet areas that are already economically advantaged are generally the first ones to get higher speed internet access. Even today, in poorer parts of the United States the only available Internet connections are slow, unreliable satellite connections with strict data caps. And in the rest of the world this issue can be even more profound, where many areas have no internet access whatsoever. And yet, this isn't intentional. Unlike the bridges on Long Island, no one is saying, let's withhold broadband access from poor people to keep them poor. Instead, it's natural to install better connections where there's already an existing infrastructure to build on. But that very natural plan has profoundly negative implications for equitable access to the Internet. So if we're not careful, completely innocent and completely logical design ideas can actually perpetuate negative effects in society.
501
502168 - Value-Sensitive Design
503In HCI, we describe the idea of interfaces becoming invisible. Some of that is a useability principle, but it also applies more broadly to the way that interfaces integrate themselves into our everyday lives. And if our interfaces are going to integrate into people's lives, then they need to share the same values as those individuals as well. This connects to the field of value sensitive design. The Value Sensitive Design Lab at the University of Washington defines this idea by saying, value sensitive design seeks to provide theory and method to account for human values in a principled and systematic manner throughout the design process. In this way, value sensitive design is another dimension to consider when designing interfaces. Not only is an interface useful in accomplishing a task and not only is it usable by the user, but is it consistent with their values? One of the most well-developed application areas of value sensitive design is privacy by design. Privacy is a value, and privacy by design has aimed to preserve that value in the design of systems. It's possible to design useful usable interfaces that don't take privacy into account anywhere. That's what makes an examination of user's values an extra dimension of interface design.
504
505169 - Value-Sensitive Design Across Cultures
506One of the challenges with value sensitive design is that values can differ across cultures. The internet makes it technologically possible to design single interfaces that are used by people in nearly every country, but just because it's technologically possible doesn't mean it's practically possible. And one reason for that is different countries and cultures may have vastly different values. A relatively recent news worthy example of this occurred with the rights to be forgotten. The right to be forgotten is a law in the European union, that allows individuals some control over what information is available about them online. That's a value held by the European Union. However, technologies like Google were not generally developed with that value in mind. So there's actually been an extraordinary effort to try to technologically support that right to be forgotten, while still providing search capabilities. Making this even more complicated is the fact that the value isn't universally shared. Many people argue that the law could actually effectively become internet censorship. So now we start to see some conflict in the values between different cultures. One cultures value of privacy, might run a rye of another cultures value of free speech. If we're to design interfaces that can reach multiple cultures, we need to understand the values of those cultures. Especially if it might force us to design different systems for different people in order to match their local values.
507
508170 - Reversing the Relationship
509We've talked a good bit about how technology and interfaces can affect politics and culture and society, but we wouldn't be telling the whole story if we didn't close by noting the alternate relationship as well. Political relationships and motivations can often have an enormous impact on the design of technology. From Bijker's book Of Bicycles, Bakelites, and Bulbs, the bulbs part refers to the battle of the design of the first flourescent lightbulb in 1938. General Electric created a new kind of light that was far more energy efficient. The power companies were afraid that this would reduce power consumption and cut into their profits. After a long drawn out battle involving the Anti Trust Division of the US government and the US Department of War, the fluorescent bulbs that were ultimately sold were not as good as they technologically could be in order to preserve others' business interests. That issue is more prevalent today than ever. More and more, we see compatibility between devices and usage policies for technologies determined not by what's technologically possible but by what satisfies political or business needs. So here's an example. To keep up with everything that I like to watch on TV I have five different subscriptions. I have cable TV, I have Hulu, I have Amazon Prime, I have Netflix and I have an HBO subscription on top of my cable subscription. And that's not to mention things that I watch for free on their own apps like Conan or anything on YouTube. And you might think wouldn't it be awesome to just have one experience that could navigate among everything I want to watch. And it would be awesome, and there's no technological reason against it. But there's a complicated web of ownership and licensing and intellectual property agreements that determine the way that technology works. Technology changes society but society changes technology too.
510
511171 - Reflections: Interfaces and Politics
512You have almost certainly experienced political or business motivations changing the way in which a technology of yours works. Similar to the fluorescent light bulb, often times these motivations are to preserve the power or profit of an influential organization in the face of radical change. Sometimes they might be the products of a relationship or an agreement between vendors or organizations to emphasize one another's content. Generally, these are instances where technology either performs sub-optimally or has certain features because someone besides the user benefits. So reflect for a second and see if you can think of an instance where some technology you use was designed with this kind of political motivation in mind.
513
514172 - Reflections: Interfaces and Politics Solution
515This question can have some pretty loaded answers and I encourage you to give those answers. But I'm going to give a slightly more innocuous one, exclusivity agreements in video games. Imagine I'm a video game developer and Amanda is Nintendo. And I'll say hey, Nintendo I'll agree to release my game only on your console, if you agree to promote my game in your console advertisements. I benefit from free advertising, Nintendo benefits from getting a selling point for its console. There's probably no technological reason my game can't run on other consoles. But there's this business relationship determining the way that the technology works.
516
517173 - Introduction to Conclusion to Principles
518In this unit we've talked about the various different design principles that have been uncovered after years of research and work in HCI. And while they are presented in many ways as individual sets of guidelines and principles, there is a lot of overlap among them. So in this recap of the unit, we'll try to tie all these seemingly different threads together. We'll also ask you to reflect on how you might apply some of these concepts as a whole to certain design problems.
519
520174 - Zooming Out: Human as Processor
521One way of knitting together the different ideas of HCI is to start very close and zoom out. At the narrowest level, we might view HCI as the interaction between a person and an interface. This is the processor model of the role to human knit system. This too looks almost like an interaction between two computers, one just happens to be a human. But humans' actions are approached almost computationally. If you're going to take this model, we need to understand a lot about what the human can sense, remember, and physically do. The model approaches HCI in this manner as well. It distills the human's role into goals, operators, methods and selection of rules, all of which can be externalized. But this is a pretty narrow view of HCI.
522
523175 - Zooming Out: Human as Predictor
524For the most part, we're interested in something more task-focused. In fact, this is where we'll likely spend the majority of our time. This is the user interacting through some interface to accomplish some task. That's what we mean by the predictor model of the user. The user is actively involved in looking at the task, making predictions about what to do, and making predictions about what will happen. This is where we looked at the gulf of execution and the gulf of evaluation. How hard is is for the user to interact with a task? And how hard is it for them to get feedback on their interaction? Here we also look at how the interface can ideally disappear from this interaction, making the user feel like they're working directly with the task, not interacting with an interface. Now, many of our design principles are constructed specifically to help with this. To help users more quickly make sense of the interface, and understand the underlying task. But in order to design this interaction effectively, we have to understand the way the user thinks about the task they're performing. We have to understand their mental models and in turn, we have to help make sure their mental models match the actual task. Here we have to get into questions like understanding the user's errors and understanding the mapping between representations and the understanding tasks. We also have to address questions like expert blind spot and learned helplessness. Now, fortunately, we have a tool to help us with this. Cognitive task analysis and its related hierarchical task analysis. So much of what we deal with in HCI occurs within this process of a human completing a task through some interface.
525
526176 - Zooming Out: Human as Participant
527However, that's not all we're interested in. We're also interested in how this interaction occurs beyond just the individual and the interface and the task. That's what was meant by the participant model of the user. The user is not merely interacting with an interface or interacting with a task through an interface. They're interacting with other interfaces, other individuals and society as a whole. They are active participants in the world around them. For example, sometimes we're interested not only in the tasks of the users performing, but also in their motivations and reasons for performing it. That's what activity theory advocates. Treating the unit of analysis not as a task, but as an activity including some elements of the context surrounding the task. Other times we're interested in how artifacts and minds combine to help accomplish the task. That's what distributing cognition advocates. Or other times we are interested in deeply understanding the situated context in which a person is acting, that's where situated action comes in. And other times, we're interested in how this all integrates with existing social norms and social relationships. That's what social cognition tries to examine, other times we're interested in dynamics even broader than this. Sometimes, we're interested in how the interfaces we design can create positive social change. Or sometimes we're interested in how the interfaces we design might risk perpetuating existing negative relationships in society. That's exactly the goal of some of our design guidelines as well. To use interfaces to create a more equal society for all people. So this diagram describes from a very low level to a very high level, what we're interested in throughout this portion of HCI.
528
529177 - Reflections: HCI Principles
530When we started that conversations I commented that when you do HCI right, users won't actually know you've done anything at all. Good HCI disappears between the user and the tasks that they're completing. As a result, people can underestimate how complex good HCI can be to leverage. In this unit, one of my goals has been to help pull back the curtain on all the theories that go on behind the scenes of the designs of some of the interfaces that you use everyday. So as we close this unit, take a second to reflect on the interfaces you use that have disappeared between you and the task. Focus especially on interfaces that were never visible in the first place, not interfaces that became invisible by learning. Which of the principles that we've discussed do you now see at play in the design of some of those interfaces?
531
532178 - Reflections: HCI Principles Solution
533For me, I'm actually using an example of one of these interfaces right now. I have a teleprompter in front of me. I didn't always use a teleprompter, but as soon as I tried one, I was hooked. And part of that is because of how well designed the interface is. The very first time I used it, it made things immediately easier, instead of introducing a new learning curve. First, it uses very simple interactions, quick presses that accomplish anything I could need during the actual recording process. Second, it builds on a good mental model of the task that I'm performing. It understands, that while recording, the only things I need to do regularly are pause, play, scroll back, and scroll forward. There are a lot of other options that it has but it keeps those out of the way during the actual recording process, because they're not necessary at the time. Personally though, I think the teleprompter is great to analyze from the prospective of distributed cognition. I struggle when recording with talking too fast. Without the teleprompter, I have to remind myself to slow down, while also remembering what to say. That's a lot to keep in memory at the same time. The teleprompter lowers the cognitive load involved in remembering what to say, but it also controls my speed because I can't read what hasn't yet appeared. So the teleprompter takes care of two cognitive processes. Remembering what I have to say, and monitoring the speed at which I am presenting. So the system comprised of the teleprompter and me is better at recording than I am alone.
534
535179 - Design Challenge: Designing Audiobooks for Exercisers
536Let's go back to our original design challenge for Morgan from the very beginning of this unit. We talked about how Morgan wants to be able to listen to audio books on the go which includes things like leaving bookmarks and taking notes. Using everything we've talked about so far, revisit this problem. Start by thinking narrowly about the physical interactions between Morgan and the interface and then zoom out to her interactions with the task as a whole, then zoom out even further to how the interaction between Morgan and the interface or relates to other things going on in the world around here. And last, think about how interfaces like this have the potential to effect society itself.
537
538180 - Design Challenge: Designing Audiobooks for Exercisers Solution
539There are a lot of designs that you could propose, but the question here isn't what you design, the question is, how will you develop it? How will you evaluate it? How do you know which ideas are good and which are bad? Now we've given some heuristics and principles for doing this, but that doesn't automatically get you to a good interface. That just kind of establishes a baseline. That's just what the principles portion of this course covers. To fully develop interfaces using these principles, we need the methods of HCI as well.
540
541181 - Stakeholders
542When we talk about user-centered design, we throw around the word user as if it's pretty obvious what it means. The user is the person who uses the interface that we create, right? However, that's not the only person in whom were interested. There are multiple stakeholders in this design, and we want to explore how our design is going to affect all of them. The user themselves is what we call the primary stakeholder. They're the person who uses our tool directly. Secondary stakeholders are people who don't use our system directly, but who might interact with the output of it in some way. Tertiary stakeholders are people who never interact with the tool or even interact with it's output, but who are nonetheless impacted by the existence of the tool. So let's take a couple of examples of this. Imagine we're designing a new grade book tool that makes it easier for teachers to send progress reports to parents. Teachers would interact with the tool, inputting grades and feedback. And so teachers would be our primary stakeholders. Parents receive the output of that tool. Parents receive the progress reports. And so they're secondary stakeholders. They interact with the output of the system, but not with the system itself. Students don't use the system at all, and maybe they don't even see the progress reports unless parents decide to share them. But they're nonetheless affected by the existence of this system. So they're tertiary stakeholders. School administrators might be another stakeholder, but where they fall in this would differ based on how the school sets up the relationship. If they can use the tool to directly monitor and intervene in student progress, they might be primary stakeholders. If they just see aggregated progress reports so they can monitor things, they might be secondary stake holders. If they never interact with the system in any way, they're nonetheless likely affected by the fact the system is there. And so they'd be tertiary stakeholders. In designing this tool, we need to keep all three kinds of stakeholders in mind. For example, how does parents having more consistent access to great information affect the students? It might foster increased involvement by parents, but it might also facilitate helicopter parenting, where parents are too controlling over their kid's school work and prevent them from developing the necessary metacognitive skills and self discipline that they need to succeed later in life. User-centered design isn't just about catering to the user in the center of this diagram, but it's also about looking at the impact of our designs on all the stakeholders.
543
544182 - Reflections: HCI Methods
545You might actually come from a software engineering background, and so while user-centric designs sounds obvious to some people, you might have experienced the other side of the coin. In many industries and domains, software engineers are still left to design user interfaces themselves. There's a fantastic book about this called The Inmates Are Running the Asylum, by Alan Cooper. Where he compares technology to a dancing bear at a circus. He notes that people marvel at the dancing bear, not because it's good at dancing, but because it dances at all. The same way, people marvel at certain pieces of technology not because they work well, but because they work at all. The book was released in 2004 and since then the user has become more and more a focal point of design. And yet there is still places where individuals with little ACI background are designing user-facing interfaces for one reason or another. Since it's a stronger chance you've worked in software engineering, reflect on that a bit. Have you seen places where software engineers, data scientists, or even non-technical people were put in charge of designing user interfaces? How did it go?
546
547183 - Reflections: HCI Methods Solution
548I encountered this in my first job, actually. Somewhere between my freshman and sophomore years at Georgia Tech, I had a job as a user interface designer for a local broadcast company. I designed an interface, then I handed it over to a team of engineers for implementation. Late in the process, the requirements were changed a bit and new configuration screen was needed that the engineers just went ahead and looked up. We got the finish tool and it all worked beautifully and perfectly, except for this configuration screen. It was a list of over 50 different settings, each with 3 to 5 radio buttons to the side. Each setting was a different length. Each radio button label was a different length. There was kind of placed all over the campus. There was no grid. It was illegible. It was unusable, but it was technically functional. It met the requirements described in terms of what the user must be able to do, just not how usable it was. Fortunately, there's a greater appreciation of the value of user-centered design now than there was then. So, many spaces have become so crowded that the user experience is what can really set a company apart. I've actually been noticing a trend lately toward new user experiences around really old tasks. I use an app called stash to buy and sell small amounts of mutual funds. Buying mutual funds has been around forever and E-Trade has even been doing that online for a long time. What differentiates stash is the new user experience. Automated investing, simple tracking, simplified summaries. User experience design really has become a major differentiator between success and failure.
549
550184 - The Design Life Cycle
551User centered design is about integrating the user into every phase of the design life cycle. So, we need to know two things. What the design life cycle is and how to integrate the user into each phase. Now if you look up design life cycles you'll find a lot of different ideas. We're going to discuss in terms of a four phase design life cycle that's pretty general and probably subsumes many of the other ones you'll find. The first part of this is Needfinding. In Needfinding, we gather a comprehensive understanding of the task the users are trying to perform. That includes who the user is, what the context of the task is, why they're doing the task, and any other information related to what we're designing. Second, we develop multiple design alternatives. These are very early ideas on the different ways to approach the task. It's important to develop multiple alternatives to avoid getting stuck in one idea too soon. The third step is prototyping. We take the ideas with the most potential and we build them into prototypes that we can then actually put in front of a user. Early on we might do this in very low fidelity ways like with a paper and pencil, or even just verbally describing our ideas. But as we go on we refine and improve. Fourth, and most importantly, we perform user evaluation. We take our ideas that we prototyped and put them in front of actual users. We get their feedback, what they like and what they don't like, what works and what doesn't work, and then the cycle begins anew. The feedback we gain from the users, as well as our experience with these prototypes and design alternatives, improves our understanding of the problem. We now know new areas of the problem we might need to explore with some more need finding. Now we might have some new ideas for design alternatives, or some new ways of expanding the designs that we already have. We then take those things and use them to improve our prototypes. Either prototyping new ideas that we didn't have before, or making our prototypes more rigorous and more polished, so that we can get even better evaluation. And then we put them in front of users again. Each time we go through this cycle our understanding improves, our designs improve, and our prototypes improve. Eventually our prototypes develop to the point of being designs ready for launch, but the cycle doesn't end there. We keep iterating, now with live users doing the evaluation.
552
553185 - Methods for the Design Life Cycle
554At every stage of this design life cycle, we're interested in gathering information from the user to better inform our designs. To do that, we need a number of methods to actually obtain that information. Fortunately, there are a number of methods we can employ to try to gather the information we need. And in fact, the majority of this unit will go through all these different methods. These will become the tools in your toolbox. Things you can call upon to grab the information you need when you need it. Not the many of this method are so well-developed that you can cover them in the entire units, or even entire courses. For example, we'll spend about three or four minutes talking about naturalistic observation. And yet, there are entire textbooks and courses on how to do naturalistic observation really well. The goal of this is to give you enough information to get started and enough to know what you need to explore next. Remember, one of the original goals of this class was not just to understand more HCI but also to understand how big the field of HCI actually is.
555
556186 - Design Life Cycles meet Feedback Cycles
557When we talk about feedback cycles, we talk about how they're ubiquitous across nearly every field. And each CI itself, isn't any different. In a feedback cycle, the user does something in the interface to accomplish some goal. And then judges based on the output from the interface, whether the goal was accomplished, then they repeat and continue. In HCI, we're brainstorming and designing interfaces to accomplish goals. And then based on the output of our evaluations, we judge whether or not the goals of the interface were actually accomplished, then we repeat and continue. In many ways, we're doing the same things that our users are doing, trying to understand how to accomplish a task in an interface. Only in our case, our interface is the tools to build and evaluate interfaces and our goal is to help them accomplish their goal.
558
559187 - Qualitative vs. Quantitative Data
560There is one final distinction we need to understand going forward because it's going to come up at every stage of the design lifecycle, qualitative versus quantitative data. At every stage of the design lifecycle, we're interested in gathering data from users. Early on that might be descriptions of what they do when they're interacting with a task. Or it might be measures of how long certain tasks take to complete, or how many people judge a task to be difficult. Later on, though, it might be whether or not users prefer our new interfaces or how much better they perform on certain tasks. Now data will always fall into one of two categories, qualitative and quantitative. Quantitative is probably the easier one to describe, quantitative data describes anything numeric. When data is summarized numerically, we can perform statistical tests and summaries on it, draw formal conclusions, and make objective comparisons. Now there are a lot of strengths of quantitative data, but those strengths come in large part because quantitative data only captures a narrow view of what we might be interested in examining. It's very strong for a very small class of things. Qualitative data covers pretty much everything else. Qualitative Data covers descriptions, accounts, observations, it's often in natural language. It could be open ended survey responses, or interview transcripts, or bug reports or just your personal observations. Because of its flexibility, qualitative data gives us a much broader and more general picture of what we're examining. But the cost is that it's hard to generate formal conclusions based on qualitative data. Qualitative data may be more prone to biases. Now in some circumstances, we can convert qualitative data into quantitative data. For example, we could count the number of surveys respondents to an end of course survey who mentioned course difficulty in their free response questions. Now the free response question would be qualitative data but numerically summarizing it generates quantitative data. Generally speaking, though, quantitative data and qualitative data serve different purposes in a design life cycle. I've heard it described quantitative data provides the what, the qualitative data provides the how or the why. When performing need finding or when doing some initial prototype evaluations, we're likely interested in users' qualitative descriptions of their tasks or their experiences with the interface. It's generally only after a few iterations that we start to be interested in quantitative analysis, to find numeric improvements or changes. We can also use these in conjunction with one another, collecting both quantitative and qualitative data from the same participants. That's referred to as a mixed method approach, it's a mix of qualitative and quantitative data to paint a more complete picture of the results.
561
562188 - Exercise: Quantitative vs. Qualitative
563Let's do a quick exercise on quantitative versus qualitative data. Let's imagine we're doing end of course evaluations for some class. For each of the following types of data, mark whether it would be considered quantitative or qualitative. You can skip ahead, if you don't want to listen to me read all these out. We have responses to on a scale of 1 to 5, rate this course's difficulty, responses to how much time did you spend per week on this course, responses to what did you like about this course, count of students Students mentioning office hours to the above questions, percentage of students that completed the survey, responses to a forum topic requesting non-anonymous course reviews, the number of participants in a late-semester office hours session, and the transcript of the conversation of that late-semester office hours session
564
565189 - Exercise: Quantitative vs. Qualitative Solution
566Quantitative data is numeric. Any of these things that can be measured numerically, really qualify as quantitative data. Many of these things are things that we can just count. We count the number of students mentioning office hours. We count the number of participants. Here we basically count the number of students that completed the survey and divided by all the students in the class. And here we have them count how many hours per week they think they spend in the course. The first option can be a little bit tricky. On a scale of one to five in a numeric scale, but because students have to choose one, two, three, four or five, it's not a continuous numeric scale. For example, we have no way of guaranteeing the student sees the difference between a three and a four as the same as the difference between a four and a five. The types of analysis we can do on the first kind of data, are more limited. But nonetheless it's still is measured numerically, so it still is quantitative data.
567
568190 - Introduction to Research Ethics
569Before we start working with real users there are a few ethical considerations we have to make. If you are doing a research as part of a university these are part of your contract with the university to do research on their behalf. Even if you are doing research independently for an industry there are still ethical obligations to follow. These considerations are important not only to preserve the rights of our users, but also to ensure the value of the data that we gather. In this lesson, we'll talk a little bit about where these kinds of ethical considerations came from. Then we'll talk about some of the basic ethical considerations that we need to make. We'll also talk about Institutional Review Board, or IRB, the university organization that governs human subjects research.
570
571191 - Origin of Institutional Review Board
572In the first half of the 20th century, a number of pretty clearly unethical human subjects experiments took place. Many of them were conducted by scientists working for the Axis powers during World War II. But famously, many were also conducted right here in our own backyard, here in the United States. Among them were Milgam's obedience experiment where participants were tricked into thinking that they had administered lethal shocks to other participants to see how obedient they would be. There was the Tuskegee syphilis study where rural African American men were intentionally injected with syphilis to study its progression and there was the Stanford prison experiment where participants were psychologically abused to test their limits or test how they would act under different circumstances. In response to all this, the National Research Act of 1974 was passed, which led to the creation of institutional review boards to oversee research at universities. The Belmont Report further summarizes basic ethical principals that research must follow in order to receive government support. Among other things, the law dictated that the benefits to society must outweigh the risks to the subjects in the case of these experiments. It also dictated that subjects must be selected fairly, which was a direct response to the Tuskegee syphilis study. And perhaps most importantly, it demanded a rigorous informed consent procedures. So, the participants know what they're getting into and can back out at any time. These efforts all attempt to make sure that the positive results of research outweigh the negatives and that participant rights are always preserved.
573
574192 - The Value of Research Ethics
575In this lesson, we're largely focusing on the practical steps we go through to get approval for human subject's research. But before we get into that, I want to highlight that this isn't just a bunch of bureaucratic steps necessary to make sure the people are treated ethically at all stages of research, IRBs main task is to make sure the potential benefits of the study are worth the potential risks. So as part of that, part of the role is to make sure the potential benefits are significant. A lot of the steps of the process are going to ensure that the data that we gather is useful. So for example, the IRB is sensitive about the perception of coercion. When participants feel coerced to participate in research, the data they actually supply may be skewed by that negative perception which impacts our results. Similarly, we might design studies that have some inherent biases or issues to them. We might demand too much from participants or ask questions that are known to affect our results. Much of the initial training to be certified to perform research is similarly not just about doing ethical research but also about doing good research. By recording who is certified, IRB helps ensure that research personnel all understand the basics of human subjects research. IRB is also there to monitor for these things as well and many of the steps of this process ensure that the research we perform is sound and useful. After all, if the research we perform is not useful, then even the smallest risks will outweigh the nonexistent benefits.
576
577193 - Getting Started: CITI Training
578If you're going to be doing a research just part of a University project or University class, you need IRB approval. Different universities have different processes and policies for getting started with IRB. We're going to discuss the Georgia Tech policies and sets where these class is based but you should check with your university if you're from somewhere else to make sure you're following the right policies for your school. To get started, we need to complete the required training. So here I'm showing the IRB website, which is researchintegrity.gatech.edu/irb. And to get started, you need to complete your required training. So click required training over on the left. This'll take you to a page that overviews the IRB required training and gives you a link of the left to begin your CITI training. So click that, then login to your Georgia Tech account. And you're going to want to complete Group 2, Social and Behavioral Research Investigators and Key Personnel. I can't show you exactly what it looks like to sign up fresh because I've already completed it. But you should be able to add a course and add that as your course. After you've completed CITI training you'll receive your completion report and then you'll be ready to get started with IRB.
579
580194 - Getting Started: IRB
581After you've completed any necessary training you can access the IRB application for your own university. We're doing this in terms of Georgia Tech, so here's the tool we used called IRBWISE. Here under my protocols, you'll see a list of all of the protocols to which you're added. A protocol is a description of a particular research project. It outlines the procedures that the IRB has approved regarding consent, recruitment, experimentation and more. Here we see approved protocols. Protocols that are new and haven't been submitted yet. Protocols that are waiting for the IRB to act on them. And amendments to protocols. Amendments are how we change earlier protocols to add new researchers or change what we're approved to do. After a protocol is approved, any changes must be submitted to the IRB as an amendment to be accepted separately.
582
583195 - IRB Protocols: Basics
584Generally speaking, you might not ever be asked to complete a protocol yourself. You might instead just be added to an existing protocol. Still, you need to make sure to understand the procedures outlined by any protocol to which you're added, because they still govern what you do. So we'll run through the process of creating a protocol, but this will also cover the details to know about any protocol to which you are added. So for this, I have a draft protocol covering our user study on people who exercise. Every protocol starts with the title of the protocol, and some certified personnel. These are required just to save the protocol. We add approved research personnel on the study personnel page. We would enter their name, select their role, and if their certification isn't already in the system, we would attach it here. After adding them, they'll appear down here. The primary investigator, PI, must always be added first and it must be a faculty member. The protocol description covers the study at a high level. This should briefly touch on what will be done, what the goal of the research is and what subjects will be asked to do. It doesn't cover all the details, but it covers enough for someone to understand generally what we're going for with this study. Under the research design and methodology section, we describe our research. First, we describe the research design in the methodology. With human subjects research, this focuses on what users will experience and in what order. It also covers some experimental details like how subjects might be assigned different experimental conditions. Then we describe the duration of subject participation to make sure subjects aren't being asked to do too much. Depending on what we're doing, we may need to provide data collection methods. This includes things like surveys, pre-tests and post-tests interview scripts, anything pre-prepared to elicit data for the participant. Then we also need to fully describe the potential benefits of the study. Remember, IRB is about making sure that the benefits out way the risks. If there are no benefits, then the benefits can't out way the risks. Benefits don't need to be to the individual participants though, but they could be to the greater community as a whole. Similarly, we also needed to describe the risks associated with the study. For usability studies, very often our risks are not going to be very significant. Our risks might be those associated with normal work at a computer. But we still need to address this to acknowledge that we thought about what risks might arise to participants. Then we describe the plan for the statistical analysis if we have one. Qualitative research might not have a statistical analysis plan, so that's why I've left this blank. Finally, we need to describe start and end dates of the research. Very often, this will break the research into a data collection phase and a research phase, where we actually analyze the data that we collected. Now we won't generally need to worry about many of the remaining options on this form, because we're not doing clinical studies and we generally don't have external funding unless you're working on a professor's research project. So now let's move on to subject details.
585
586196 - IRB Protocols: Human Subject Interaction
587Because we're interested in human-computer interaction, we almost certainly will have human-subject interaction. So when it asks, will the research involve direct interaction with human subjects, we would click, yes. That will bring us to a screen where we describe our subjects and the data we plan to collect from them. First, they want to know how many subjects we have and what genders. They want to make sure that we're not wasting participants' time if we're not going to actually analyze all their data. And that we're being fair to the different genders. A common problem in early research was over-representing male populations. Second, they'll want to know if we're targeting any vulnerable populations. People that might not have the capacity to give true informed consent. If we do, we need to make special accommodations to make sure they're fully aware of their rights as participants. Third, they want the scientific justification for the number of subjects to enroll in our study. Like I said, they want to make sure that we're not going to waste the time of a bunch off participants and then just throw their data out. That wouldn't be very respectful for our participants' time. If we're doing statistical tests this might be the number of participants necessary to find a certain effect size, which we'll talk about when we talk about quantitative research. If we're doing qualitative research, this is usually a smaller number and is more based on how many different perspectives we need to get a good picture of what we're trying to analyze. Alternatively, we might have external limits on our number of participants. For example, if you're doing classroom research, your maximum number of students is the maximum number of students in the class. Next, we state the inclusion and exclusion criterion. The inclusion criterion are, who we specifically including, who's our targeting audience? The exclusion criterion are those that we're specifically excluding. Often times, one of these will just be the inverse of the other, but there may be times when we need to be more specific. For example, if we were doing research on undergraduate computer science education, our inclusion criteria might be undergraduate students. But our exclusion criteria would be undergraduate students that have previously taken a computer science class. As before, we can skip the questions, for our purposes at least, that are more based on clinical research. But at the bottom, we need to provide the steps necessary to ensure additional protection of the rights and welfare of vulnerable populations. For example, if we're working with 10 year olds, how do we make sure 10 year olds really understand that they really do have the right to opt out of this research? We need to provide a plan for that here if we're working with a vulnerable population. Finally, we also need to describe our recruitment procedures. How are we going to find our subjects? First, we'll note what we'll say and how we'll communicate with them here. If we're using the Georgia Tech subject pool, which is a system for finding research subjects within the Georgia Tech student body, we'll indicate so here. And last, we'll note the kind of compensation we plan to provide the participants. Many times we won't compensate our participants at all. But if we're doing a bigger research study that actually has some external funding, it's pretty normal to give them some sort of monetary compensation for participation. It's we're using the George Tech subject pool, our compensation will often be extra credit in a certain class, very often a psychologist class. Note that the recruitment procedures are very important, especially if you're doing something like classroom research, where there can be a very significant perception of coercion to get people to participate. If I, as an instructor, am recruiting students in my own class to participate in my research project, I have to be very clear that it won't come back to haunt them if they choose not to participate.
588
589197 - IRB Protocols: Consent Procedures
590One of the most important elements of IRB approval is consent, that was one of the things created by the Belmont Report. If we're doing any interaction with our human subjects, we definitely need to think about consent procedures. On the consent information page, first, we need to indicate what kind of consent we'll receive. Most commonly, this will be written consent required. In this case, participants will sign or digitally sign, a consent form to start the study, but in some cases a waiver may be obtained. First, a waiver of consent can be obtained under certain, pretty narrow circumstances, this generally means we don't need to receive the subject's consent at all. Most of the time this only applies when subjects will not be directly affected by the research. So for example, if we wanted to study educational or health data that's already been generated and is already anonymized, we might receive a waiver of consent. Because those subjects won't be impacted by the fact we're now researching their data. Similarly, if we were to go sit in a coffee house and just take notes on the order taking process in a way that didn't identify anyone. We might receive a waiver of consent, because our observation is not affecting those people. We might also receive a waiver of documentation of consent. This occurs for low risk research, where the written consent itself, would be the only record of the participants identity. This applies to a lot of survey research or unrecorded interviews, where participants can be informed of their rights at the start, and their own continued participation constitutes continued implied consent. There's no reason to have them sign a consent form, because that consent form is the only reason we'd ever be able to identify them after the study. After selecting our option, we need to provide a justification, if we requested a waiver. If we didn't, then no justification is necessary. We'll then describe the plan for obtaining informed consent. Generally, this will be to provide the consent form to participants at the start of a study, and make it very clear that they can withdraw from the study at any time. If we're involving children, non english speakers or other at risk populations in our study, there may be some additional boxes to complete. It's also important for us to assess whether participants are continuing to consent to the study. Often times, we do this by making it very clear at the start of the study that they can withdraw at any time. So that their continued participation constitutes implied continued consent. Finally, it's also possible to have protocols where deception or concealment is proposed. In HCI, for example, we might want to tell participants that an interface is functioning even if someone behind the scenes is actually just making it look functional, so that we get good research data out of those participants. For example, if we were testing something like a new version of Siri, we might tell participants that it's functioning, when in reality someone is writing the responses by hand. If we're using deception or concealment like that, we'll indicate so here. Then finally, we need to upload our consent forms. At Georgia Tech the Office of Research Integrity Assurance provides consent form templates that we can tweak to match the specific needs of our study. The templates provide in depth directions on what to supply. Generally, this is where we disclose to participants the details of the rest of the protocol. What we're researching, why, how, and why they were invited to participate?
591
592198 - IRB Protocols: Wrapping Up
593Of the remaining fields the only one we're likely interested in is the data management questions. The majority of the others cover either clinical research or biological research or other things that we hopefully won't touch on very much in human computer interaction. Unless the field has changed a lot by the time you're listening to this. Nonetheless though you should actually peek into the items to make sure that they don't apply to you if you're filling out a protocol like this. Under the Data Management section, we'll want to describe how we keep participants data safe. That'll include descriptions of the way we store it and define information about participants. And how we'll safeguard the data itself through password protection or encryption or anything like that. Finally, there are always some questions that we answer for all studies even though they generally won't apply to us. Generally our studies won't involve the Department of Defense, generally they shouldn't involve Radiation. And one day I really kind of hope they involve Nanotechnology but we're probably not quite there yet. So we'd mark no that there is no DoD involvement. Finally, at the bottom, there's a place to upload some additional documents. This is where we would supply things like an interview script, a survey, a recruitment script and other documents that the IRB would want to see and approve. When we're done, we can click Save and Continue Application. On the next page, we can preview everything on one flat screen, and then check off at the end that we have no conflicts of interest, or report them, if we do. Then we'll click Save & Continue again. And for y'all, you would then submit it to your primary investigator. I am the primary investigator so I see something a little bit different here than what you would see. After submission, we'll generally hear back from IRB in about three weeks about whether the study was accepted and what changes need to be made if not.
594
595199 - Research Ethics and Industry
596Institutional review boards govern any research institutions that receive support from the federal government. But what about research that doesn't receive any federal support? Very often, companies will do research on their users. This is especially common in HCI. Lots of companies are constantly doing very interesting testing on their users with a lot of rapid AB experiments. There's a lot of potential knowledge there, but at the same time much of what they do likely would not pass IRB if it were university research. This actually came up recently with Facebook in a paper they published titled experimental evidence of massive-scale emotional contagion through social networks. Basically, Facebook wanted to see if they could predict what would make users happy or sad. And as a result they tweaked the news feed for some users to test out their ideas. In other words, they tried to manipulate their user's mood for experimental purposes. Now, Facebook argues that this was consistent with their own data use policy, which permits them to perform experiments like this. Some social scientists however would argue that this does not constitute informed consent. Informed consent they say is specific to a certain experiment, temporary for a known period of time and given without coercion. Some would argue that if you don't agree you can't use Facebook qualifies as coercion. These are some difficult issues and if you end up working in HCI industry, you'll likely find yourself wrestling with some of them.
597
598200 - Exercise: Research Ethics and Industry
599People are still discussing whether or not Facebook's study on its impact on users' moods was ethical. Facebook maintains that the study was consistent with its own data use policy, which constitutes informed consent. Opponents argue that it doesn't. What do you think? If you think that this was ethical, why do you think it was ethical? If you think that it was unethical, what could've made it ethical?
600
601201 - Exercise: Research Ethics and Industry Solution
602If you said yes, there are several reasons you might have stated. You might agree that because the terms of service covered it, it was technically ethical research. The users did agree to things like this. You may have actually read the article or read other publications about it and noted that Facebook actually has an internal IRB that reviews things like this. And in this case, an external IRB did review the study. If you said no, the reason you gave may have been that we know users are not aware of what's in terms of use. We have plenty of studies that indicate that users really don't spend any time reading what they're agreeing to. And while technically, it's true that they're still agreeing to it, what we're interested in here are participants' rights. If we know that users aren't reading what they're agreeing to, don't we have an ethical obligation to make sure they're aware before we go ahead with it. We also might say no because users couldn't opt out of this study. Part of that is because opting out of the study alone means deactivating your entire Facebook account or just stopping using the tool. But part of it is that users also weren't aware that a study was now going on. They couldn't opt out of the study specifically, nor could they even opt out of it by closing down their entire Facebook account because they didn't know when the study had started. That ties into the other issue. Users weren't notified that they were participants in an experiment. So even though they technically agreed to it when they agreed to Facebook's terms of service, one could argue the fact they weren't notified when the study was beginning and ending means that it wasn't ethical research. I'm not going to give you a right or wrong answer to this. There's a very interesting conversation to have about this. But what's most important here are the interesting questions that it brings up. Especially in regard to companies doing human subjects research that doesn't have any over sight from the federal government. If you agreed with these reasons why it wasn't ethical, what could they have done to fix it? Maybe they could have separated out the consent process for research studies from the rest of Facebook as a whole. Maybe they could have specifically requested that individual users opt-in, and alert them when the study was done, but not tell them what's actually being manipulated. And even if the original study was ethical, there were likely things that could have reduced the backlash. At the same time, those things might have affected the results. These are the tradeoffs that we deal with.
603
604202 - Data Inventory
605Before we start our need-finding exercises, we also want to enter with some understanding of the data we want to gather. These are the questions we ultimately want to answer. That's not to say we should be answering them every step of the way, but rather, we want to gather the data necessary to come to a conclusion at the end. Now, there are lots of inventories of the types of data you could gather, but here's one useful list. One, who are the users? What are their ages, genders, levels of expertise? Two, where are the users? What is there environment? Number three, what is the context of the task? What else is competing for users' attention? Four, what are their goals? What are they trying to accomplish? Five, right now, what do they need? What are the physical objects? What information do they need? What collaborators do they need? Six, what are their tasks? What are they doing physically, cognitively, socially? And seven, what are the subtasks? How do they accomplish those subtasks? When you're designing your need finding methods, each thing you do should match up with one or more of these questions.
606
607203 - The Problem Space
608In order to do some real need finding, the first thing we need to do is identify the problem space. Where is the task occurring, what else is going on, what are the user's explicit and implicit needs? We'll talk about some of the methods for doing that in this lesson, but before we get into those methods, we want to understand the scope of the space we're looking at. So consider the difference between these two actions. Notice that in each of these, I'm doing the same task, turning off the alarm. But in the first scene we're focusing very narrowly on the interaction between the user and the interface. In the latter, we're taking into consideration a broader view of the problem space. We could zoom out even further if we wanted to and ask questions about Where and why people need alarm systems in the first place. That might lead us to designing things like security systems for dorm rooms or checking systems for office buildings. As we're going about need finding, we want to make sure we're taking the broad approach. Understanding the entire problem space in which we're interested, not just focusing narrowly on the user's interaction with a particular interface. So in our exploration of methods for need finding, we're going to start with the most authentic types of general observation, then move through progressively more targeted types of need finding.
609
610204 - Naturalistic Observation
611For certain tasks, a great way for us to understand the users need is to simply watch. A great way for me to start understanding what it's like to need an audiobook app for exercising is to come somewhere where people are exercising and just watch them exercise. This is called naturalistic observation, observing people in their natural context. So I'm fortunate that I actually live across the street from a park, so I can sit here in my rocking chair on my porch and just watch people exercising. Now, I want to start with very specific observations and then generalize out to more abstract tasks. That way I'll observe something called confirmation bias which is basically when you see what you want to see, so what do I notice? Well, I notice that there's a lot of different types of exercisers. There are walkers, joggers, runners I see some rollerbladers, I see some people doing yoga. I see a lot of people riding bikes but the bikers seem to be broken into two different kinds of groups. I see a lot of people biking kind of leisurely but I also see some bikers who are a little bit more strenuous about it. I'm also noticing that while joggers might be able to stop and start pretty quickly, that's harder for someone riding a bike. So I might want to avoid designs that force the user to pull out their phone a lot because that's going to be dangerous and awkward for people riding bikes. Now I also see people exercising in groups and also people exercising individually. For those people exercising in groups, I don't actually know if they'd be interested in this. Listening to something might kind of defeat the purpose of exercising together. So I'm going to have to note that down as a question I want to ask people later. I also see that many people tend to stretch before and after exercising and I'm wondering if we can use that. Then we can have some kind of starting and ending sequence for this, so that a single session is kind of book ending by both stretching, and interacting with our app. Note that by just watching people engage in the task of exercising, I'm gathering an enormous amount of information that might affect my design. But note also, that while naturalistic observation is great, I'm limited ethically in what I can do. I can't interact with users directly and I can't capture identifying information like videos and photographs that's why I can't show you what I'm seeing out here. I'm also limited in that I don't know anything about what those users are thinking. I don't know if the people working out in groups would want to be able to listen to audiobooks while they're doing yoga. I don't know if bluetooth headsets would be problematic for people riding bike, I need to do a lot more before I get to the design phase. But this has been very informative in my understanding of the problem space and giving me things I can ask people later on.
612
613205 - Participant Observation
614Sometimes it's not just enough to watch people engaging in a task. Sometimes we want to experience a task for ourselves. So that's what I'm going to do. I listen to audiobooks a lot. I don't really exercise. I should, but I don't. But I'm going to try this out. So I've got my audiobook queued up, I've got my mic on so I can take notes as I run. So I'm going to go on a jog and see what I discover. So what did I learn? I learned that I'm out of shape for one thing. I already knew that but I learned it again. I also learned that this app would be very useful for anyone doing participant observation on exercisers. Because I kept having to stop to record notes for myself, which I could have done with this app that I'm trying to implement. But aside from that, I noticed that unexpected things happen pretty often that made me wish that I could easily go back in my book. Or sometimes there are just things I just wanted to hear again, but there was no easy way to do that. I also notice that there's definitely the need there for me. I already planned to listen to everything again now that I'm home because there were notes I wanted to take that I couldn't take easily. I also noticed that while sometimes I wanted to take notes, sometimes I also just want to leave a bookmark. Now we do have to be careful here though. Remember you are not your user. When you're working as a participant observer, you can avail useful insights, but you shouldn't over represent your own experiences. You should use this experience as a participant observer to inform what you ask users going forward
615
616206 - Hacks and Workarounds
617Let's zoom in a little bit more on what the user actually does or we can do naturalistic and participant observation without having to directly interact much with our users. We need to get inside users heads a little more to understand what they're thinking and doing. If you're trying to design interfaces to make existing tasks easier, one way to research that is to look at the hacks that users presently employ. How do they use interfaces in non-intended ways to accomplish tasks or how do they break out of the interface to accomplish a task that could have been accomplished with an interface? If you're designing a task meant to be performed at a desk like this, looking at the person's workspace can be a great way of accomplishing this. So for example, I have six monitors around. And yet, you still see Post-It notes on my computer. How could I possibly need more screen real estate? Well, Post-It notes can't be covered up. They don't take away from the existing screen real estate. They're visible even when the computer is off. So, this implicit notes here is the way to hack around the limitations of the computer interface. Now when you're looking at hacks, it's important to not just look at what the user does and assume you understand why. Look at their work around and ask them why they're using them. Find out why they don't just use the interface that's currently in place. You might find they just don't know about them, which presents a different kind of design challenge. Now hacks are related to another method we can use to uncover user needs as well, which are called errors. Whereas hacks are ways users get around the interface to accomplish their tasks, errors are slips or mistakes that users frequently make while performing the task within the interface.
618
619207 - Apprenticeship and Ethnography
620If we're designing interfaces for particularly complex tasks, we might quickly find out that just talking to our participants or observing them really isn't enough to get the understanding we need to design those interfaces. For particularly complex tasks, we might need to become experts ourselves in order to design those programs. This is informed by the domain of ethnography, which recommends researching a community or a job or anything like that, by becoming a participant in it. It goes beyond just participant observation though, it's really about integrating oneself into that area and becoming an expert in it and learning about it as you go. So we bring in our expertise and design in HCI and use that combined with the expertise that we develop to create new interfaces for those people. So for example, our video editors here at Udacity have an incredible incredibly complex workflow involving multiple programs, multiple workflows, lots of different people and lots of moving parts. There's no possible way I could ever sit down with someone for just an hour and get a good enough picture of what they do, to design a new interface that will help them out, I really need to train under them. I really need to become an expert at video editing and recording myself, in order to help them out. It's kind of like an apprenticeship approach. They would apprentice me in their field and I would use the knowledge that I gain to design new interfaces to help them out. So ethnography and apprenticeship are huge fields of research both on their own and as they apply to HCI. So if you're interested in using that approach take a look at some of the resources that we're providing.
621
622208 - Interviews and Focus Groups
623A most targeted way of gather information from users though is just to talk to them. One way of doing that might be to bring them in for an interview. So I'm sitting here with Morgan, who's one of the potential users for our audio book app targeted at exercisers. And we're especially interested in the kinds of task you perform while exercising and listening to audio books at the same time. So to start, what kind of challenges do you run into doing these two things at once? I think the biggest challenge is that it's hard to control it. I have headphones that have a button on them that can pause it and play. But if I want to do anything else I have to stop, pull up my phone and unlock it just to rewind. Yeah, that makes sense. Thank you. Interviews are useful ways to get at with the user is thinking when they're engaging in a task. You can do interviews one on one like this or you can even do interviews in a group with multiple users at the same time. Those tend to take on the form of focus groups, where a number of people are all talking together about some topic, and you can use them to tease out different kinds of information. Focus groups can elicit some information we don't get from this kind of an interview, but they also present the risk of overly convergent thinking. People tend to kind of agree with other instead of bringing in new ideas. So they should really be used in conjunction with interviews, as well as other need finding techniques.
624
625209 - Exercise: Interviews
626Interviews are likely to be one of the most common ways you gather data. So let's run through some good and bad interview questions real quick. So here are six questions. Which of these would make good interview questions? Mark the ones that would be good. For the ones that would be bad, briefly brainstorm a way to rewrite the question to make it better. You can go ahead and skip forward to the exercise if you don't want to listen to me read them out. Number one, do you exercise? Number two, how often do you exercise? Number three, do you exercise for health or for pleasure? Number four, what, if anything do you listen to while exercising? Number five, what device do you use to listen to something while exercising? Number six, we're developing an app for listening to audio books while exercising. Would that be interesting to you?
627
628210 - Exercise: Interviews Solution
629Personally, I think three of these are good questions. Do you exercise, is not a great question, because it's kind of a yes or no question. How often do you exercise, is actually the better way of asking the same question. It's subsumes all the answers to do you exercise, but leaves more room for elaboration or more room for detail. Do you exercise for health or for pleasure, is not a great question, because it presents to the user a dichotomy. It might not be the way they actually think about the problem. Maybe there's some other reason they exercise. Maybe they do it to be social, for example. We want to leave open all the possibilities a user might have. So instead of asking, do you exercise for health or for pleasure, we probably want to ask, why do you exercise? The next two questions work pretty well, because they leave plenty of room for the participant to have a wide range of answers, and they're not leading them towards any particular answer. We're not asking, for example, what smartphone do you use to listen to something, because maybe they don't use a smartphone. This sixth one is interesting. We're developing an app for listening to audiobooks while exercising. Would that be interesting to you? What's wrong with that question? When we say, we're developing an app, we introduce something called social desirability bias. Because we're the ones developing the app, the user is going to feel some pressure to agree with us, to support our ideas. People like to support one another. And so even if they wouldn't be interested, they'll likely say that they would, because that's the supportive thing to say. No one wants to say, hey, great idea, David, but I would never use it. So what we want to make sure to do is create no incentive for a user to not give us the complete, honest answer. Worrying about hurting our feelings is one reason why they wouldn't be totally honest. So we might reword this question just to say, would you be interested in an app for listening to audiobooks while exercising? Now granted, the fact that we're the ones asking still probably will tip off the user that we're probably thinking about moving in that direction, but at least it's going to be a little more collaborative. We're not tipping them off that we're already planning to do this, we're telling them that we might be thinking about doing it. And so if they don't think it's a good idea, they kind of feel like they should tell us right now, to save us time down the road. So by rephrasing the question that way, we hopefully, avoid biasing the participant to just agree with us to be nice.
630
631211 - Think-Aloud
632Think-aloud protocols are similar to interviews in that we're asking users to talk about their perceptions of the task. But with think-aloud, we're asking them to actually do so in the context of the task. So instead of bringing Morgan in to answer some questions about listening to audiobooks while exercising, I'll ask her to actually think out loud while listening to audiobooks and exercising. If this was a different task like something on a computer, I could have her just come into my lab and work on it. But since this is out in the world, what I might just do is give her a voice recorder to record her thoughts while she's out running and listening. Now think aloud is very useful, because it can help us get at users thoughts that they forget when they are no longer engaged in the task. But it's also a bit dangerous by asking people to think aloud about their task, we encourage them to think about it more deliberately and that can change the way they actually act. So while it's useful to get an understanding of what they are thinking, we should check to see if there are places where what they do differs when thinking out loud about it. We can do that with what's called a post-event protocol, which is largely the same, except we wait to get the user's thoughts until immediately after the activity. That way, the activity is still fresh in their minds, but the act of thinking about it shouldn't affect their performance quite as much.
633
634212 - Surveys
635Most of the other methods for need finding, like observation, interviewing, apprenticeship, require a significant amount of effort for what is often relatively little data. Or it's data from a small number of users. We might spend an entire hour interviewing a single possible user or an hour observing a small number of users in the world. The data we get from those interactions is deep and thorough, but sometimes, we also want broader data. Sometimes, we just want to know how many people encounter a certain difficulty or engage in a certain task. If we're designing an audio book app for exercisers, for example. Maybe we just want to know how often those people exercises or maybe we want to know what kind of books they listen to. At that point, a survey might be our more appropriate means of need finding. Surveys let us get a much larger number of responses very quickly and the questions can be phrased objectively, allowing for quicker interpretation. And plus, with the Internet, they can be administered asynchronously for at a pretty low cost. A few weeks ago, for example, I came up with the idea for a study on Friday morning. And with the great cooperation from our local IRB office, I was able to send out the survey to potential participants less than 24 hours later and receive 150 responses within a week. Now of course, the data I receive from that isn't nearly as thorough as what I would receive from interviewing some of those participants. But it's a powerful way of getting a larger amount of data. And it can be especially useful to decide what to ask participants during interviews or during focus groups.
636
637213 - Exercise: Surveys
638Writing survey questions is an art, as well as a science. So let's take a look at an intentionally poorly designed survey, and see everything we can find that's wrong with it. So on the left is a survey. It's kind of short, mostly because of screen real estate. Write down in the box on the right everything that is wrong with this survey. Feel free to skip forward if you don't want to listen to me read out the questions. On a scale of 1 to 4 with 1 meaning a lot and 4 meaning not at all, how much do you enjoy exercising? Why do you like to exercise? On a scale of 1 to 6 with 1 meaning not at all and 6 meaning a lot, how much do you like audiobooks? Have you listened to an audiobook this year?
639
640214 - Exercise: Surveys Solution
641Here are a few of the problems that I intentionally put into this survey. Some of them are kind of obvious, but hopefully a couple others were a little bit more subtle and a little bit more interesting. First when I say on a scale of one to four with one meaning a lot and four meaning not at all, what do two and three mean exactly? It's not a very clear scale to just say the endpoint. Just giving the endpoints doesn't give a very clear scale. We usually also want to provide an odd number of options, so that users have kind of a neutral central option. Sometimes we'll want to force our participants to take one side or the other, but generally we want to give them that middle neutral option. Either way though, we definitely don't want to change the number of options between those two questions. Having one be 1 to 4 and the other be 1 to 6 is just confusing. And even worse, notice that we're reversing the scale between these two. In the first question, the low number means a lot. In the second question, the high number means a lot. That's just terrible design. We want to be consistent across our entire survey, both with the direction of our scale and the number of options unless there's a compelling reason not to. The second question is also guilty of being quite a leading question. Why do you like to exercise assumes the participant likes to exercise. What are they supposed to say if they don't? And finally, the last question is a yes or no question. Have you listened to an audiobook this year? Yes or no. No is kind of an interesting answer, but yes, I don't know if you listened to one audiobook this year or a 100 audiobooks this year. I don't know if you listened every single day or if you just listened once because you had a gift certificate. So we want to reword this question to be a little more open-ended and support a wider range of participant answers.
642
643215 - Other Data Gathering Methods
644So far we've discussed some of the more common approaches that need finding. Depending on your domain though, there might be some other things you can do. First, if you're designing for a task for which interfaces already exist, you might start by critiquing the interfaces that already exist using some of the evaluation methods that we'll cover later in the evaluation lesson. For example, if you're wanting to design a new system for ordering takeout food, you might evaluate the interfaces of calling in an order, ordering via mobile phone or ordering via a website. Second and similarly, if you're trying to develop a tool to address a problem that people that are already addressing, you might go look at user reviews and see what people already like and dislike about existing products. For example, there are dozens of alarm clock apps out there, and thousands of reviews. If you want to design a new one, you could start there to find out what people need or what their common complaints are. Third, if you're working on a task that already involves a lot of automatic logging like web surfing, you could try to get some logs of user interaction that have already been generated. For example, say you wanted to build a browser that's better at anticipating what the user will want to open next. You could grab datalogs and look for trends both within and across users. You can creative with your data gathering methods. The goal is to use a variety of methods to paint a complete picture of the user's task.
645
646216 - Exercise: Needfinding Pros and Cons
647In this lesson we've covered a wide variety of different methods for need finding. Each method has its own disadvantages and advantages. So let's start to wrap up the lesson by exploring this with an exercise. Here are the methods we've covered, and here are the potential advantages. For each row, for each advantage, mark which need-finding method actually has that advantage. Note that these might be somewhat relative, so your answer may differ from ours. Go ahead and skip to the exercise if you don't want to listen to me read these out. The columns from left to right are Naturalistic Observation, Participant Observation, Errors and Hacks, Interviews, Surveys, Focus Groups, Apprenticeship, and Think-Aloud. The potential advantages are Analyzes data that already exists, Requires no recruitment, Requires no synchronous participation, Investigates the participant's thoughts, occurs within the task context, and cheaply gathers lots of users' data.
648
649217 - Exercise: Needfinding Pros and Cons Solution
650Here's my answer to this very complicated exercise. Two methods that analyze data that already exists are Naturalistic Observation and Errors and Hacks. Naturalistic Observation doesn't necessarily analyze data that already exists, but it analyzes data that's being produced already on its own without observing it, so we don't have to go out and create an opportunity for data to happen. We just have to observe it and capture it where it's already taking place. Errors and Hacks, look at the way users already use interfaces to see what errors they regularly make or when they have to work around the interface. The two methods that require no recruitment are Naturalistic Observation and Participant Observation. In both cases, we don't need other human participants to come do anything differently based on the fact that we're doing some research. With interviews, surveys, Focus Groups, apprenticeship and Think-Aloud, we're always asking users to do something to accommodate us or to give us some data. And with Errors and Hacks, even if we can view that data on our own, we still need the user to give us permission to view their workspace or watch them do whatever they're doing. There might be some times when you can look for Errors and Hacks with Naturalistic Observation, but generally you need to get enough into the users head to understand why something's an error or why they need to use a certain hack. For the most part, all of these are going to need some synchronous participation. There might be some exceptions. For example, we could do a retrospective analysis of Errors and Hacks, or we can have someone do a Think-Aloud protocol where they actually write down their thoughts after doing a task. But generally speaking, the way most of these are usually done, they require synchronous participation. Surveys are the exception. Surveys we usually send out to someone, wait some period of time, and get back the results. So we never have to be interacting live with any of our participants. That's one of the reasons why surveys can get a lot more data than other methods. Adding more participants doesn't necessarily require more of our time, at least not to gather the data in the first place. Analyzing it might require more time at the end, but that's not synchronous either. As far as investigating participant thoughts is concerned, almost all these methods can investigate this when used correctly. We could do a survey does not actually investigate participants thoughts, but a well designed survey is going to trying get a heart of the users thinks about things. The only exception is Naturalistic Observation where by definition, we're just watching people we're not interacting with them or we're not asking them what they are thinking. It's always extremely valuable for us to be able to do some needfinding that occurs within the task context itself. And unfortunately interviews and surveys, which are some of our most common data gathering methods, very often don't occur within the task context. Naturalistic Observation and Participant Observation obviously do, but since they don't involved getting inside the real users head, their contributions are a little bit more limited. Apprenticeship and Think-Aloud really capture the benefits of occurring within the task context, because either way we get the user's thoughts while they're engaging with the task, or immediately thereafter. It is possible to do interviews and Focus Groups within the task contexts as well, it just isn't quite as common. Errors and Hacks are certainly debatable as well, because the Errors and Hacks themselves definitely occur within the task context, but our analysis of them usually doesn't. And finally, as we talk about when we discuss cognitive task analysis, one of the challenges with needfinding is that most of our approaches are extremely expensive. If we want to gather a lot of data cheaply, then we probably need to rely on surveys. Everything else is either going to incur a pretty significant cost or it just isn't capable of gathering a lot of data. For example, we could cheaply be participant observations for weeks on end, but we're only ever going to gather data from one person and that's never ideal.
651
652218 - Design Challenge: Needfinding for Book Reading
653The needfinding exercises that we've gone through so far focus on the needs of the exercisers. What can they do with their hands, what is the environment around them like while exercising, and so on? However, that's only half the picture for this particular design. Our ultimate goal is to bring the experience of consuming books to people that exercise, which means we also need to understand the task of book-reading on its own. Now a problem space is still around exercisers, so we wouldn't go through the entire design life cycle for book reading on its own. We don't need to design or prototype anything for them. But if we're going to bring the full book reading experience to people while exercising, we need to understand what that is. So take a moment and design an approach to needfinding for people who are reading on their own.
654
655219 - Design Challenge: Needfinding for Book Reading Solution
656We could apply pretty much every single need-finding method that we've discussed to this task. We could, for example, go to the library and just watch people reading and see how they're taking notes. We've all likely done it ourselves. We can reflect on what we do while reading, although again, we need to be careful not to over-value our own priorities and approaches. Reading is common enough, that we can easily find participants for interviews, surveys, think alouds. The challenge here will be deciding who our users really are. Books are ubiquitous. Are we trying to cater to everyone who reads deliberately? If so, we need to sample a wide range of users or initially, we could choose a subset. We might cater to students who are studying or busy business people, or people that specifically walk or bike to work. We might start with one of those groups and then abstract out over time. We might eventually abstract all the way to just anyone who's unable to read and take notes the traditional way like people driving cars or people with visual impairments but that's further down the road. The more important thing is that we define who our user is, define the task in which we're interested, and deliberately design for that user and that task through out the design life cycle.
657
658220 - Iterative Needfinding
659We've noted that design is a life cycle from needfinding to brainstorming design alternatives to prototyping to evaluation. And then, back to needfinding to continue the cycle again. Needfinding on it's own though can be a cycle by itself. For example, we might use the results of our naturalistic observation to inform the questions we asked during our interviews. For example, imagine that we noticed that very many joggers, jog with only one earphone in. That's a naturalistic observation, and then in an interview, we might ask, why do some of you jog with only one earphone in? And we might get the answer from the interview that it's to listen for cars or listen for someone trying to get their attention because they exercise in a busy area. Now that we understand why they have that behavior, maybe we develop a survey to try and see how widespread that behavior is, and ask, how many of you need to worry about what's around you when you're listening while driving? If we notice in those surveys a significant split in the number of people who were concerned about that, that might inform our next round of naturalistic observation. We might go out and look and see in what environments are people only wearing one headphone and in what environments are they wearing both. So in that way all of the different kinds of need finding that we do can inform our next round of other kinds of need finding. We can go through entire cycles just of need finding without ever going on to our design alternatives or prototyping stages. However, the prototyping and evaluation that we do will then become another input into this. During our evaluation we might discover things that will then inform what we need to do next as far as need finding is concerned. Creating prototypes and evaluating them gives us data on what works and what doesn't. And that might inform what we want to observe to better understand the task going forward. That's the reason why the output of evaluation is more needfinding. It would be a mistake to do one initial needfinding stage, and then jump in to a back and forth cycle of prototyping and evaluation.
660
661221 - Revisiting the Inventory
662During these need-finding exercises, you'll have gathered an enormous amount of information about your users. Ideally, you've combined different sets of these approaches. You've observed people performing the tasks, you've asked them about their thought process, and you tried it some yourself. Pay special attention to some of the places where the data seem to conflict. Are these cases where you as the designer understand some elements of the task that the users don't? Or are these cases where your expertise hasn't quite developed to the point of understanding the task? Once you've gone through the data gathering process, it's time to revisit that inventory of things we wanted to gather initially. One, who are the users? Two, where are the users? Three, what is the context of the task? Four, what are their goals? Five, right now, what do they need? Six, what are their tasks? And seven, what are the subtasks? Revisit these, with the results of your data gathering in mind.
663
664222 - Defining the Requirements
665Finally, the final step for need-finding is to define our requirements. These are the requirements that our final interface must meet. They should be specific and evaluatable, and they can include some components that are outside of users tasks, as well, as defined by the project requirements. In terms of user tasks, we might have requirements for guarding functionality, what the interface can actually do, usability, how certain user interactions must work, learnability, how fast the user can start to use the interface, and accessibility, who can use the interface. We might also have some that are generated by external project requirements, like compatibility, what devices the interface can run on, compliance, how the interface protects user privacy, cost, how much the final tool can actually cost, and so on. We'll use these to evaluate the interfaces we develop, going forward.
666
667223 - Introduction to Design Alternatives
668. When we've developed a good understanding of the needs of our user, it's time to move on to the second phase of the design life cycle, design alternatives. This is when we start to brainstorm how to accomplish the task we've been investigating. The problem here is that design is very hard, it's hard for a number of reasons. The number of choices we have to make, and things we have to control is more expansive than ever before. Are we designing for desktops, laptops, tablets, smart phones, smart watches, augmented reality, virtual reality, 2D, 3D, gesture input, pen input, keyboard input, mouse input, voice input? In this lesson, we're going to talk about how to generate ideas for designs. And then we'll chat about how to explore those ideas a bit further to figure out what you want to actually pursue.
669
670224 - The Second Biggest Mistake
671The biggest mistake that a designer can make is jumping straight to designing an interface without understanding the users or understanding the task. The second biggest mistake though is settling on a single design idea or a single genre of design ideas too early. This can take on multiple forms. One form is staying too allegiant to existing designs or products. Take the thermostat, for example, again. If you settled on tweaking the existing design of a thermostat you would never invent the Nest. So if you're working on improving an existing interface, try to actually distance yourself from the existing solutions, at least initially during the brainstorming session. But this is also a problem if you're designing interfaces for new tasks as well. Imagine for instance, that while you were observing people exercising, you started sketching interface ideas like how to make the buttons big enough or what buttons need to be featured prominently. In doing so, you're getting tunnel vision and missing out on any design alternatives that might involve voice or gesture control. So the second biggest mistake you can make is focusing too strongly on one alternative from the very beginning, instead of exploring the entire range of possible design alternatives. The reason why this is such a common mistake, is that there's this natural tendency to think of it as a waste of time to develop interfaces you're not going to end up using. You think you can get it done faster just by picking one early on and sticking to it. But flushing out ideas for interfaces you don't end up using isn't a waste of time, because by doing so you continue to learn more about the problem. The experience of exploring those ideas that you leave behind will make you a better designer for the ideas that you do choose to pursue. In all likelihood your ultimate design will be some combination of the design alternatives that you explored earlier. So, take my security system for an example. There are two ways of interacting with it, the key pad and the key chain. Two different designs that, in this particular instance, integrated just fine. Different alternatives won't always integrate side by side this easily, but the design process as a whole is an iterative process of brainstorming, combining, abandoning, revising and improving your ideas, and that requires you start with several ideas in the first place.
672
673225 - The Design Space
674When we talk about the problem we're solving here we define the problem space as disabling a security system as we enter a home. We defined our problem as far as possible away from the current interfaces for doing it. The design space on the other hand is the area in which we design our solutions to this problem. The current design space for this problem is wall mounted devices and portable devices like my key chain. But as we design, the space of possible ideas might expand. For example, as we go along we might be interested in voice interfaces or interfaces with our mobile phones or wearable devices. Our goal during the design alternative phase is to explore the possible design space. We don't want to narrow down too early by sticking devices on walls or devices on keychains. We want to brainstorm lots of possible approaches, and grow a large space of possible designs.
675
676226 - 5 Tips: Individual Brainstorming
677Here are five quick tips for effective individual brain storming. Number one, write down the core problem. Keep this visible. You want to let your mind enter a divergent thinking mode but you also want to remain grounded in the problem. Writing down the problem and keeping it available will help you remain focused while remaining creative. Number two. Constrain yourself. Decide you want at least on idea in a number of different categories. Personally, I try to make sure I have at least three ideas that use nontraditional interaction methods, like touch and voice. You can constrain yourself in strange ways too. Force yourself to think of solutions that are too expensive or not physically possible. The act of thinking in these directions will help you out later. Number three. Aim for 20. Don't stop until you have twenty ideas. These ideas don't have to be very well-formed or complex, they can be simply one sentence descriptions of designs you might pursue. This forces you to think through the problem, rather than getting tunnel vision on an early idea. Number 4. Take a break. You don't need to come up with all of these at once and, in fact, you'll probably find it's easier if you leave and come back. I'm not just talking about a ten minute break either. Stop brainstorming and decide to continue a couple days later but be ready to write down new ideas that come to you. Number 5. Divide and conquer. If you're dealing with a problem like helping kids lead healthier lifestyles, divide it into smaller problems and brainstorm solutions to those. If we're designing audio books for exercises, for example, we might divide it into things like the ability to take and review notes, or the ability to control playback hands-free. Divide it like that and brainstorm solutions to each individual little problem.
678
679227 - Challenges in Group Brainstorming
680Group brain storming presents some significant issues. Thompson in 2008 laid out four behaviors in group brainstorming that can block progress. The first is social loafing. People often don't tend to work as hard in groups as they would individually. It's easy to feel like the responsibility for unproductive brainstorming is shared and deflected. In individual brainstorming, it's clearly on the individual. The second blocker is conformity, people in groups tend to want to agree. Studies have shown that group brainstorming leads to convergent thinking. The conversation the group has tends to force participants down the same line of thinking, generating fewer and less varied ideas than the individuals acting alone. During brainstorming, though, the goal is diversion thinking, lots of ideas, lots of creativity. The third blocker is production blocking. In group brainstorming, there are often individuals who dominate the conversation and make it difficult for others to actually be heard. Their ideas can thus command more weight, not because of the strength of the ideas, but because of the volume of the description. The fourth blocker is performance matching. People tend to converge in terms of passion and performance, which can lead to a loss of momentum over time. That might be able to get people excited if they're around other excited people initially, but more often than not, it saps the energy of those who enter with enthusiasm. In addition to these four challenges, I would add a fifth. Group brainstorming may also be prone to power dynamics, or biases. No matter how supportive and collaborative a boss might be, there'll likely always exist a tacit pressure to build on her suggestions, which dampens creative brainstorming. There also exists considerable literature stating that other biases based on gender, age, race, complain to these group sessions as well. Now note that this doesn't mean group brainstorming should be avoided altogether. What it means is that we should enter into group brainstorming with strong ideas of how to address these issues, ideally, after a phase of individual brainstorming has already occurred.
681
682228 - Rules for Group Brainstorming
683To have an effective group brainstorming session, we need to have some rules to govern the individual's behavior to address those common challenges. In 1957, Osbourne outline four such rules. Number one, Expressiveness. Any idea that comes to mind, share it out loud, no matter how strange. Number two, nonevaluation. No criticizing ideas, no evaluating the ideas themselves yet. Number three, quantity. Brainstorming as many as possible. The more you have, the greater your idea of finding a novel idea. Number four, building. While you shouldn't criticize other's ideas, you should absolutely try to build on them. Then, in 1996, Oxley, Dzindolet and Paulus presented four additional rules. Number one, stay focused. Keep the goal in mind at all times. Number two, no explaining ideas. Say the idea and move on. No justifying ideas. Number three, when you hit a roadblock, revisit the problem. Say it again out loud. Number four, encourage others. If someone isn't speaking up, encourage them to do so. Note that all eight of these rules prescribe what individuals should do, but they're only effective if every individual does them. So it's good to cover these rules, post them publicly, and call one another on breaking from them.
684
685229 - Fleshing Out Ideas
686The brainstorming process should lead you to a list of bunch of high level general design alternatives. These are likely just a few words or a sentence each but they described some very general idea of how you might design the interface, to accomplish this task. Your next step is to try to flush these ideas out into three or four ideas that are worth taking forward to the prototyping stage. Some of the ideas you might be able to dismiss pretty quickly, that's all right. You can't generate good ideas without generating a lot of ideas. Even though you won't end up using all of them. In other places, you might explore an idea a little before dismissing it or you might combine two ideas into a new idea. In the rest of this lesson, we'll give you some thought experiments you can use to evaluate these ideas and decide what to keep, what to combine and what to dismiss.
687
688230 - Personas
689The first common method we can use to flush out design alternatives is called personas. With personas we create actual characters to represent our users. So let's create a persona for the problem of helping exercisers take notes while reading books. We'll start by giving her a name and a face, and then we'll fill out some details. We want to understand who this persona is. We want to be able to mentally simulate her. We want to be able to say, what would Anika do in this situation? What is she thinking when she's about to go exercise? What kind of things might interrupt her? We might want to put in some more domain specific information as well. Like, why does this person exercise? When do they exercise? What kind of books do they like? How are they feeling when they're exercising? Where do they usually exercise? We want to create at least three or four of these different personas, and perhaps more depending on how many different stakeholders we have for our problem. The important thing is that these should be pretty different people, representing different elements of our designs, different elements of our task, so we can explore its entire range. We don't want to design just for Anika, but we do want to design for real people. And so we should define personas that represent the range of real people that we care about. That way we can ask our questions like, how would Janet feel about this design alternative? Using this, we can start to extort the space and find the options that has the most appeal.
690
691231 - User Profiles
692Personas are meant to give us a small number of characters that we can reason about empatheticly. However, it can sometimes also be useful to formulaicly generate a large number of user profiles to explore the full design space. We can do this by defining a number of different variable about our users and the possibilities within each. So here our few examples, we can ask ourselves, do we care about novice users or expert users or both? Do we care about users that read casually, that read seriously, or both kinds of users? Do we only want to cater to users that are highly motivated to use our app, which can make things a little bit easier on us? Or do we want to assume that it won't take much to stop them from using our app? Can we assume a pretty high-level of technological literacy, or are we trying to cater to more casual users as well? And are we interested in users that are going to use our app all the time, or in users who are going to use our app only occasionally, or both? All of these decisions present some interesting design considerations that we need to keep in mind. For example, for users that are going to use our tool very often, our major consideration is efficiency. We want to make sure they can do what they need to do as quickly as possible. And oftentimes, that might be relying on them to know more about how to use the app. But if we're designing for users that use our app pretty rarely, we need to make sure to keep all the interactions discoverable and visible. That way every time they come back to the app, it's like the first time they came back to it. They don't need to remember anything from the previous time because we don't know how long it's been since the last time they've used it. If we want to design for both, then we have our work cut out for us. We need to either design very efficient interaction methods that nonetheless are discoverable and visible, or we need to design two sets of interaction methods. One way that's very discoverable and visible, and one way that's very efficient. We see this with our example of the hotkeys for copy and paste. If you don't know how to use them, you have a way of finding them. So it caters to either novice users or users who haven't used the program in awhile. But because you can also do it with simple hotkeys, it caters to those users who use it more frequently and makes it more efficient for those who are going to be doing it a lot. In deciding what to design, we need to understand what groups, what profiles we're designing for, and use that to inform our design decisions. Inexperienced designers often make big mistakes here. They either try to design for everybody, which rarely works, or they design with no one in particular in mind. And so, certain areas of program are good for some users, others are good for other types of users. An entire program as a whole is not good for any particular type of user. So it's very important that we understand the range of users that we're designing for, and that we make sure the range is actually something that we feasibly can design for.
693
694232 - Timelines
695Building on the idea of a persona we can take that person and stretch her out over time and see what is she thinking, what is she doing at various stages of interacting with our interface or interacting with the task at hand. I've also heard this called journey maps although journey maps usually cover much longer periods of time. They cover the entire expanse of the persons life, why they are interested in something and where they are going from here. Timelines can be more narrowed to the specific time which users are interacting with the task or with the program. So our goal is to take that persona and stretched it out overtime. So for our example, what sparks Anika to decide to exercise in the first place? That might be really useful information to know. After she decided to exercise, what did she do next? In theory she doesn't just start right there. She goes exercise somewhere she has kind of setup process. Then what does she do? In this case, maybe she set ups her audiobooks as she actually pushes play, puts her headphones in, and so on. And then there's probably a period of actual exercise in our example, and then at the end, she turns off the audiobook. The usefulness of drawing this as a timeline is it starts to let us ask some pretty interesting questions. What prompts this person to actually engage in the task in the first place? What actions lead up to the task? How are they feeling at every stage of the task? And can we use that? How would each design alternative impact their experience throughout this process? For example, if our persona for Anika was that she really doesn't like to exercise but she knows she really needs to, then we know her mood during this phase might be kind of glum. We need to design our app with the understanding that she might have kind of low motivation to engage in this at all. If our app is a little bit frustrating to use, then it might turn her off of exercising all together. On the other hand, if Anika really likes to exercise, then maybe she's in a very good mood during this phase. And if she likes exercising on its own, maybe she forgets to even set up the audio book at all. So then we need to design our app with that in mind. We need to design it such that there's something built into it that could maybe remind her that when she gets to a certain location, she meant to start her audio book. So stretching this out as a timeline lets us explore not only who the user is, but also what they're thinking and what they're feeling. And how what we design can integrate with a task that they're participating in. Exploring our different design alternatives in this way allows us to start to gauge which designs might have the greatest potential to positively impact the user's experience. And they also let us explore what might be different between different users. Our design might need to be different for Anika who loves to exercise, and Paul who hates exercising. This timeline let's us start to explore those more personal elements.
696
697233 - User Modeling
698In our unit on principles, we talk about task analysis, including things like cognitive task analysis or human information processor models. Performing those analysis as part of our need finding also gives us a nice tool for exploring our design alternatives. Using this, we can start to look at how exactly the goals, operators, methods, and selection rules of the Gomes model map up to the ideas of our design alternatives. How does the user achieve each of their goals in each interface? How relatively easy are the goals to achieve between the different design alternatives? With the results of our cognitive task analysis, we can start to ask some deeper questions about what the user is keeping in mind as well. Given what we know about things competing for our user's attention, what are the likelihoods that each interface will work? In some ways, this is a similar process to using personas we outlined earlier, but with a subtle difference. Personas are personal and meant to give us an empathetic view of the user experience. User models are more objective and meant to give us a measurable and comparable view of the user experience. So ideally, the result of this kind of analysis is we would be able to say that the different alternatives have these different phases and these different phases have different efficiencies or different speeds associated with them. So, we could start to say exactly how efficient one design is compared to another.
699
700234 - Exercise: Design Alternatives Pros and Cons
701In this lesson we've covered several different ways of developing design alternatives. Each method has its advantages and disadvantages. So, let's start rap the lesson up by exploring this with an exercise. Here are the methods that we've covered and here are some other potential advantages. For each row, mark which of the different methods possesses that advantage. Note that these might be somewhat relative, so your answer might differ from ours and that's perfectly fine.
702
703235 - Exercise: Design Alternatives Pros and Cons Solution
704So personally here's my answer. For me scenarios are really the only ones that include the entire task context. You can make the case that personas and timelines do as well, but I tend to think that these are a little bit too separated from the task to really include the context. Personas and user profiles, on the other hand, do include the users context. They include plenty of information about who the user is, why they're doing this task, and what their motivations are. You could make the argument as well, that scenarios and timelines include the user's context. Because the way we describe them, they're instances of the personas being stretched out over a scenario or over time. User profile probably do the cleanest job of delineating the target audience. With our personas we have kind of a fuzzy idea of who are different users are. But our user profiles really formally articulate the space of your users in which we're interested. As far as general workflows that's what user modeling is really good at. It really outlines the phases or steps or operators that users use in a general sense. You could say the same thing about timelines to a certain extent although timelines are more focused on what the user is thinking and feeling and less on their actual workflow with regard to the task. As far as capturing activity over time, scenarios, timelines, and user modeling all have an element of time in what they analyze. And possibly one of the bigger benefits of using scenarios is they allow us to capture potential edge cases more easily. Timelines, user models, user profiles and personas are all about the general user or the general routine interaction with the task. But scenarios let us pose interesting and novel situations so that we can kind of mentally simulate how our different design alternatives will work with that scenario. For example, we wouldn't say that a fire engine going by Morgan, which is listening to an audiobook, is a routine thing, so it probably wouldn't come up in our timeline or in our user modeling. But we can develop a scenario that explores how is she going to deal with that particular event. And while it might seem a little silly to focus so much on edge cases, as we do more and more design, we start to discover that there are a lot of edge cases. They're all different. But a lot of our time is spent dealing with those unique circumstances that fall pretty far outside the routine interaction with the program.
705
706236 - Exploring Ideas
707So let's apply these techniques to some of the ideas that I came up with earlier. The first thing I might do is go ahead and rule out any of the ideas that are just technologically unfeasible. Coming up with those wasn't a waste of time because they're part of a nice broad free flow brainstorming process. But skin based interfaces and augmented reality, probably are not on the table for the immediate future. I might also rule out the options that are unfeasible for some more practical reasons. We might a small team of developers, for example. So, a dedicated wearable device isn't really our expertise. Now the one I might do next is create some timelines, covering a sequence of events in exercising to use to explore these alternatives further. I might notice that the users I observed and talked with, valued efficiency in getting started. They don't want to have to walk through a complex set up process every time they start to exercise. I might also use my user persona's to explore the cognitive load of the users in these different alternatives. They have a lot going on, between monitoring their exercise progress, observing their environment, and listening to the book. So, I'm going to want to keep cognitive load very low. Now granted, we always want to keep cognitive load pretty low, but in this case, the competing tasks are significant enough, that I want to sacrifice features for simplicity, if it keeps that cognitive load pretty manageable. Now based on these timelines and these personas, I would probably end up here with three design alternatives that I want to explore. One is a traditional touch interface, a smartphone app. Then unfortunately it means the user is going to have to pull out their phone whenever they want to take a note. But if I can design it well enough that might not be an issue. I also know that approach gets me a lot of flexibility so it's good to at least explore it. A second approach is gestural interfaces. I know that people aren't usually holding their device while exercising. So it would be great if they had someway of interacting without pulling out their phone. Gestures might let us do that. Now in our gesture recognition is in its infancy, but we might be able delivered smart watched technology or something like a Fitbit to support interaction via gestures. A third approach is a voice interface, I know people generally aren't communicating verbally while exercising, so why not a voice interface? That can even double as the note taking interface. So now that I have three design alternatives that I'm interested in exploring, I would move on to the prototyping stage which is building some version of these that I can test with real users.
708
709237 - Introduction to Prototyping
710This is the prototyping stage. Like brainstorming design alternatives, this involves looking at the different ideas available to us and developing them a bit. But the major distinction is that in prototyping, we want to actually build things we can put in front of users. But that doesn't mean building the entire interface before we ever even have a user look at it. We want to get user feedback as quickly and rapidly as possible. And build up more sophisticated prototypes over time as we go through the design life cycle. So we'll start with low fidelity prototypes, things that can be assembled and revised very quickly for rapid feedback from users. Then we'll work our way towards higher fidelity prototypes, like wire frames or working versions of our interface.
711
712238 - Basics of Prototyping
713To discuss prototyping there are a variety of different terms and concepts we need to understand. For the most part, these will apply to where in the prototyping timeline those concepts are used. In the early prototyping, we're doing a very rapid revision on preliminary ideas. This happens on our first few iterations through the design lifecycle. In late prototyping, we're putting the finishing touches on the final design, or revising a design that's already live. This happens when we've already been through several iterations of our design lifecycle. At the various phases, we'll generally use different types of prototypes in evaluations. Now, note that everything I'm about to say is pretty general, there will be lots of exceptions. The first concept is representation, what is the prototype? Early on, we might be fine with just some textural descriptions or some simple visuals that we've written up on a piece of paper. Later on though, we'll want to make things more visual and maybe even more interactive. We only want to put the work into developing the more complex type of prototypes once we vetted the ideas with prototypes that are easier to build. So in a lot of ways, this is a spectrum of how easy prototypes are to build over time. A verbal prototype is literally just a description, and I can change my description on the fly. A paper prototype is drawn on paper, and similarly, I could ball up the paper, throw it away, and draw a new version pretty quickly. But things like actual functional prototypes that really work, those take a good bit of time. And so we only want to do those once we've already vetted that the ideas that we're going to build actually have some value. You don't want to sink lots of months and lots of engineering resources into building something that actually works. Only to find out there's some feedback you could have gotten just based on a drawing on a piece of paper that would have told you that your idea wasn't a very good one. This brings us to our second concept, which is fidelity. Fidelity refers to the completeness or the maturity of the prototype. A low-fidelity prototype would be something like paper or simple drawings, very easy to change. A high-fidelity prototype would be something like a wireframe or an actual functional working interface, something that was harder to put together. We want to move from easily changeable low-fidelity prototypes to explore our ideas, to higher-fidelity prototypes to really test them out. Note that fidelity and representation are pretty closely related, low-fidelity is really about a prototype that's pretty far from being complete. And the same thing is true for some of our early methods of prototyping. They describe different ideas, but they very heavily correlate what kinds of representations you're going to use for different levels of fidelity. Now these different kinds of prototypes also lend themselves to different kinds of evaluation structures. Low fidelity prototypes can fine for evaluating the relative function of an interface, whether or not it can do what's it's designed to do. If a user looks at the interface can they figure out what they're supposed to press? You can prototype that was just a drawing on a piece of paper, as opposed to a real functional prototype. Things like wireframes can be useful in evaluating the relative readability of the interface as well. However, to evaluate actual performance, like how long certain tasks take, or what design leads to more purchases. We generally need a higher fidelity prototype, through more iterations of the design lifecycle. So early on, we're really just evaluating whether or not our prototype even has the potential to do what we want it to do. Can a user physically use it? Can they identify what button to press and when? For that we need additional detail like font size and real screen layout. We need a real prototype that looks the way the final interface will look, even if it doesn't work quite yet. And then, to evaluate performance we really need a prototype that's working, or close to working, to evaluate certain tasks. And then the final concept we need to understand, is the scope of the interface. Is it a horizontal prototype or a vertical prototype? Horizontal prototypes cover the design as a whole, but in a more shallow way. Vertical prototypes take a small portion of the interaction and prototype it in great detail. So for example, if we were designing Facebook, we might have a vertical prototype specifically for the status-posting screen and a horizontal prototype for the site in general. Now, in my experience, we usually start with horizontal prototypes earlier on, and move toward the deeper vertical prototype later. But in reality, you'll likely move back and forth among these more frequently throughout you iterations through the design lifecycle. So, these are four the main concepts behind prototyping. There are other questions we might ask ourselves as well. Like whether we're prototyping iterative or revolutionary changes, and the extent to which the prototype needs to be executable. But in many ways, those fall under these previous concepts.
714
715239 - Exercise: Prototyping Pros and Cons
716In this lesson we've covered various different methods for prototyping. Each method has its advantages and disadvantages. So let's start to wrap up the lesson by exploring this with another exercise. Here are the methods that we've covered and here are some of the potential advantages. For each row, mark the column to which that advantage applies. Note that as always, these are somewhat relative, so your answer might differ from ours.
717
718240 - Exercise: Prototyping Pros and Cons Solution
719So here are my answers. First when we're talking about things that are revisable during interaction, we're talking about things that I as the experimenter can get feedback from my user and immediately change my prototype. So if they say that that button label doesn't really makes sense, I can cross out that button label and immediately change it. That makes sense for prototypes that are very low fidelity. Verbal prototypes, I can immediately say okay, then let's make it the way you just described. Paper prototypes or card prototypes, I could quickly erase or cross out something on my prototype and change it. Wizard of Oz is similar. Since I'm running what's going on behind the scenes, I can just change the way I'm running it. Those four prototypes, because they're more low fidelity, also disguises superficial details. No one is going to look at a prototype that I drew by hand and say they don't like the font. No one is going to to listen to me run a Wizard of Oz prototype for a voice interface and say, I don't like the voice that you're using. These help us focus on the overall patterns of interaction and disguise some of the superficial elements that users would often have a tendency to get distracted by. However, as we prototype, we need to move from designing interfaces to designing interactions. Verbal prototypes and paper prototypes don't really cover interactions, they cover showing something and asking the user what they think, but they don't really go further than that. Card prototypes, Wizard of Oz prototypes, to a certain extent wireframing and to a certain extent physical prototypes all let us actually simulate the user interaction. With a card prototype, we're actually saying if you did that, then you would see this, so they can walk through the pattern of interaction. Wizard of Oz, we can simply call out or describe or simulate, this is what would happen if you do what you just described. Now, wifeframing you could do more like a paper prototype, where it's just a simple wire frame, but more generally, we use wire frames when we're ready to actually show different interfaces and the movement between them. Similarly with physical prototypes, the main reason why we would do a physical prototype is to hand a user, and say, pretend you're jogging, or pretend you're working in your office. How would this interact with what you're actually doing? We're simulating the way they would physically use it. Now among all of these, the wires frames are really the ones that are most easily distributable to remote users. You can make an argument that we can send scans for a paper prototypes but generally, a paper prototype isn't just about what's on paper. It's also about the conversations and descriptions that we're having around it and asking users what they think about certain elements. Whereas a wire frame is more about a general impression that users get. You can make the argument that paper prototypes can be sent easily, as well. But for me, I would only share wire frames with remote users. Now prototyping look and feel is really just the inverse of disguise and superficial details. Look and feel is really about those superficial elements that have a significant user impact, but are more easily modifiable within an overall pattern of functional interaction. So just as the earlier low fidelity prototypes support disguising details, the later ones support prototyping look and feel. As computers become more ubiquitous, and users are moving around while interacting with interfaces more and more, allowing mobility is really valuable. Wizard of Oz, since we're just calling things out to the user, let them move around, and same with physical prototypes. We can actually hand them to a user and have them physically interact, the way they would with the actual interface
720
721241 - Design Life Cycle Revisited
722At this point, there's a risk of a major misconception that we should cut off right now. We started with need finding, then develop some design alternatives, and now we're prototyping. We've talked about how prototyping follows a timeline to low fidelity to high fidelity prototypes, from early to late prototyping. We might think that we move on to evaluation when we're done prototyping. That's not the way the design life cycle works though. We go through this cycle several times for a single design and a single prototype corresponds to a single iteration through the cycle. So we did some initial needfinding, we brainstormed some alternatives, and we prototyped those alternatives on paper. We don't jump straight from doing them on paper to doing them via wire framing or doing a functional prototype. We take those prototypes and we use them for evaluation. We evaluate those paper prototypes with real people. The results of that evaluation tell us if we need to go back and understand the task even better. Those results help us reflect on our alternatives as a whole, maybe come up with some new ones. Then, equipped with the results of that evaluation, that additional needfinding, and that additional brainstorming, we return to the prototyping phase. If our prototype seemed to be pretty successful and pretty sound, then maybe it's time to raise the fidelity of it. Maybe we take it from a paper prototype and actually do some wire frames, or do a car prototype around the actual interaction. If it wasn't very successful though, when we reach back here, we're going to do a different paper prototype, or a different low fidelity prototype, and then go to evaluation again. Each time we develop a new prototype we go through the same cycle again. Now that might sound extremely slow and deliberate but we also go through this on a very different time scales too. So for example, after we've gone through needfinding and designing alternative brainstorming, we can develop a paper prototype. We give it to a user and get their evaluation. They say that they don't like it. We ask them why, we ask them to describe what about their task isn't supported by that interface. That's in some ways another needfinding stage. Then we brainstorm real quick how we could resolve that. Maybe we just do that while we're sitting with that user and think it didn't support this element of what they described, but I could add that pretty quickly just by making this button or this function more visible. Now we very quickly have a new prototyping just by sketching out that addition to that paper prototype and now we can do it again. This cycle could take one minute. We could take one prototype, put it in front of a user, get their evaluation, figure out what they liked and didn't like, brainstorm a way to fix that, and then immediately revise it and try it again. We can go through this very, very quickly. We could also go through this very slowly, we could have prototypes that take months to develop. And generally that's why we only want to do that after we've gone through the cycle a few times. Because if we're going to take months to develop a prototype, we want to make sure we're probably going to get some pretty good evaluations on it. And we can make sure of that by prototyping the elements in lower fidelity first.
723
724242 - Multi-Level Prototyping
725There's one other misconception that I've seen in some designers I've worked with that I feel is also worth explicitly acknowledging. All your prototypes don't have to be at the same level, at the same time. Take Facebook for example. Facebook is a complete app already implemented. Imagine that Facebook wanted to redesign their status update box, which they've done pretty recently and have probably done since I recorded this. Just because the interface is complete in other ways doesn't mean that all future prototyping efforts need to be similarly high fidelity. They don't need to implement an entire new status composition screen just to prototype it. They can prototype it in lower fidelity with sketches, or wire frames, put that in front of users, get their feedback, before ever actually implementing it into a functional prototype or a working part of the website. This applies particularly strongly to the design of apps or programs with multiple functions. So take something like the LinkedIn app. It has a number of different functions like editing your own profile, or connecting with others, or browsing your news feed. Each of these individual screens has its own tasks and interactions. And moving amongst them, is itself a task or a type of interaction. Trying to design all the screens and the transitions among them all at the same time is likely far too much. So we could take the bottom-up approach, where we would design the individual screens first, and then design the app experience as a whole. Or we might take the top-down approach and design the overall experience of moving between these different screens, and then design the contents of the individual screens. The point of this is that at any time, protoyping can and should exist at multiple levels of fidelity.
726
727243 - Introduction to Evaluation
728The heart of user-centered design is getting frequent feedback from the users. That's where evaluation comes into play. Evaluation is where we take what we've designed and put it in front of users to get their feedback. But just as different prototypes serve different functions at different stages of the design process, so also our methods for evaluation need to match as well. Early on, we want more qualitative feedback. We want to know what they like, what they don't like, whether it's readable, whether it's understandable. Later on, we want to know if it's usable. Does it actually minimize your workload? Is it intuitive? Is it easy to learn? Then at the end, we might want to know something more quantitative. We might want to actually measure, for example, whether the time to complete a task has changed, or whether the number of sales has increased. Along the way, we might also want to iterate even more quickly by predicting what the results of user evaluation will be. The type of evaluation we employ is tightly related to where we are in our design process. So in this lesson, we'll discuss the different methods for performing evaluation to get the feedback we need when we need it.
729
730244 - Three Types of Evaluation
731There are a lot of ways to evaluate interfaces. So to organize our discussion of evaluation, I've broken these into three categories. The first is qualitative evaluation. This is where we want to get qualitative feedback from users. What do they like, what do they dislike, what's easy, what's hard. We'll get that information through some methods very similar, in fact identical, to our methods for need finding. The second is empirical evaluation. This is where we actually want to do some controlled experiments and evaluate the results quantitatively. For that, we need many more participants, and we also want to make sure we addressed the big qualitative feedback first. The third is predictive evaluation. Predictive evaluation is specifically evaluation without users. In user centered design, this is obviously not our favorite kind of evaluation. Evaluation with real users though is oftentimes slow and its really expensive. So it's useful for us to have ways we can do some simple evaluation on a day to day basis. So we'll structure our discussion of evaluation around these three general categories.
732
733245 - Evaluation Timeline
734When we discussed prototyping, we talked about how over time the nature of our prototypes get higher and higher fidelity. Something similar happens with evaluation. Over time, the evaluation method we'll use will change. Throughout most of our design process our evaluations are formative. Meaning their primary purpose is to help us redesign and improve our interface. At the end, though, we might want to do something more summative to conclude the design process, especially if we want to demonstrate that the new interface is better. Formative evaluation is evaluation with the intention of improving the interface going forward. Summative is with the intention of conclusively saying at the end what the difference was. In reality, hopefully we never do summative evaluation. Hopefully our evaluations are always with the purpose of revising our interface and making it better over time. But in practice, there might come times when you need to demonstrate a very clear quantitative difference. And because of this difference, our early evaluations tend to be more qualitative. Qualitative evaluations tend to be more interpretative and informal. Their goal is to help us improve or understand the task. Our later evaluations are likely more empirical, controlled, and formal. Their goal is to demonstrate or assess change. So while formative evaluation and summative evaluation were the purposes of our evaluations, qualitative evaluations and empirical evaluations are ways to actually fulfill those purposes. Predictive evaluation is a little outside the spectrum, so we'll talk about that as well. As far as this is concerned, predictive evaluations tend to be very similar to qualitative evaluations. They inform how we revise and improve our interfaces over time. These three categories actually form the bulk of what we'll talk about in this lesson. Recall also that earlier we talked about the difference between qualitative and quantitative data. As you've probably realized, if qualitative evaluation occurs early, an empirical evaluation occurs late. And chances are, we're using qualitative data more early, and quantitative data more late. In reality, qualitative data is really always useful to improve our interfaces, whereas quantitative data, while always useful, really can only arise when we have pretty rigorous evaluations. And then one last area we can look at is where the evaluation takes place. In a controlled lab setting or actually out in the field. Generally when we're testing our early low fidelity interfaces, we probably want to do it in a lab setting as opposed to out in the wild. We want to bring participants into our lab and actually describe what we're going for, the rationale behind certain decisions, and get their feedback. Later on we might want to do real field testing where we give users a somewhat working prototype, or something resembling a working prototype. And they can actually reflect on it as they go about their regular lives, participating in whatever task that interface is supposed to help with. This helps us focus exclusively on the interface early on, and in transition to focusing on the interface in context later. But of course we want to also think about the context early on. We could for example, develop a very navigation app that works great when we test in our lab, because it demands a very high cognitive load. But doesn't work at all out in the field because when participants are actually driving, they can't spare that cognitive load to focus on our app. Now of course none of these are hard and fast rules. We'll very likely often do qualitative evaluation late or maybe do some field testing early. But as general principles, this is probably the order in which we want to think about our different evaluation styles.
735
736246 - Evaluation Design
737Regardless of the type of evaluation you're planning to perform, there's a series of steps to perform to ensure that the evaluation is actually useful. First, we want to clearly define the task that we're examining. Depending on your place in the design process this can be very large or very small. If we were designing Facebook, it can be as simple as posting a status update, or as complicated as navigating amongst and using several different pages. It could involve context and constraints like taking notes while running, or looking up a restaurant address without touching the screen. Whatever it is, we want to start by clearly identifying what task we're going to investigate. Second, we want to define our performance measures. How are we going to evaluate the user's performance? Qualitatively, it could be based on their spoken or written feedback about the experience. Quantitatively, we can measure efficiency in certain activities or count the number of mistakes. Defining performance measures helps us avoid confirmation bias. It makes sure we don't just pick out whatever observations or data confirm our hypotheses, or say that we have a good interface. It forces us to look at it objectively. Third, we develop the experiment. How will we find user's performance on the performance measures? If we're looking qualitatively will we have them think out loud while they're using the tool? Or will we have them do a survey after they're done? If we're looking quantitatively what will we measure, what will we control, and what will we vary? This is also where we ask questions about whether our assessment measures are reliable and valid. And whether the users we're testing are generalizable. Fourth, we recruit the participants. As part of the ethics process, we make sure we're recruiting participants who are aware of their rights and contributing willingly. Then fifth, we do the experiment. We have them walk-through what we outline when we develop the experiment. Sixth, we analyze the data. We focus on what the data tells us about our performance measures. It's important that we stay close to what we outlined initially. It can be tempting to just look for whatever supports are design but we want to be impartial. If we find some evidence that suggests our interface is good in ways we didn't anticipate, we can always do a follow up experiment to test if we're right. Seventh, we summarize the data in a way that informs our on going design process. What did our data say was working? What could be improved? How can we take the results of this experiment and use it to then revise our interface? The results of this experiment then become part of our design life cycle. We investigated user needs, develop alternatives, made a prototype and put the prototype in front of users. To put the prototype in front of users, we walked through this experimental method. We defined the task, defined the performance measures, developed the experiment, recruited them, did the experiment, analyzed our data and summarized our data. Based on the experience, we now have the data necessary to develop a better understanding of the user's needs, to revisit our earlier design alternatives and to either improve our prototypes by increasing their fidelity or by revising them based on what we just learned. Regardless of whether we're doing qualitative, empirical, or predictive evaluation, these steps remain largely the same. Those different types of evaluation just fill in the experiment that we develop, and they inform our performance measure, data analysis, and summaries.
738
739247 - Capturing Qualitative Evaluation
740With qualitative research, we want to capture as much of the session as possible. Because things could come up that we don't anticipate. And we'd like to look at them again later. So how do we do that? One way is to actually record the session. The pros of recording a session are that it's automated, it's comprehensive, and it's passive. Automated means that it runs automatically in the background. Comprehensive means that it captures everything that happens during the session. And passive means that it lets us focus on administering the session instead of capturing it. The cons though, are that it's intrusive, it's difficult to analyze, and it's screenless. Intrusive means that many participants are uncomfortable being videotaped. It creates oppression knowing that every question or every mistake is going to captured and analyzed by researchers later. Video is also very difficult to analyze. It requires a person to come later and watch every minute of video, usually several times, in order to code and pull out what was actually relevant in that session. And video recording often has difficulty capturing interactions on-screen. We can film what a person is doing on a keyboard or with a mouse, but it is difficult to then see how that translates to on-screen actions. Now some of these issues can be resolved, of course. We can do video capture on the screen synchronize it with a video recording. But if we're dealing with children, or at risk populations, or with some delicate subject matter, the intrusiveness can be overwhelming. And if we want to do a lot of complex sessions, the difficulty in analyzing that data can also be overwhelming. For my dissertation work I captured about 200 hours of video, and that's probably why it took me an extra year to graduate. It takes a lot of time to go through all that video. So instead we can also focus on note-taking. The benefits of note-taking are that it's very cheap, it's not intrusive, and it is analyzable. It's cheap because we don't have to buy expensive cameras or equipment, we just have our pens and papers or our laptops, or anything like that. And can just do it using equipment we already have available to us. It's not intrusive, in that it only captures what we decide to capture. If a participant is uncomfortable asking questions or makes a silly mistake with the interface, we don't necessarily have to capture that, and that can make the participant feel a little bit more comfortable being themselves. And it's a lot easier to analyze notes. You can scroll through and read the notes on a one hour session in only a few minutes. But analyzing that same session in video is certainly going to take at least an hour, if not more, to watch it more than once. But but of course there are draw backs too. Taking those can be a very slow process, meaning that we can't keep up with the dynamic interactions that we're evaluating. It's also manual which means that we actually have to focus on actively taking notes, which gets in the way of administering the session. If you're going to use note taking, you probably want to actually have two people involved. One person running the session, and one person taking notes. And finally, it's limited in what it captures. It might not capture some of the movements or the motions that a person does when interacting with an interface. It doesn't capture how long they hesitate before deciding what to do next. We can write all that down of course, but we're going to run into the limitation of how fast we can take notes. It would be nearly impossible to simultaneously take notes on what questions the user is asking, how long they're taking to do things, and what kind of mistakes they're making. Especially if we're also responsible for administering the session at the same. A third approach if we're designing software, is to actually log the behavior inside the software. This is in some ways, the best of both worlds. Like video capture, it's automatic and passive, but like note taking, it's analyzable. Because it's run to the system itself, it automatically captures everything that it knows how to capture, and it does so without our active invention. But it likely does so in a data or text format, that we can then either analyze manually by reading through it, or even with some more complicated data analytics methods. So in some ways, it captures the pros from both note-taking and video capture. But it also has its drawbacks as well. Especially, it's very limited. We can only capture those things that are actually expressed inside the software. Things like the questions that a participant asks wouldn't naturally be captured by software logging. Similarly, it only captures a narrow slice of the interaction. It only captures what the user actually does on the screen. It doesn't capture how long they look at something. We might be able to infer that by looking at the time between interactions, but it's difficult to know if that hesitation was because they couldn't decide what to do, or because someone was making noise outside, or something else was going on. And finally, it's also very tech sensitive. We really have to have a working prototype, in order to use software logging. But remember, many of our prototypes dont' work yet. You can't do software logging on a paper prototype, or a card prototype, or a Wizard of Oz prototype. This only really works once we've reached a certain level of fidelity with our interfaces. So in selecting a way to capture your qualitative evaluation, ask yourself, will the subjects find being captured on camera intrusive? Do I need to capture what happens on screen? How difficult will this data be to analyze? It's tempting, especially for novices, to focus on just capturing as much as possible during the session. But during the session is when you can capture data in a way that's going to make your analysis easier. So think about the analysis that you want to do, when deciding how to capture your sessions.
741
742248 - Predictive Evaluation
743Predictive evaluation is evaluation we can do without actual users. Now, in user centered design that's not ideal, but predictive evaluation can be more efficient and accessible than actual user evaluation. So it's all right to use it as part of a rapid feedback process. It lets keep the user in mind, even we we're not bringing users into the conversation. The important thing is to make sure we're using it appropriately. Predictive evaluation shouldn't be used where we could be doing qualitative or empirical evaluation. It should only be used where we wouldn't otherwise be doing any evaluation. Effectively, it's better than nothing.
744
745249 - Exercise: Evaluation Pros and Cons
746In this lesson, we've covered three different types of evaluation. Qualitative, empirical, and predictive. Each method has its advantages and disadvantages. Let's start to wrap this lesson up by exploring those advantages with an exercise. Here are the methods that we've covered. And here are some potential advantages. For each row, mark the column to which that advantage applies. Note that again, these might be somewhat relative, so your answer will probably differ a bit from ours. You can go ahead and skip to the exercise if you don't want to hear me read these. Our advantages are, does not require any actual users, identifies provable advantages. Informs ongoing design decisions, investigates the participants thought process. Provides generalizable conclusions, and draws conclusions from actual participants.
747
748250 - Exercise: Evaluation Pros and Cons Solution
749Here would be my answers to this exercise. These are a little bit more objective than some of our exercises in the past. First, if it does not require any actual users, predictive evaluation is the only evaluation we can do without involving users in the evaluation process. That's both its biggest strength and its biggest weakness. For identifying provable advantages, only empirical evaluation can reliably generate generalizable conclusions, generalizable advantages, because it's the only one who does it numerically. As far as informing ongoing design decisions is concerned, that's definitely the case for qualitative and predictive evaluation. I've left it unmarked for empirical evaluation simply because we usually do this towards the end of our design life cycle, although we also know that the design life cycle never really ends. So eventually, empirical evaluation could be used to inform ongoing design decisions. It's just not involved in the earlier cycles though the design life cycle. As far as investing the participant's thought process, again, empirical evaluation doesn't really do that. It only accesses participants performance numerically. Qualitative evaluation definitely does this, because it actually asks users to think out lout and describe their thought process. And really, predictive evaluation tries to investigate the participant's thought process, just in a lower overhead, or lower cost kind of way. It does so by having experts in usability design simulate the participant's thought process, and comment on it from the perspective of some preset heuristics. Similar to how only empirical evaluation can identify provable advantages, it's also the only one that can provide generalizable conclusions, again because it uses numbers. And finally, qualitative and empirical evaluations both draw conclusions from actual participants. This is the inverse of predictive evaluations, lack of requirement for actual users.
750
751251 - Exercise: When to Go Agile Solution
752Here would be my answers. The two areas that I think are good candidates for an agile development process are the two that use existing devices and don't have high stakes associated with them. In both these cases, rolling out updates wouldn't be terribly difficult, and we haven't lost a whole lot by initially having a product that has some bugs in it. A camera interface for aiding MOOC recording would be a good candidate, if the camera environment was easier to program for, but programming for a camera isn't like programming for an app store, or for a desktop environment. I actually don't even know how you go about it. So for us, a camera interface for aiding MOOC recording probably wouldn't be a great candidate, because we don't have access to that platform. And remember, our goal is to get products in front of real users as soon as possible. Now of course, that all changes if we're actually working for a camera company and we do have access to that platform. The second one is more fundamental though. A tool for helping doctors visualize patient information in surgery. There are really high stakes behind that, if you visualize something in a way that's a little bit misleading, someone could die. So you probably don't want take an agile development process for that. For a wearable device for mobile keyboard entry. Wearable devices are expensive to produce. When you're actually producing the physical device, you want to be sure it's going to work pretty well. And similarly devices aren't easy to update the way software is. So a wearable device is probably not a good candidate for agile development process. And finally, a navigation app for the console of an electric car, I said isn't a good candidate although you might disagree. Personally, I would say that the stakes are high enough for a navigation app, that you probably want to be pretty sure that you're going to have a good product before you roll it out to users. They might take a wrong turn or end up in the wrong neighborhood or miss an appointment based on some mistakes that we make. And I would consider that sufficiently high stakes to avoid a faster development process. And plus not all electric cars are like Tesla. Some of them actually have to have you bring the car to the factory or to the repair shop to get an update. So the cost of rolling out updates can be more significant there as well.
753
754252 - When to Go Agile
755So when should you consider using these more agile methodologies? Lots of software development theorists have explored this space. Boehm and Turner specifically suggest that agile development can only be used in certain circumstances. First, they say, it must be an environment with low criticality. By it's nature, agile development means letting the users do some of the testing. So you don't want to use it in environments where bugs or poor usability are going to lead to major repercussions. Healthcare or financial investing wouldn't be great places for agile development, generally speaking. Although there have been efforts to create standards that would allow the methodology to apply, without compromising security and safety. But for things like smartphone games and social media apps, the criticality is sufficiently low. Second, it should really be a place where requirements change often. One of the benefits of an agile process is they allow teams to adjust quickly to changing expectations or needs. A thermostat, for example, doesn't change it's requirements very often. A site like Udacity though, is constantly adjusting to new student interests or student needs. Now these two components apply to the types of problems we're working on. If we're working on an interface that would lend itself to a more agile process, we also must set up the team to work well within an agile process. That means small teams that are comfortable with change. As opposed to large teams that thrive on order. So generally, agile processes can be good in some cases with the right people, but poor in many others.
756
757253 - Paper Spotlight: “Towards a Framework for Integrating Agile Development and User-Centred Design”
758In 2006, Stephanie Chamberlain, Helen Sharp, and Neil Maiden investigated the conflicts and opportunities of applying agile development to user-centered design. They found interestingly that the two actually had a signficant overlap. Both agile development and user-centered design emphasized iterative development processes building on feedback from previous rounds. That's the entire design life cycle that we've talked about. That's at the core of both agile development and user-centered design. Both methodologies also place a heavy emphasis on the user's role in the development process. And both also emphasize the importance of team coherence. So it seems that agile methods and user-centered design agree on the most fundamental element, the importance of the user. By comparison, the conflicts are actually relatively light, at least in my opinion. User-centered design disagrees with agile development on the importance of documentation and the importance of doing research prior to the design work actually beginning. But, clearly, the methodologies have the same objectives. They just disagree on how to best achieve them. As a result, the authors advocate five principles for integrating user-centered design and agile development. Two of these were shared between the methodologies in the first place, high user involvement and close team collaboration. User-centered designs' emphasis on prototyping and the design life cycle shows that by proposing that design is run a sprint ahead of developers to perform the research necessary for user-centered design. To facilitate this, strong project management is necessary.
759
760254 - Live Prototyping
761One application of Agile development in HCI is the kind of new idea of live prototyping. Live prototyping is a bit of an oxymoron, and the fact that it's an oxymoron speaks to how far along prototyping tools have come. We've gotten to the point in some areas of development where constructing actual working interfaces is just as easy as constructing prototypes. So here's one example of this, it's a tool we use at Udacity called Optimizely. It allows for drag and drop creation of real working webpages. The interface is very similar to many of the wire-frame tools out there, and yet this website is actually live. I can just click a button and this site goes public. Why bother constructing prototypes before constructing my final interface, when constructing the final interface is as easy as constructing prototypes? Of course, this only addresses one of the reasons we construct prototypes. We don't just construct them because they're usually easier, we also construct them to get feedback before we roll out a bad design to everyone. But when we get to the point of making small little tweaks or small revisions, or if we have a lot of experience with designing interfaces in the first place, this might not be a bad place to start. It's especially true if the cost of failure is relatively low, and if the possible benefit of success is particularly high. I would argue that's definitely the case for any kind of e-commerce site. The cost of failure is maybe losing a few sales but the possible benefit is gaining more sales for a much longer time period. I'm sure anyone would risk having fewer sales on one day for the possible reward of having more sales every subsequent day.
762
763255 - B Testing
764So in some contexts, it's now no harder to construct an actual interface than it is to construct a prototype, so we might skip the prototyping phase altogether. However, prototypes also allowed us to gather feedback from users. Even though we can now easily construct an interface, we don't want to immediately roll out a completely untested interface to everyone who visits our site. We might be able to fix it quickly, but we're still eroding user trust in us and wasting our user's time. That's where the second facet of this comes in, AB testing. AB testing is the name given to rapid software testing between typically two alternatives, A and B. Statistically it's not any different from T-tests. What makes AB testing unique is that we're usually rapidly testing small changes with real users. We usually do it by rolling out the B version, the new version to only a small number of users, and ensuring that nothing goes terribly wrong, or there's not a dramatic dip in performance. That way we can make sure a change is positive, or at least neutral, before rolling it out to everyone, but look where testing feedback coming in here. They're coming automatically with the real users during normal usage of our tool. There's no added cost to recruiting participants and the feedback is received instantly. So for a quick example, this is the overview page for one of Udacity's programs and it provides a timeline the students should dedicate to the program in terms of number of hours. Is number of hours the best way to display this? I don't know, we could find out. Instead of showing 420 hours maybe I say this as 20 hours per week. In this interface all I have to do is edit it and I immediately have a new version of this interface that I can try out. Now I can click Start Experiment and try this out. I could find out. Does phrasing this as ten hours per week, does it increase the number? Does it decrease the number? If it decreases it, I can very quickly roll this back. If it increases it, I can very quickly roll this out to everybody. I'm going through the same design life cycle. I understand that the need is for the user to know where the timeline is. I've got a design in mind, which is to show the timeline in number of hours per week. I prototype it. It just happens to be here that the prototype is live. And I immediately roll it out. I look at how users use it, I evaluate it, and I decide if I want to roll back that change, or roll it out to everybody. I can go through a microcosm, a very rapid iteration to really design life cycle by using live prototyping and AB testing.
765
766256 - Technology: Augmented Reality
767Virtual reality generally works by replacing the real world's visual, auditory, and sometimes even all factory or kinesthetic stimuli with it's own input. Augmented reality on the other hand, compliments what you see and hear in the real world. So for example, imagine a headset like a Google Glass that automatically overlays directions right on your visual field. If you were driving, it would highlight the route to take, instead of just popping up some visual reminder. The input it provides complements stimuli coming from the real world, and instead of just replacing them. And that creates some enormous challenges, but also some really incredible opportunities as well. Imagine the devices that can integrate directly into our everyday lives, enhancing our reality. Imagine systems that could, for example, automatically translate text or speech in a foreign language, or could show your reviews for restaurants as you walk down the street. Imagine a system that students could use while touring national parks or museums, that would automatically point out interesting information, custom tailored to that student's own interests. The applications of augmented reality could be truly stunning, but it relies on cameras to take input from the world, and that actually raises some interesting societal problems. There are questions about what putting cameras everywhere would mean. So keep those in mind when we get to interfaces and politics, in unit two.
768
769257 - Idea: Pen- and Touch-Based Interaction
770I always find it interesting how certain technologies seem to come around full circle. For centuries we only interacted directly with the things that we built and then computers came along. And suddenly we needed interfaces between us and our tasks. Now, computers are trying to actively capture natural ways we've always interacted. Almost every computer I encounter now days has a touch screen. That's a powerful technique for creating simple user interfaces because it shortens the distance between the user and the tasks they’re trying to accomplish. Think about someone using a mouse for the first time. He might need to look back and forth from the screen to the mouse, to see how interacting down here, change things he sees up here. With a touch based interface, he interacts the same way he uses things in the real world around him. A challenge can sometimes be a lack of precision, but to make up for that we've also create pen based interaction. Just like a person can use a pen on paper, they can also use a pen on a touch screen. And in fact, you might be quite familiar with that, because most Udacity courses use exactly that technology. They record someone writing on a screen. That gives us the precision necessary to interact very delicately and specifically with our task. And as a result tablet based interaction methods have been used in fields like art and music. Most comics you find on the internet are actually drawn exactly like this, combining the precision of human fingers with the power of computation.
771
772258 - Domain: Healthcare
773A lot of current efforts in healthcare are about processing the massive quantities of data that are recorded everyday. But in order to make that data useful, it has to connect to real people at some point. Maybe it's equipping doctors with tools to more easily visually evaluate and compare different diagnoses. Maybe it's giving patients the tools necessary to monitor their own health and treatment options. Maybe that's information visualization so patients can understand how certain decisions affect their well-being. Maybe it's context aware computing that can detect when patients are about to do something they probably shouldn't do. There are also numerous applications of HCI to personal health like Fitbit for exercise monitoring or MyFitnessPal for tracking your diet. Those interfaces succeed if they're easily usable for users. Ideally, they'd be almost invisible. But perhaps the most fascinating upcoming intersection of HCI and health care is in virtual reality. Virtual reality exercise programs are already pretty common to make living an active lifestyle more fun, but what about virtual reality for therapy? That's actually already happening. We can use virtual reality to help people confront fears and anxieties in a safe, but highly authentic place. Healthcare in general is concerned with the health of humans. And computers are pretty commonly used in modern healthcare. So the applications of human computer interaction to healthcare are really huge.
774
775259 - Domain: Security
776Classes on network security are often most concerned with the algorithms and encryption methods that must be safeguarded to ensure secure communications. But the most secure communication strategies in the world are weakened if people just refuse to use them. And historically, we've found people have very little patience for instances where security measures get in the way of them doing their tasks. For security to be useful it has to be usable. If it isn't usable, people just won't use it. XEI can increase the usability of security in a number of ways. For one, it can make those actions simply easier to perform. CAPTCHAs are forms that are meant to ensure users are humans. And they used to involve recognizing letters in complex images, but now they're often as simple as a check-box. The computer recognizes human-like mouse movements and uses that to evaluate whether the user is a human. That makes it much less frustrating to participate in that security activity. But HCI can also make security more usable by visualizing and communicating the need. Many people get frustrated when systems require passwords that meet certain standards or complexity, but that's because it seems arbitrary. If the system instead expresses to the user the rationale behind the requirement, the requirement can be much less frustrating. I've even seen a password form that treats password selection like a game where you're ranked against others for how difficult your password would be to guess. That's a way to incentivize strong password selection making security more usable.
777
778260 - Domain: Games
779Video games are one of the purest examples of HCI. They're actually a great place to study HCI, because so many of the topics we discuss are so salient. For example, we discussed the need for logical mapping between actions and effects. A good game exemplifies that. The actions that the user takes with the controller should feel like they're actually interacting within the game world. We discussed the power of feedback cycles. Video games are near constant feedback cycles as the user performs actions, evaluates the results and adjust accordingly. In fact, if you read through video game reviews you'll find that many of the criticisms are actually criticisms of bad HCI. The controls are tough to use, it's hard to figure out what happened. The penalty for failure is too low or too high. All of these are examples of poor interface design. In gaming though there's such a tight connection between the task and the interface. Their frustrations with a task can help us quickly identify problems with the interface.