So, what do we mean when we talk about design in UX? Well, I'd like to start by thinking about how the term design is used in common, everyday ways, and I'd like to do that by looking at what happens when we do a search on Google images for design. Well, what we see are a lot of visual images that are essentially decorations of some kind. If we scroll down, we can see lots of graphical images and some tools that are used for producing graphic images. And so, commonly, when people talk about design they talk about how something looks, maybe what decorations it has, what form it has. However, this is a very narrow and specific use of design. Steve Jobs once said," Most people make the mistake of thinking design is what it looks like. People think it's this veneer, that the designers are handed this box and told 'Make it look good', but that's not what we think design is. It's not just what it looks like and feels like. Design is how it works." Charles Ames, a well-known mid-century furniture designer said, " Design is a plan for arranging elements in such a way as to best accomplish a particular purpose." So, from these two quotes, we start to get a picture of design as being, first, a plan. So, a design is not the final product. It' s not the outcome, but it's a plan for producing that product or that outcome, and it's a plan for arranging elements and those elements will depend on the type of product that it is. So, the elements could be gears and pulleys, or it could be wood and leather. It could be lines and swatches of color on a page, or in the case of UX, it could be things like text, and icons, and buttons, and images. A design is a plan for arranging elements to accomplish a purpose. So, there is a purpose that this design is supposed to accomplish, and is supposed to help the users or the consumers of the design to accomplish, and ultimately a design is mostly about how it works and the functionality and not just about how it looks. Of course, it also includes what it looks like and what it feels like. The well-known designer and architect Buckminster Fuller said," When I'm working on a problem, I never think about beauty. I only think about how to solve the problem. But when I've finished, if the solution isn't beautiful, I know it's wrong." So, here, we see an echo of Steve Jobs point that a design is not strictly about beauty, but we see an emphasis on design being about solving problems. So, this brings us to our first major point, that design is about solving problems. So, what do we mean by solving problems, and what are the kinds of problems that design can solve? Well, let's look at an example. This is Zappos, which is e-commerce site that primarily focuses on selling shoes. They sell lots of other clothes now, but they started out selling shoes, and so what is the problem that a product like this is trying to solve? Well, it's trying to solve the problem that some people need shoes. Well, that's simple because it so happens that the creators of Zappos want to sell shoes. So, this should work out perfectly. However, the problem is a little bit more sophisticated than that because there's lots of ways that people can get shoes. They can go to a shoe store. They can go to lots of other websites to get their shoes. So, maybe we need to understand the problem a little bit better. Well, so, maybe it turns out that what consumers need is shoes that they can acquire conveniently without having to go out and go shopping and spend the time that it takes to do that. They want to receive them fast. They want to be able to get them within a day or two. They want to be able to find shoes that are in their style, that they actually like, and they need it to be reliable. They need to be sure that when they invest the time in going onto Zappos, that they're going to have a successful outcome. Maybe it turns out also that people don't know exactly what they want, and they need inspiration. They need to be able to be led to the choices that are going to be satisfying for them, and by the way there are a lot of different consumers who have different taste and were all different. So, this can lead to a more precise articulation of what the solution to this problem of delivering shoes to consumers might consist of. So, now, as the creator of this product, I might be able to articulate what I'm trying to do, as I want to be able to sell shoes faster, more conveniently, with more selection, in a way that's more personalized than the alternatives. I want to do it in a way that's fun and inspiring for people, so that they have a positive experience, and that they end up finding shoes that they enjoy and that delight them, and I want to do this across many demographics and styles. So, what we've seen here is we've gone from a very simple high level problem statement, and we've really unpacked it to understand more specifically what this product needs to accomplish. So, we've not only understood the problem better but we've understood better what the form of a solution needs to be. The design researcher, Bryan Lawson, who studied how designers work across many domains, across many years, has said that design is as much a matter of finding problems as it is solving them, and I would add it's about articulating problems in such a way that you can understand what the form and the criteria of a solution ought to be. So, we can look at a very simplified version of the process that we follow when we're designing. The first step is understanding the problem, and as we said making sure that you understand the problem well enough that you can envision what a solution would look like, what would the solution have to have in order to actually solve that problem. At that point, you can generate possible solutions. You can start thinking about different possible ways to solve that problem, and the goal here is actually to produce lots of different solutions that could be candidates for solving the problem. Given those possible solutions, the next step is to analyze, systematically, the solutions against the criteria that you established for what a solution ought to have, and select the ones that are the most promising, that can be elaborated and brought forward to the next phases. The next step is to embody those solution, which means to build some kind of a prototype that can be used for really understanding how this solution would work, and that can also be used for assessing whether or not we're moving along the right track. At the assessment phase, What you want to do is you want to find new problems, ones that you missed the first time around. Maybe you missed important requirements or you missed important constraints, and now you're going to go back to the beginning, understand those problems, generate possible solutions, and so on and so forth. So, to look at an example of how this all works, I'd like to show you a pretty cool project that I just came across recently. It's called 50 Problems In 50 Days. And it's this British designer named Peter Smart who traveled all over Europe and set as a goal for himself to do 50 designs in 50 days. Starting with understanding a problem in the morning, working through solutions and coming up with a prototype of a solution by the evening. So, one that I like is day 29. And he was staying at a hostel in Amsterdam. And he observed that at his hostel, the staff sometimes have guests who can't speak a language that they understand. So, there's this communication problem between the staff at the hostel and the guests. So today's challenge, he said was, ''Work with the hostel staff to develop a system to assist communication.'' So, he started out by sitting down with the staff and asking them to think of questions they are often asked by guests, and have them write them down on post-it notes and created just a huge number of the types of questions that they often have to answer on a day-to-day basis. So, this was part of understanding the problem and understanding in a more specific way going from the general problem of communication, to say, ''What are the specific types of communication we need to address?'' He went forward from there to organize those into different categories of questions. Say ''Well, are there themes or are there patterns that we could leverage when trying to come up with design solutions?'' And from that, he was able to organize a communication architecture to summarize the flow of interactions with guests. So, how did they go about figuring out what the question is and what type of answer the guest is looking for? And further, he went through to categorize these into key themes and actually asked the hostel staff to work with him to draw some of the key things such as luggage, checkout, train station, breakfast, and so forth. And look at how those could be communicated through pictures, since the problem is that people don't have a shared language that they can use to talk about these things. He then engaged in rapid prototyping. So, basically, sketching out and trying out different ideas that could be used to facilitate this kind of communication. And then ultimately, iterated through those to come up with this particular prototype, which was a book that could be used to facilitate communication. And the way it works is, a guest could take the book, they could point to whether they had a question or a statement, what was the type of question that they were trying to ask, was it about when something happens, why something happens, where it is or about the hostel staff themselves, and then from there could go on and ask more specific questions using these pictorial representations. So, in that simple example, just a one day very short example, we saw all of these steps except for maybe the last one taking place. Understanding the problem, generating possible solutions, analyzing and selecting from those possible solutions, and embodying those solutions in a way that could help both the designer, the hostel staff, and potentially other people assess whether or not it actually solves the problem. From there, you would ordinarily go on it, iterate, and try to refine and come up with better solutions based on what you learned from that. In some of the other lectures, we've talked about the iterative design process that we use in UX Research and Design to come up with products that deliver a great user experience. And I just want to point out that this design process that I've just described is aligned with the process that we've been talking about. So, when we talk about understanding the problem, that's aligned with what we've been calling the assessment phase, where we understand initially, what it is that people are doing? What works and what doesn't for them? And then using that to understand what problems we're going to solve in the design phase. Generating possible solutions is what we do during that initial design phase to try to explore the space of possible solutions, and towards the end of that design phase, we analyze and select the most promising solutions. In the build phase, we embody those potential solutions in the form of prototypes that we can then use with UX research methods to assess and find new problems that we can use in the next phase of design and build. So, what I've described here is actually a general design process. It can be used for designing anything from a tube of toothpaste, to an aircraft carrier. So, what is it that's special about UX design? Well, a couple of things. One is that the experiences in the systems that we're building are interactive. Which means that they're time-based, they occur across time. They're based around action-response rules and getting those rules, what happens when a user does X, is one of the critical things that we're focusing on and what it is that we're trying to design. So, to break that down more, thinking about designing action, that's about designing the command options or the things that users can do, and when thinking about the response part of that equation, it is about what information is presented and what new commands are available when a particular command is invoked? And as a result in UX design, where we're dealing with interactive systems, we're often contending with complex system behavior, which drives us towards this focus on usability. How can we make sure that people can navigate these complex systems in order to be able to accomplish the things that they need to do? In UX design, context is critical. So, understanding how and when and why people are using and interacting with our systems is critical to getting the design right. So, we need to understand the other interactions that people are having with other systems, with other devices, with other people, and the other things that they're doing when they're trying to interact with our systems. What other activities are they engaged in at the same time? And what other people are involved? So, looking at this design process that I introduced a few slides ago, and mapping it onto the UX design process, we can see that understanding the problem becomes very much about studying users and the tasks that they're trying to accomplish and the context in which they're trying to accomplish them. Generating possible solutions takes the form of sketching different design ideas, story-boarding to show how an interaction unfolds over time, wire-framing specific screens, and so on and so forth. Analyzing and selecting among the design solutions becomes not just about applying the criteria of the design problem as we've understood it, but also applying UX criteria. What is it that we know about what delivers a good user experience and what drives us away from that? Embodying the solutions is going to be about building prototypes, and we'll talk more about the different types of prototypes that you might build. And assessing and finding new problems with those prototypes is going to be based around applying specific UX research methods like user testing to be able to understand what those problems might be. So, to sum up the design process, and we'll be talking about this more in other lectures, is about understanding the problem, generating possible solutions, analyzing and selecting from among those possible solutions, embodying them in a prototype, and then assessing them to see whether we're on track or not, and finding new problems that we need to solve in the next phase.
