As you think about how you're going to go from user story to perhaps wire frame to working software, I wanted to give you a little bit of a vocabulary in a way of thinking about what you're going to do that's structured and testable. The material we're going to use is from this wonderful book, The Design of Everyday Things, a seminal book about human-centered design. Here's this yucky old tub. Now, if we start to think about this dial, there's a few terms I want to introduce to you in the context of this tub dial. So the first one is a signifier, and this is the idea that when I see this tub dial, it signifies to me that I can flip it up and down. When a user sees that, the thing that you probably recognize as a dropdown box, it signifies to them, we think that they can click it and it'll do a dropdown. Like a little kid, for example, who's never used a computer, let's say, that's not true. So the signifier is the idea that we think it's going to signify to the user a certain thing. The affordance is the fact that it actually does that. This is a subtle difference but pretty important because it allows us to decouple what we think we're saying to the user with a given design item, and what it actually does and look for. If we find dissonance between those two things like they're not doing what we expect, then it's a way for us to just talk about that and understand it. A constraint, and these are important, is that the dial only goes up and down. So constraints are things we put in to help the user not do the wrong thing basically. Feedback is how the user knows what's happening. With the tub dial, we just see that the water level rises when the drain's closed and that it goes down when the drain is open. The mapping refers to this general idea that people know what dials are and that they're things that switch between two different states, on and off, open and shut and they look a certain way. What's important is that wherever possible, we use well understood mappings. Innovation is not about introducing novelty for novelty's sake. There's already enough risks in whatever you're going to design. Even if it's not a startup or a new product, you want to stick to well understood patterns and not force the user to learn about your software unless there's a super compelling reason which there rarely is. Here is how we can think about the process that a user goes through when they encounter these things. They have some goal, and the classic example from the book, Design of Everything is Donald is sitting in an armchair, it's dusk and there's not enough light coming from the window anymore. He creates a plan which is a relatively simple plan, which is, "I think what I'll do is I'll turn on the light." Then he specifies a set of actions. I'm going to reach up to light and turn it on. He turns a light on. Then the real world, our software or the light in this case, does certain things. So he can immediately perceive that the light is turned on. Interpret is that he understands, okay, what's happened is that the light is turned on. The difference between perceive and interpret is that visceral versus the behavioral action. For example, let's say light doesn't turn on. He's going to immediately perceive that, and then maybe the interpretive step is that he thinks, "Okay, what's happened here, either the lights unplugged or the bulb is broken or something." That would be maybe a little bit better way of looking at the difference. Compare is he had this goal, "I want to keep reading my book," and he figures out whether he's getting enough light or not. So if we look at this, here's just another way of thinking about this. We have a feed forward, the user doing things, and we have a feedback loop which is these various things. Do designers go through every single one of these things for every single thing they create? No, but probably most of them have some kind of notion of this as they think about the usability, the results that they're seeing in what they're doing. So signifiers help users immediately understand what they can do and how they might do it. So when we pick interface elements, we want to ask the question what interface patterns might the user be expecting to see here given the user story and the general contours of what they're going to do? Constraints help the user avoid unnecessary error, like do things that just don't make sense and an unnecessarily get into an error state. Perceive, it's important to have prompt actionable critical feedback, like, they see the message, for instance, on the screen that says, "You're good or you're not good," and they know what that is. Interpret is, don't tell them Error 5306, they don't know what that means. Tell them, "Hey, this certain thing happened or you're all set." Then compare is how the users decide have they achieved their goal, have they achieved their reward of our user stories. So we can think about this as the third clause of our user story, reward or third clause. That's how this relates to the user stories. Lastly, we'll go through the idea. These are sort of different levels of user cognition. We have the visceral layer, the behavioral, and the reflective that the user thinks about as they go through these actions. They relate to different mental processes that we have this layering, so that we don't overthink things basically and overwhelm ourselves. Well, let's talk about those briefly. Visceral reaction is how do you feel when you see this scary dog? Afraid, right? Well, that is your most primitive lizard brain saying you just know, this is bad. Get away from this dog. How about this dog? You feel okay about that. No, problem, no danger. That's your sort of visceral reaction. Let's look at the behavioral layer. Put your left hand up, just try doing it. But you probably didn't have to think about how you do that, you just innately know how to do those things. That's what we want to achieve for our user. We don't want to force them to think too much about what they're trying to do with our software because we're trying to make things as easy and rewarding for them as possible. Then finally, the reflective layer really ties very directly to that third clause in the user story. I have a contact form on my site. So if we unpacked the layers, well, we want nice clear consistency. When somebody submits the form, the interpretive layer would be, hey, they see the message, it says, "Message received." Then if we think about the reflective layer, then we need to go up a layer and say, "Well, why were they contacting me in the first place." Let's say they're looking for a speaker. What do they really want? Well, what they probably want to know is "All right, is this guy going to get back to me soon or should I try to find a couple other alternative?" So that might tell us things like maybe if we can manage it, we should always let the users know how soon we'll get back to them because their goal is not to submit a contact form. Their goal is to, for example, find a speaker. So those are just some ideas about how to achieve good usability as you go from idea to code, and some things you may want to think about as you're coding your prototype.
