In this lecture, we're going to go through some of the more common methods that are used in user experience design. We'll let you take a look at these methods. We'll especially focus in on the level of fidelity that the given method provides in its model and then we'll help you learn enough about them that you can review and select them as appropriate for your own work. So let's dive into them here. The first one is one that you've probably seen before, design the requirements. Then there's some other familiar construction methods; wireframes, prototypes. Sketchboards might be new to you. Style guides, you may have heard of. I'm going to talk a little bit about paper prototype or Wizard of Oz testing, that'll help us test some of those lower fidelity prototypes that don't have all the detail there yet. We'll talk about parallel design, which is a really important tool for working through alternatives, and then we'll get into usability heuristics, design principles, the Laws of UX, and sketching, which is one of our best exploratory methods. Again, as we look at these methods, we're going to talk a lot about fidelity. Fidelity has a lot of aspects; how refined something is visually, how much functionality is represented, how much detail is there, how interactive or capable the model is, how much it represents data in the model. But really, when you think about low to high fidelity, just think about the additional levels of detail in functionality. That's a good way to summarize it. If you do a sketch, odds are it's going to have low levels of detail. You're not going to be able to actually press a button and have something happen. If you do a high fidelity prototype, there may be some real controls there and it may actually do some real work. That's really the range that we're talking about. Again, as you go to select these methods, you can think about how much time they take, how complex they might be. Specifically, what it is that you're trying to get out of the modeling. Again, the level of fidelity and how well the whole thing fits in your overall project flow. There is an order of application to these methods simply because usually in a design cycle, we start with low fidelity methods and work our way up. We don't usually make a full-fledged prototype before we've done some sketches. There's this order from sketching to wireframes to prototyping that drives us through as we make more and more detailed models. The first one we should talk about is requirements, though, and requirements, this is really on the border, probably, of research and design. When you're doing used cases, you're starting to build up your requirements for the system, usually, the fidelity of requirements is pretty high. You really want to get detailed in order to make the requirements as useful as possible. This is an obvious step, maybe. Certainly, if you've worked in an engineering organization, you've probably been exposed to the development of requirements in both waterfall or agile models. There is a point where you start to document specifically what something does. You do have different levels of requirements. But generally speaking, they're very specific, they're very distinct. They try to be complete and you try to make them well thought out. Also, you might go through the prioritization exercise for the requirements. When you look at design requirements, often they're divided into several categories. Functional requirements talk about how the system or the device will do something. Non-functional requirements might talk about how it works, and constraints might be limits, could be something like voltage or memory or what have you. Requirements also span a large range of different considerations. Requirements might be related to the business, to the user, to how the device operates, quality of service issues or implementation details. Most of the time, your organization might have some documentation approach for requirements. They may even use the automated tool. So you'll have to see how things are done within your own organization around requirements. The other thing about requirements that you might have seen before is something called the V. The V represents a couple of things around requirements. One, that as we get into our requirements, so we move from the user into the system, into the architecture, and into the detailed design, the requirements get more and more specific and more and more detailed. Then also, there's a corresponding test element for the requirements. If we're going to create a requirement, we ought to have a way to verify it or validate it. The V represents both the development of the requirements and the development of the tests. Wireframes are one of our most popular methods for putting together a picture of what an interface for a system might look like. You've seen this probably looking into webpage development, but really you can use this for anything that has a display or that's providing information to a user. The thing about wireframes is they're really focused on functionality. They don't generally include style, color, or graphics. Although if you increase the fidelity of the wireframe, you might. Generally though what you're therefore is thinking about navigation, exposure of information, and how the different elements link together. Again, here's an example of a difference in wireframe fidelity. You can see in the sketch underneath that wireframes can be very rough or they can be very finished or somewhere in between. A lot of times wireframes will use filler text. You've probably seen the lorem ipsum, nonsense text that people use to represent blocks of paragraphs, etc. Then again, as fidelity might increase in a wireframe, you might be more careful about dimensions or some behavior or what elements on the wireframe actually do. Prototypes are somewhat similar in that. You can do very low fidelity prototypes, you could also do high fidelity prototypes that are very close to a functioning device. The low-fidelity prototypes often you can do on a sheet of paper. In any case, you can certainly use a prototype both to envision how something looks and also to dig into how something works. We often talk about "Looks like" prototypes and "Works like" prototypes. Looks like prototypes might be, again paper, they might be 3D prints. What have you? Works like prototypes might be something that you put together with a single-board computer or a devkit that's an ugly board to look at, but has the functionality of the device that you eventually want to produce. We're going to spend quite a bit of time in one of the other classes talking about rapid prototyping and ways to get through these cycles effectively. I'd like to line up sketches versus prototyping, just to remind you that the act of prototyping usually is driving towards the refinement of a product model, whereas sketch is usually exploratory, and we're trying to propose things, talk about things but not really commit. Sketches are usually done much earlier in the process than a prototype. A sketchboard is a method from the Boullee book, which talks about putting sketches of a proposed system up for everyone to see, and then using that sketchboard as a place to gather notes, gather questions, and also bring people up for organized reviews. In the reviews, she says, "There should be no butts in seats. Everyone should be up and engaged and looking at design issues and bringing up questions." This is nice because really, you're making a very public view of your design and you're giving people a chance to dig into it and comment on it. A style guide is something that you're using to keep bounds on a design, to make it look like something you intend it to be. Often, you see style guides in terms of web-pages, say Google's Material Design, which I talk about a bit here, a really great example of a solid style that can be applied to a web-page. You probably recognize it when you see it, but it's very clean, very consistent. You could create a style guide for almost anything you develop and you could talk about, for instance, for a device, what types of buttons, what sort of spacing, mechanical concerns, how the device responds to certain situations. You can look out online there's a link here for a 193 different style guides. Most of them are web-related, but it's still nice to take a look and see what the style guides have in them, and how they support your work. Again, paper prototyping or Wizard of Oz testing really talks to testing something that's not functional. So if I put a piece of paper in front of you that has a sketch of a device and I ask you to perform a task with that device, you might tell me that you would push that button, but of course you can't push it. So someone in the test has to take the role of the computer or the device and respond by saying, ''Okay, if you push that, this is what's going to happen.'' Usually, these kinds of tests you would do with someone in that role acting as the device, then you would have a facilitator, you might have an observer too and you'd have a user. These tests are extremely valuable because you can drive through trying out tasks on an interface almost before that interface exists, because all you're really working with, is a paper copy of it. This is a very powerful technique, something that you can use for anything that has limited functionality. Parallel design is a way to drive through a number of design options by creating different sketches and then evaluating those sketches for what's best about them. Ideally, it's a group exercise where you have lots of people developing lots of ideas, and then you bring the group together to look at what's best in class from each of those ideas. You could also do it as an individual activity, create some alternatives and start to think about which of those alternatives really represent what you're trying to get across in the design. Usually, if this is a lower fidelity exercise because you're sketching, you could do something like this though, with higher fidelity prototypes, but usually by the time you're at that level, you've already made these sort of decisions. So this is really intended to be somewhat exploratory and to get you through honing in on what that final design will look like. So I know there's a lot to digest here and we haven't finished, we're going to do two more lectures about usability heuristics and about sketching, but I want you to take some time to think about what's in this lecture and how these tools might apply to what you do when you're creating an embedded device or a system. All of them are important and all of them are useful and they really could get you to a point where you can drive through a design fairly quickly and yet give people a chance to give you that critical feedback that gets you to something user centric that everyone will appreciate. So again, we'll follow up with two more lectures here on heuristics and on sketching and then we'll get into the Project for this cycle. Thank you very much.
