Part 1 - Five Essential Principles of Interaction Design

[This series is best viewed at full-screen in HD mode.] [♪♪] [ADOBE TV Presents] [♪♪] [CLASSROOM - Five Essential Principles of Interaction Design] Hi. I'm Dave Hogue, the Vice President of Experience Design at Fluid here in San Francisco. And in this lesson we're going to be talking about interaction design, specifically an introduction to the five essential principles of interaction design. Interaction design is a complex field to define, so let's take a look at how some people refer to it. The Interaction Design Association has a definition for the field. They say that it defines the structure and behavior of interactive systems and that interaction designers strive to create meaningful relationships between people and the products and services that they use. What this means is that we're working on interfaces and basically how people are interacting with their devices-- not just websites. But the field of interaction design is actually very large and fairly complex, and there are many things that we could be talking about, so we need to focus ourselves on a few basic principles to help guide our design decisions. If we take a look at many of the things that we can talk about, such as explorability, efficiency, locus of control, the concept of perceived affordances, this could go on for days and days. So we're going to focus on five key principles: consistency, visibility, learnability, predictability, and feedback. But the most important thing for us to remember when we talk about interaction design is that we are not talking about the behavior of the interface, we're talking about behavior of people. And we're designing for helping them to interact with devices. Let's go ahead and jump in and start talking about these five essential principles. The first: consistency. People are very sensitive to change. It's the way that we evolved; it's the way that our brains are wired. We notice when there are differences. So when there are differences in an experience, people pay attention to that. And what we don't want them doing is asking, "Why is this different?" or, "Why isn't that the same?" So we wanted to establish a system of design for ourselves that allows people to feel comfortable, that as they learn how to interact, it is familiar to them on the different pages or the different screens. Let's take a look at a few examples of how inconsistency can attract attention in a negative way. This is a simple wireframe. And as we go through different pages in this set of wireframes, you'll notice that things begin to move around on the page. Specifically take a look at the header and how the content area is laid out. In this case, the secondary navigation is using underlines, and the Make a Reservation button is located on the right side of the screen. But as we go to a different page on the site, suddenly the navigation terms have rearranged, there's no longer an underline, and the Make a Reservation button has moved. Even things in the header above the navigation have switched their locations. And as we go to yet another page, we find another layout to the content and yet a different location to the button. As we just quickly step through these, you notice right away that as you go from page to page, your eye is drawn not to the content but to the objects that are moving, that are changing their location. People aren't paying attention to what you want them to do, they're paying attention to where things are located, and that's not efficient for the experience. We should also be very careful about how we design components so that people begin to recognize them. Elements that have similar behavior should have similar appearance. Once again let's take a look at a few wireframes as examples. In this first wireframe, we're introducing the concept of a content module that has hide/show functionality. If people want to see more information, they simply click on the title bar and that content is revealed to them. On another page we're using a similar hide/show functionality, but we're using a different iconography, and the content is presented in a slightly different way. We're also taking content that was previously available in the main area of the page in the prior wireframe and we're positioning it in the left column in a new format with a new visual style. And in this last wireframe, we see once again that now we have a navigational system in the left column that looks a bit like the modules but isn't, and we've returned to an original style for the hide/show module. Once again as we just quickly step through these wireframes, you can see similar functionality. It is all hide/show functionality being presented in different ways on different pages, and it really should be using the same design pattern. There should be consistency in the presentation so that people learn how to do it and then they're able to recognize that every time they find it on another page. Similarly, components with different behaviors should have a different appearance. When you use the same presentation for different functionality, people can get confused. Let's take a look at some wireframe examples. On this one we have a simple slideshow, but we also have tabs because there are different chapters to the photos. We have previous and next functionality, we have what appears to be an enlarge or zoom feature, and we have down here a little drawer function that is going to give us access to information or additional content about that image. When we look at this, we understand that each one of these different patterns is going to produce a different reaction. In other words, I know that when I click on a tab I'm going to see a different set of content. I know that when I click on an arrow I am going to see the next in a sequence. I know this is larger, and I know this is going to show me more information. And in fact, as we begin to interact with it, we see that the Details does in fact slide into view and can be easily removed. And if I view larger, I can get a slideshow on a layer of content above that page so I get a much bigger image and the details can also be presented here. Changes in appearance and behavior can attract unwanted attention. When things don't look the same throughout the experience and when things don't behave the same throughout the experience, people pay attention to the difference. It's all in the details. We want to be very careful of things such as color and iconography, typography, shape, and alignment, even the grid system and the sense of proportion that we are designing toward. And this also applies to the behaviors, which is specifically relevant to interaction design. How do the transitions occur? How does the interface react when people click on a button or when they use a component on the page? So we want to be very careful that we define a style, that we define patterns for our interactions, and that we reuse them consistently. Let's take a look at the next factor, the essential principle of visibility. You cannot invite people to become engaged with an interface and to be interactive with it if they don't know that the opportunity to interact exists. Since most interfaces are inherently visual, this means providing some type of a cue to people that says, "Hey! Interactivity is over here. You can do something with this element." Hidden interactions will decrease usability and efficiency. When interactions are hidden, you're essentially relying on people's ability to randomly discover them as they are using the interface. And discoverability should not involve luck or chance. You are designing an experience; you are not designing a scavenger hunt or a treasure map. Let's take a look at some wireframes that show how just adding additional information can tell us what's happening. In this particular wireframe we've got two images, but one of them is actually a video. It's set so that if you mouse over the image, the Play controls will appear. But when this page first loads, people have no idea that there is actually media available to them. What we should do is make sure that people are able to distinguish that type of media by giving visual cues. One is a photo, the other is a video. So the Play icon and the Play controls clearly communicate to people, "This is something that you can interact with." We also want to avoid situations where people falsely believe that they have reached the end of their content. We sometimes call this a false bottom because on web pages it appears that the content has ended at the fold or the bottom of the visible browser canvas when in fact there is more content below. What we can do to try and avoid this is what's called content hinting. In other words, we give very specific cues that say, "There is more content below," such as trying to make sure that images always fall across the fold line so that a little bit of it is available above the fold. When we take a look at this wireframe, you'll see an example of a false bottom. The dashed red line here represents where the fold would be in a typical browser, and you can see that if someone were simply reading the content, it would look as if they had reached the end of the page. Nothing peeks above the fold to let them know there is more content below, and in fact, we have three very important content modules that are not visible. So what can we do? Maybe we restructure the content so that some of the modules appear above the fold. Maybe we make sure that there is content in either the left or right column that extends lower on the page so that people know that it goes. You may say, "Well, people look at the scroll bar in their browser." "They know it's a longer page, right?" Well, no, not always. They're focusing on the content of the page; they're not necessarily looking at the controls of their browser. So we want to make sure that they see that there is more information available. We also want to signal the availability of interaction with visual cues that invite people to click or touch, and there are a lot of different ways that we can do this. Essentially, people are very click happy. They will attempt to interact with anything that looks like it might be something that will react to them. So standard interface components such as buttons often include depth cues or 3D with shading and shadows, and it makes us want to touch them. Icons and images. They are very common mechanisms for people to interact with web pages and in fact, many of them are familiar to us. And even the use of a very small image for people communicates, "If you click this, you'll probably get a larger view." Textures. We often don't think about texture and design for digital devices. But what we're doing is simulating what looks like something people might want to touch. So the scroll bar, the thumb actually has a little grip zone on it, and modules or components that can be dragged and dropped very often will use a little grip zone or touch zone with texture cues in the top corner so that people get the cue, "Hey! I can click here," or, "I can move this." But also text styles. In the early days of the Web, it was very standard for people to use hyperlinks that were just blue and underlined, and everyone learned that. But we have since generalized that, and now when we're looking in blocks of content, almost anything where the text is different may be perceived as a link. So it doesn't necessarily have to be underlined, but if we change the text color, if we change the font weight, even if we use a traditional blue with an underline, people are very likely to try and click on that text. Games and Easter eggs. They're a special exception to this principle of visibility. When we want people to be efficient and task-focused, it's very important to have visibility. But when discovering and play and exploring is an important part of the experience, well, now maybe not telling them where things can interact is part of what they want to be doing. So we're going to make an exception for game design when we talk about the rule of visibility. And a famous Easter egg here from Photoshop from the About Us panel. The next component: learnability. Interactions should be easy to learn and easy to remember. You want people to be able to remember what they've learned on one page to the next and from one visit to the next or from one use to the next. Ideally, the situation is, "Use it once, learn it, remember it forever." Practically speaking, it's probably a little bit different, where we often have to use something several times before we really learn how to use it. It takes practice to reinforce our memory, and then we hope that they're going to come back often enough to be able to remember that. Learning theories from psychology can help us better understand how people remember this. There's a whole lot of information here. There's much deeper content than we have the opportunity to discuss here today. But if we talk about just two basic theories, operant conditioning and observational learning, that can tell us a lot about how people are learning to interact with devices. In operant conditioning, basically if you have a positive outcome, it increases the probability of that behavior. In other words, if people do something and they get what they want, they've been rewarded. That's feedback to them that increases the likelihood that they will do that again in the future. On the other hand, if they do something and they get a result that was unexpected or unwanted, well, that's punishment or an error has occurred, and they are less likely to do that in the future. With observational learning, it's all about modeling and imitation. We watch what other people are doing and then we imitate it or we mimic that. They serve as a model, and we do what we have seen them do. Video tutorials are an excellent example of observational learning. We watch someone use a design tool, and then we try and do the same thing ourselves. We repeat what we have seen. Learnability is often equated with ease of use. But even interfaces that are easy to use sometimes require practice in order to learn them. The more we use an interface, the easier it becomes for us to do that. And practice leads to decreased error. So if we take a look at this graph, we'll see that when we first begin using something, we are a novice and we're likely to make more errors because we have had little practice. But over time, as we get more practice and as we become experts, we make fewer errors and it takes less time for us to complete our tasks. So we should not be surprised when people use something for the very first time when they're novices that it takes them longer and they are more prone to errors. What we want to do is design something that is so easy to learn that they can proceed along this curve quickly. In other words, they can move from novice to expert with only a little bit of training and experience. Learnability also means that people are going to take what they have learned in other places and they are going to apply it to your device or to your interface. And that might be the real world, it might be other devices, it might be other applications or websites. For example, if we take a look here, we are seeing what are great examples of perceived affordances. Perceived affordances are a popular topic, and people discuss the affordances of interfaces all the time. But what they really mean is a perceived affordance. An affordance is actually a property of a real physical object, where we understand, "How does it work, how am I going to interact with it, "what is it going to do?" "I can lift it, I can press it, I can turn it." When we draw the digital equivalent in an interface, now we are representing metaphorically or as an analog what that button or what that nob is. So a button in an interface has visual characteristics that remind us of physical buttons that can be really pressed. This button has an affordance. The digital button has a perceived affordance. Similarly, sliders on a sound mixing board versus sliders in a digital interface or even the physical tab folders in a file cabinet and the tabs that we see in an interface. They communicate to us, "This is similar to something you have done in the real world." And we transfer that learning from one place to another. And we should always design to try and take advantage of what people already know. Predictability. The design should set accurate expectations about what is going to happen before someone interacts with it. Visitor behavior can tell us whether or not they know what they are doing. If you watch someone interacting with a device and they appear to be randomly moving around or just touching or clicking on anything that looks like it might react to them, chances are they're not able to predict what is going to happen or what they should be interacting with. On the other hand, if someone is task-focused and they understand what is going on, well, then you'll see that focus in their behavior. They know precisely where to touch, they can tell you what should happen next, they can even tell you what the outcome is likely to be. If you set the correct expectations, you're able to establish the ability to predict the outcomes. We can use previews to set expectations and define constraints for new or complex interactions. So for example, as an interface is loading, maybe there is a layer of content that gives a preview of what it's going to be, how it behaves, and how you should interact with it. So that people aren't just sitting there waiting while a spinner loads on the page, we give them content so that they can understand and predict what the experience is going to be. Simple things like labels, instructions, icons, and images can all be used to establish context to help us understand, "Oh! I know what's going to happen when I click this button "and I know what the outcome will be." When we're talking about predictability, there are four things that we want to be able to communicate: What should you do; What will happen; Where is it going to take you; and How is the interface going to respond. Let's take a look at a wireframe example. We have several things that are happening on this page that are all giving us cues or clues to predict what is going to happen. We have a content module that looks like it is clickable. We've defined a pattern. We have a Show link very specifically that says, "Oh! Something is going to be revealed." We have a Hide link that says, "Oh! Content is going to be removed." We have an icon and a link that says to download re-potting instructions. We have a View Larger Icon and Text. We have Play indicators for embedded media. All of these things allow people to understand exactly what will happen and what they're going to get once they interact with this. Feedback. Feedback is essential because it provides information about where you are, what's happening, what might happen in the future, and whether or not something has finished. One of the most important things about feedback is that it should never interrupt the visitor's experience. Feedback should complement the experience; it should never complicate the experience. We also want to make sure that when people are doing something they understand how they can undo, that there is some way to revert a decision, undo an action, or to correct a mistake. Let's take a look at a wireframe example that has different types of feedback in it. In this particular case, someone has opted to download a file, and this Download dialog is giving us status information about what is happening. It's telling us the percentage of progress. It's also giving us the absolute file size so that we know about how large it's going to be. There is text that says what is happening as well as the document that is being downloaded. And we even have the ability to cancel this download from here. This simple dialog is giving multiple cues about what is happening, what you are getting, how long it will take, and that you have the option to get out of it. Every interaction should produce a noticeable and understandable reaction. I think Isaac Newton said something like this one time. We should always acknowledge interactions, let people know that they've been heard or felt or seen or whatever the input mechanism happens to be. When we fail to acknowledge an interaction, it can lead to unnecessary repetition of those actions. If people don't realize that what they have done has been received, they are going to try and repeat it until they get feedback, and that means maybe buying 12 pairs of fuzzy pink bunny slippers when you really only wanted one, because every time you hit the Submit Order button, nothing seemed to happen. There are different ways that we can indicate progress and completion. These indicators are just simple diagrammatic examples. But we do need to consider one thing, and that is that sometimes we know how long it will take for an action to occur and sometimes we don't. When we do know how long it will take, we have definite indicators. So I can say, "There's 42 seconds remaining," or, "Sixty-eight percent of the file has transferred." When it's indefinite, on the other hand, it is simply saying, "Yes, I am still working on this." "I am here. I received your input. I am responding to it." "Unfortunately, I can't tell you how long it's going to take." So we have an indefinite indicator such as a progress bar where there's just a highlight that moves back and forth or the ubiquitous spinners that we see. It might also just be a simple text message: "Thank you. Please wait a moment while we process your order." Let's take a summary look now at these five principles because they're actually quite interrelated. This diagram shows us how we can think about these five principles as a system and not just isolated descriptions. When people come to an interface, no matter where it is-- a kiosk, a mobile device, a touch device, or a website-- if they can understand where they can interact with it if it is visible, and if it communicates what is going to happen when they interact with it if it is predictable, then they interact with it. And when they interact with it, it should provide feedback to them. And if that feedback is meaningful, they'll understand what has happened. And if it has allowed them to gain a deeper understanding, they'll begin to learn how the interface works. And now what happens is we continue to use it. And so we practice and we observe. "What happens when I do this? What happens when I do that?" And we continue this cycle of, "Oh! I see I can interact. I think this will happen." I do it, it's what does happen, I get positive feedback, I learn, and then I observe and practice. And once I have learned that behavior, I now have the opportunity to transfer that knowledge to other environments or to other devices or other situations. And as long as they have some consistency, what I learn in one area will apply to another. And so we have this wonderful cycle where these five essential principles help us to make better design decisions when crafting an interface. So the overall view now. Professional design is important, and all of these factors are essential to crafting a professional design. You want to be credible. You want to establish trust. So it's just more than all of these factors individually, it's all of these factors combined: nuance and polish, consistency and feedback. We don't want to be different just for the sake of being different. We want to be different when being different means being better. So we learn from what people have done, we allow them to transfer their knowledge, we provide the feedback, we make it understandable to them. We want to leverage design patterns. Design patterns are a very important topic in the field. They are essentially a reusable solution to a recurring problem, and we can learn. Many design patterns are already out there. There are thousands of designers who are working on challenging interaction issues that we can learn from. That doesn't necessarily mean that every pattern we see is going to be an effective pattern. But we need to make sure that we are selecting patterns that work, that are appropriate, basically that have been tested, and that are a good fit to the interaction that we want. Although the content may change, the underlying concept of the pattern can be applied, and this really feeds into consistency and predictability and the ability to transfer our learning. And then finally, prototype. The design you have in your head might seem wonderful, but when it actually comes down to execution, well, maybe it doesn't work quite the way you thought it would or maybe it's not understood or perceived the way that you thought it would. So it's very important to take the opportunity to create something that you can test, that you can play with, and that you go beyond just the sketch and you actually begin to interact with the interface. The most important feedback that you can get is from really behaving, from really interacting with something. And take the feedback that you get. Designers need to be fairly thick-skinned because we get a lot of negative feedback about what we're doing. But that negative feedback should point you in the direction of new design opportunities and not to take it personally. Finally, it's important to remember you're not designing for yourself. The way you want something to work and the way that you think about it and your own learning is unique to you. You need to be thinking about the audience for the interface that you are designing. Once we get deep into a project, we understand it very, very well and it makes it harder for us to understand through fresh eyes how someone else may see that. So it's good to remind ourselves periodically that, "I'm not designing for me, "I know more about this than other people do, "I need to prototype this, I need to get it in front of people, "I need to choose design patterns, I need to apply these five principles, "and I need to understand how it is working." Thank you. This has been just a quick introduction to five essential principles of interaction design. In the following lessons, we're going to apply these principles of interaction design in some key areas for common interface design. We're going to be discussing navigation, presentation of text, images and multimedia, and forms and dialogs. Thank you. [♪♪] [ADOBE TV PRODUCCTIONS - tv.adobe.com]