We talked about interface design being a science. There is a really accessible set of ideas from Donald Norman's book the Design of Everyday Things that we're going to apply to achieving the scientific test oriented approach to achieving usability. Let's get started, I'm going to walk you through this material. First, there's some vocabulary that if we take a tub like this the idea is that we have this idea of a signifier. And the signifier is the relationship between the user and what they think a given thing that they're seeing in a tub or a piece of software can do. For example with this dial people at least here in the US these are pretty common and people understand that a dial like this is something you can flip up and flip down, but that's it nothing else. And then there's this other idea of an affordance, and the affordance is what this thing can actually do. So the fact that indeed it does just flip up and down. That might seem like a lot of stuff and kind of nit picky. But in fact this this was something that Donald Norman added in the second edition of his book that I think he brought in his 80s and it's really, really useful. Because especially for our purposes, because we're taking a hypothesis driven approach and it's really important to separate out what we think a user is going to understand from a given interface element versus what they actually do understand and that's really the difference between these two terms. The signifier is what the user understands its due, the affordance is what it actually does. And obviously we want to make those two the same but we have to test our way to that to validate that hypothesis, that in fact the users understanding this thing we're presenting to them the way that we expect. A constraint is an easy win, once you know what you're trying to do. A constraint is the fact that this dial only goes up and down if it went also side-to-side or spun around that would be confusing to the user because that's not that does not actually going to do anything for them. And so for example, if you think about a piece of software and there is we want state abbreviations in the US. Well, we just do a drop down of state abbreviations rather than having the user type that in so that they don't accidentally put in the wrong two letters. And then we have this idea of feedback, it's really important. When we flip the dial, honestly, I don't remember whether up or down is open or closed. And so I need feedback, I start running the water, I think pretty much every time I fill up the tub and I flip it up or I flip it down and then I see whether the water is rising or draining. Now, maybe I should remember it better, but I don't because I don't take baths very often. And so feedback is really critical, feedback is the user observing what's actually going on and being able to understand the signifier and the affordances and what they've done with them. And then finally a mapping is the understanding that users carry around with them about the relationship between signifiers and affordances. So for example, in this case users care around this idea that these dials are things you can flip up and down. And likewise with software there there there are changes, but they're pretty durable common patterns to the types of interface elements that users are going to see in a piece of software. The way that we kind of unpack these experiences is with these seven steps. And the classic example Donald Norman uses in his book is that he is sitting in an armchair, it's late afternoon, the light level is dropping and he can't see his book well enough, but he wants to keep reading. And so his goal is to keep reading, and really goal is equivalent to the term that we've been using problem scenario or job to be done. And so the job to be done is not in this case turn on the light, which is what he's going to do in this example, his job to be done is to keep reading. And being able to separate out problem and solution and think about them that way is really critical while we spent so much time on that proceeding material. The plan step is where he elects an alternative from the alternatives available to him for that job to be done, and again using our phrasing. And so for example, he has he does have choices, he could quit reading. He could move to another part of the house that gets more light at this time of day. Or he could turn the switch on the light and maybe that will help them keep reading. And so in this case he plans he selects an alternative which is to turn on the light. Then he specifies a series of steps that he's going to use to turn on the light. He raises his arm, he finds the switch, he turns it, let's say it's one of the ones that rotate. Now, does he do this? He think through that a lot? No, but the behavioral layer is kind of more innate and that's where well-understood signifiers, affordances those relationships are so super important. Then he performs some action, in this case we'll assume that it's one of these light switches that you rotate. So he rotates the light switch to turn it on and then he gets feedback. So he perceives, okay, the light turned on or maybe the bulb flashed, which he knows his like it burning out. And he interprets the results, okay, the light is turned on that's what's happened here. And then he compares this with his original job to be done of keeping reading, is this light level okay? Does this does this work for me? Or do I want to do something else? And so that is a way to unpack the user experience and the different aspects of it, which is critical to a test driven approach to usability. And so the idea here is there's a feed-forward process. This is the stuff to the left, this is what the user is going to go do to achieve their goal deliver on their job to be done. And then there's a feedback process, which is what our software for instance tells them after they do those things. And these kind of questions are ways of of alternatively understanding those steps. I would take take a moment and just sort of think about this and it's probably a lot of new information, and think about how it might apply to some of your work. Now, let's look at the vocabulary that we started with and how that applies to this process. Signifiers are really important for helping the user avoid unnecessary confusion as they're specifying these steps. Again, the idea is that the specification is pretty neat, they're not really consciously even thinking about it that much. And so this relationship between well-understood signifiers and the affordances they provide is really what's critical especially in the feed forward process here as for example reach up and turn on the light. Or I go and I'm trying to fill up the bathtub, I run the water and then I'm flipping this dial up and down and I know that that's just up and down and I can do it, I don't have to evaluate whether moving it side to side or spinning it around, opens or closes the tub. Constraints, help avoid error, and that's that's really this idea that the dial will only go up and down. I can't move it left to right because why would we let the user do that? That's just going to confuse them and cause them to make a mistake. Then the world, the light, the tub, our software is going to provide feedback of some sort to the user. Prompt specific understandable feedback is really important and should always be a part of your testing, did the user understand what just happened? Even if they if they did the thing right, do they understand what happened? Because that's critical to a good user experience where the user is not having to wonder whether they're all right and all done or they're unsure about that. And then interpreting the results is is likewise very tightly related to how well they understood what they were doing. It's tightly related to what results they're going to be expecting back. And that's how you achieve good work there. And then when they when they compare these results, this is really where they're going to be evaluating whether our proposition, our delivery is the thing that they want to use to do this underlying job to be done achieve this goal. All right, so that is the Donald Norman 7-step model and some of the key vocabulary around it. If you want to take a moment and kind of reflect on this think about how it relates to something you do or something you're building. I think that's a great thing to do right now. However, if you're sort of like well, I generally get this but I want to see how it applies. Well, that's what we're going to do over the balance of this lesson.
