[SOUND]. Mental Models are an important part of usability. They let us understand how users perceive systems, and if we keep that in mind when we're designing a system, it can improve usability, in all the aspects that we've discussed. Users of the system didn't write the code, and generally weren't involved in the design process, so when they come in to use a piece of software, they generally don't know how it works, yet often times people are able to sit down and immediately begin using a piece of software. When they're doing this, they're relying on mental models. This borrows knowledge from all other parts of their life, including experience in the outside world and with other software they've used. They have those models they apply to the current piece of software that they're using. And they can rely on their expectations in previous experience to help guide them through using the software. If we can take these mental models into account when we're designing software, we can build things in that make it easier for users to learn to use the software. To remember how to use it. And, as they're interacting with it, they can be faster, more efficient, and more confident. In short, usability improves all the way across the system. There a number of factors that play into developing mental models, which we'll look at today. First, are affordances. Affordances are things within a system that show a user how they're supposed to be used. There are a couple components that are important to consider as part of affordances. Mapping, visibility, and feedback. Let's look at each of those individually. Mapping discusses how, certain functionalities will map to, something that you see. If we think about a stove that you may have in your house, you have four burners on it, and you have four knobs. Each knob turns on a burner. But which knob turns on which burner? Ideally we would want a mapping that says, which burner the, left most knob goes to, which burner the right most knob int his pair goes to and so on. This, current set up that we're looking at here, probably indicates to us that these two knobs go to the two burners on the left and these two control the two burners on the right, so there's some affordance there. There's some mapping. But, we don't really know which of these knobs turns on, which burner, the front or the back. We could redesign this layout so that there's a better mapping. One simple way to do this would be to change the, configuration of the knobs entirely. Here it's very clear that the, lower most knob controls the lower burner, the top knob controls the top burner. And the left group controls the left burners, the same for the right. This is a, big change in the size of the system. So, maybe there's a way that we can alter the layout of the knobs so that there's a good mapping. One way to do that could be to have them similar to how they were at first, but to have two of the knobs placed closer to the back and two closer to the front. This gives a pretty good indication. That the two center knobs are controlling the two back burners, since they're further back. But the mad thing would be even clearer if there was a, match between the layout of the knobs and the layout of the burners. Here, we've moved the two back burners closer together so it's quite clear that that matches the layout of the two rear knobs. This is a way that we can do mapping. We want there to be a clear correspondence between the controls and the result that will come from using them. Cars a classic example of where there's a very clear mapping between the controls and the functionality. So if I'm driving and I want to turn the car left, [SOUND] it makes sense for me to turn the wheel to the left. I'm turning the wheel in the same direction I want the car to go. I turn right to make the wheels go right. If I want to use the turn signal, it follows the same direction as the steering wheel. If I want to turn left, I hit the, signal down, which is the same direction I would turn the wheel if I were going left. If I want to go right, I move the signal up, which is the same direction I would turn the wheel if I were turning right. As we've discussed before, Google does a great job of making it's functionality visible in a usable way. The most visible thing is the task, people want to do most often, which is to do a search. On top of that, other things people want to do are also visible on the page, but they don't clutter up the main task, so, advertising business and about pages, are clearly visible, but they're hidden away down at the bottom. Anyone who's looking, would likely head to this area to try to find it, but. It won't get in the way of someone who's not interested in finding that. The same thing is true over here with privacy and terms. Again, those are normally at the bottom. They're visible for someone who's looking for them. But it's not going to get in the way of the major task that someone else is trying to accomplish. This e-commerce site illustrates, some feedback. Here we're looking at a T shirt and if I want to order it in a small I can see that that size is grayed out. If I put my mouse over it I get feedback on top of the picture that says, this is not available in the size that you're looking for. And if I click on the size Small, it grays out the color options that aren't available, in this case the white one up at the top. Constraints, talk about how a system can prevent us from doing things that we shouldn't and how the design of it can encourage us to do things the right way. Let's look at an example. The classic example of a physical constraint is what you get with the plug. It's difficult to get confused about which orientation to use since it's very clear where the slot is. Furthermore, if we have different sized prongs, one slot is too small, so we know we're constrained [SOUND] and have to turn it around. In this page, we have a log in window. It has the email address and a password and there's a sign in button. Now, it is obvious that I should enter a password, but I can click sign in without typing it in, and then I get an error, asking me to please provide my password. This is okay, but there are better ways to do this. Specifically, we can incorporate a constraint. For example, if we pick a Wi-Fi network, we're prompted to enter a password. But the Join button doesn't appear until the password has been typed in. So we can enter a password and only when it's long enough. Do we have the option to click the Join button? That's creating an affordance and a constraint, so I know that I can't even try to join until I've typed the password in. Conventions describe a common understanding of what something means. These can be cultural or relatively universal. When we're looking at software, we've often seen traffic metaphors creep in. For example, stoplights are, used in a lot of countries. Red always means stop, and it's almost always on the top. Green means go, and it's almost always on the bottom. Traffic signs are also used. The yield or alert sign. Often is yellow, triangle shaped and is very common across cultures. As is the red circle with the diagonal slash that indicates you should not do what it is that you are trying to do. Because these are well known across cultures, they're easy to use in software because we can expect. Users understand the conventional meaning of these symbols, and they can incorporate it into their mental model of how the system works. Let's see that working in software. If I go to the Pandora website, it starts playing a radio station for me. [MUSIC] Now, there's a set of controls across the top, and we're really expecting the user to know what those controls are. [MUSIC] There's this button in the middle, which we're trained to know means pause, though it doesn't say pause. But it works. If we see the triangle we know it means play. [MUSIC] There's a thumbs up and a thumbs down to the left, which again, we're encultured to know means that we're voting a song up or down. Now, the timeline at the bottom may give us a way to fast forward or rewind, but clicking there doesn't seem to do anything. In this case, our expectation wasn't met. [MUSIC] The volume works as expected, and the Skip option with the two triangles in the line does, in fact, skip us to the next song. This relies on conventions for controlling music that are well understood by users. So to come back to mental models, they're really a combination of, labels which can be put into the system to explain what's going on. But more than that, affordances which help a user figure out what to do. Constraints which prevent them from doing the wrong thing. Mappings between the controls and the actual functionality. Conventions that users have come to expect from controls and system interaction. If we put all these things together along with our understanding of users' experiences, both in general, outside in the world and with software. It can help us better understand what the user will expect when they come in to use the system. And how we can design it to be more usable. And, eventually, for our concerns, more secure.
