The web site of jiawp

UX Fundamentals

Understanding Your User UX Overview Hello. Welcome to UX Fundamentals. I'm Krispian Emert, and I look forward to teaching you about how to make the world a better place through UX. I'm going to go over the course overview, but first, let's talk about user experience, or UX, what it is, and why it's important. Now you can love or hate Apple, but there's no denying that lately the most successful companies have differentiated themselves through a good user experience. Good user experience is about how it works, not just about what it looks like, and that's why I chose this quote, and that's what this course is about. I'm going to teach you the tools to create something that works great on any device, as opposed to just looking great. Let's play an imagination exercise. Think about the websites and apps that you use most often, and why you use them so often. Is it because they're easy to use, they allow you to do what you set out to do? Now think about frustrating websites. What's the last site you visited where you were really frustrated? Or think about an app you downloaded that didn't live up to its promise. The difference between the good experience and bad experience was probably due to whether the designers followed a user-centered process or not. That's what this course will teach you about: taking a user- centered design approach to UX design. Not just about UI design. People confuse UX and UI all the time. Think about the sites that are easy to use. You probably didn't like them because they had a beautiful interface. Similarly, thinking about the bad user experience you had, it wasn't due to an ugly interface, it was because you couldn't find something, or it was hard to complete a task. So that illustrates that a great or a poor user experience isn't about the UI, it's about the fact that you were able to easily complete a task, and you felt pretty good about doing it. So just to define user experience or UX, it's basically designing great experiences for users, and this course will show you what it takes to create great experiences. It doesn't matter what device. It could be a mobile device, a smart watch, a kiosk; the principles of user- centered design considering the user, their needs and goals, fully understanding the problem you're trying to solve, and improving your designs based on user feedback can apply to any device. Now before I show you how to create great user experiences through user-centered design, let's talk about what contributes to bad UX, some impact to user experience. Number one: designing for yourself, not considering how others would use the design. That's also known as design-centered design, and it's the opposite of user-centered design. Another impact user experience: thinking that the user experience is merely an interface. A pretty UI doesn't always result in a great experience. Now, user-centered designs are based on an understanding of your users. Understandings and insights, and unless your designs are driven by user insight, if you're just thinking about the interface, you're basically just moving deck chairs around on the Titanic. And speaking of the Titanic, here's a very common model that we use in user experience design to illustrate why we shouldn't focus on the user interface, and actually my colleague here on Pluralsight, Keith Harvey, has a great course called Hacking the User Experience/UX for Developers, where he talks about this iceberg model, and has some really great things to say about it. Basically what it means is the user interface is like the visible part of an iceberg. Everybody can see it, but there's actually a great deal of depth below the surface that people may not be aware of, but it certainly impacts the user experience. And so all of these disciplines and activities that go on underneath the surface are what I'm going to cover in this course.

UX and Its Place in the Development Cycle Let's talk about where UX fits in to the development cycle. During the first stage: planning, user experience can help you define the problem by understanding user's needs, goals, and motivations. It will help you design the right thing instead of just designing the thing right. During analysis, understanding your users will help you prioritize features based on what users actually want instead of wasting time developing something that nobody needs. During the design phase, the ideating, prototyping, and iterating based on user feedback, that's the hallmark of UX design, is a low-cost way to see what works, and again could save you money in development. Finally, during the implementation and maintenance phase, user testing: analyzing user feedback to improve the product will help you create great experiences. Now I'm going to teach you about user experience using a medical analogy. For example, in medicine you can have many specializations, but it's a general practitioner understands a little bit about each specialization to keep the patient healthy. Similarly with UX, we want to create great experiences, you don't need to be a specialist in any of these disciplines, but have a little understanding of each, and that will help you create great experiences. Interaction design deals with structure, and also is concerned with how interface elements respond to user input. Content is the words, pictures, and other information that make up experiences. Content strategy ensures that this information is current, relevant, and useful. User research: understanding human behavior and empathizing with user needs is crucial to designing great experiences. Business objectives: taking time to fully understand the business objectives and clarify the problem to dispel any assumptions is essential before you begin to design experiences. Information architecture: information architecture ensures that the structure and navigation of an experience allows people to accomplish tasks and find information easily, and then finally, visual design is concerned with the look, and feel, and the branding, and the colors of the final piece. Let's talk about what you need to take this course. No fancy tools or software is needed. All you need is a pencil, sketchbook, and most of all, a curious mind. Designing great experiences is not about the type of tool you use, it's about cultivating a curiosity about people; how they think, what are their goals, needs, and motivations? How do they use products or services? Having this curios mind will be an asset in user experience. Let's talk about what we're going to learn in this course. Module one: UX Overview/Understanding Your User. In module two, we're going to learn about communicating the big picture through user journeys and storyboarding scenarios. Module three is all about wireframing, sketching out interfaces. Module four is about creating a prototype, and we can make a quick and easy one on paper that we can use for module five: usability testing. During this course, as well, you're going to do a lab assignment. We're going to do a fun activity together and design an application. During the first module, together we will try to understand user goals and create a strategy document. In module two, we're going to sketch out interaction flows and a user journey. Module three, we'll be sketching wireframes, and module four, create a paper prototype, and in module five, conduct a usability test. Let me talk about how some of these lab activities are going to help you understand the various disciplines and specializations of UX. For example, when we create the strategy document in module one, we're going to cover business objectives and user research. Interaction flows and user journey are going to cover information architecture, content strategy, and interaction design specializations. When we sketch out wireframes and prototype, this will be using information architecture skills, and interaction design skills, and a bit of visual design, and finally, conducting usability testing falls under user research. Now that we've done a UX overview and covered what's in this course, let's talk about the first module: Understanding Your User. Now we've covered the elements of UX and its place within the development cycle, now we're going to learn quick and easy user research techniques that will help you to empathize with users and understand their goals, but first, we're going to do requirements gathering. Learn how to consider business goals and the technical limitations, and combine these with user goals to create a strategy document. The strategy document is our first lab assignment. We're going to learn something called an Empathy Map, and use it to derive the user goals. We're then going to find the business goals by conducting business requirements gathering to create a strategy document. So let's get started with business requirement.

Business Requirements It's important to start by clarifying business requirements. Any project needs to make money, even if it's a non-profit, you still need to clarify the business requirements, because you want to be successful, and that means clarifying goals before you start designing. You would be surprised at how many important decisions have not been made by the time you've been asked to design something. Now Andrew Hinton says that the interface is used as a proxy for difficult decisions, and I think that's true. If some of the important decisions have not been made and you have to start making them when you're designing the interface, then guaranteed there's going to be some impact to the user experience. So what I've designed for you here are some of my favorite questions that I ask during any kickoff to get the business goals from the stake holders. These business requirement questions are what we're going to use during our lab assignment for this module. These two questions at the end are very important, and you'd be surprised at how many business people haven't really thought this through. So it's important for you to ask these questions, and if they're unable to answer it, then that builds a pretty good case for conducting user research so that you can answer these questions. That brings us to user research.

User Research So let's talk about, What is a user? Users are known by many names. They could be your customers, your viewers, you can call them the audience or your clients, whatever your organization calls them with is okay. We call them users because that's a handy shorthand here in the field of UX. So I'll be using the word user from now on. User research means having a curiosity about your users. Really trying to figure out how they behave. What are people like as they go about their daily business? If you're trying to design a better system for how an artist works, you really want to understand how they go about creating their art. If you're designing a business application, you want to go on the job and see how they actually work. This is observing versus asking. This is key to proper user experience research. You want to observe people in their natural habitat and see as they actually go about their daily work as opposed to just asking them about what their opinion might be on a great experience. If you were to ask somebody, how can I design you a great experience? You would not get the insights that just observing them as they go about their daily business would get you. And here's a handy tool called an Empathy Map. This is going to help you ask the right questions as you observe somebody during your user research. So an Empathy Map is a handy device that takes a person's head, and you actually divide up the paper into what they think and feel, which is above their brain, what they see, which is in the area where the eye is. What they say and do, which is where the mouth is, and near the ear, what they hear. You also want to observe what are their pain points: their fears, frustrations, and obstacles, and what are their gains, meaning, what are their wants, needs, or success measures. So armed with this Empathy Map, you can go out and observe your target audience, and from this observation and taking notes on this Empathy Map, you're going to get some really great information that will form the basis and the insights from which to create good experiences. I'm not a big fan of Personas, only because they've been used inaccurately in our industry. Basically, if they're works of fiction, they're not very useful. Another thing that's not very useful is designing for demographics. Now, things such as age, income, occupation, geographics, and education; these are really important things for the business, and they're very valuable for marketing, for example, but they're not useful for user experience design, because it's kind of hard to design for demographic. What I want you to think instead is to think about archetypes. If you go out and do your observational research, and fill in those Empathy Maps, try to create an archetype that's based on why a person would use your product or service. What are their behaviors, what is the environment that they're in, and especially what are the goals, needs, and motivations? You can boil your archetype down to this statement: the user is a blank who wants to blank. Once you fill that out, you will have a quick and easy reference system that will help you design towards people's goals as opposed to demographics or a lengthy persona.

Lab Project - Strategy Document It's time to do a lab project. Grab your sketchbooks. So for this entire course, what we're going to do is design an app for Pizza Pies Unlimited, and for module one, we are going to define the user goals and create a strategy document together. Here's your brief. You've been hired by Pizza Pies Unlimited. They want you to design an app that allows customers to order pizza. They want their customers to be able to choose a pizza from their menu, they want the app to send an email to the restaurant, who will then make the pizza and have it delivered, and they're thinking that to make things simple, they'll just have the customer pay the delivery driver. They also want the app to be able to be used on any device. Now, if you just went ahead and started designing an app based on these vague business requirements, you might run into a problem, because the pizza app that might be forming in your head may be very different than what the stake holders are forming in their head, and that's why we create documentation in user experience, to ensure that we're all on the same page, and we're all in alignment. But remember the business requirements questions that I brought up earlier. Let's pretend that we're now interviewing the stake holder and getting some requirements back to gain some clarity. So some examples of this would be to ask and get clarity on what are the goals for creating this pizza app? And the stake holders, say you're talking to Luigi, the owner, and he says, well the goals are to make more money, and that's a standard goal that most businesses have, but you want to get clarity on that. So you want to ask, exactly why are you creating a pizza app instead of just sticking to the old telephone method that you always had? And so he might say something like, well, I want to create something that's really engaging and fun, that makes pizza ordering a really great experience. Oh, okay, so here's something we can design towards, and then you may ask, how will we know when this has been successful? You said you want to increase sales, let's talk a concrete number perhaps, and so he might say, okay, let's increase sales by 5%. Good, this is something that we can measure, we can measure the success of your UX design. Another important question is who are the users? Who's going to be using your app? And most businesses will say, well everybody, but the rule of thumb in user experience design is that if you try to design for everybody, you end up designing for nobody. So it's very helpful to target your designs to target audiences, and so interviewing the stake holder, he might say something like, well, I've noticed that most young people are always on their phones and younger people don't seem to like talking on the phone or ordering, they prefer to send texts or use apps on their phone, so I would like to target a younger crowd. Oh, okay, well here's something we can design towards, and then delving deeper, you would say, well why would customers use this pizza app instead of calling it in old style? Or, what problems are they having that this app will solve, or what are you hoping to gain from this? And the stake holder may say something like, well, we have lots of new and exciting menu items and that takes a lot of time and money to print onto our paper menus, and people don't often notice it on our old website, so this is app will make our new menu items really easy to see because they're always changing and the ordering process should be fun. We want to make pizza ordering fun. Okay, so this is actually something that's a lot easier to design for than the vague requirements given earlier. So now it's time for you to pull out your sketchbook, and if you don't have a sketchbook, it's okay to use a stack of paper, if you have printer paper. So the first thing we're going to do is we're going to write down the business goals that have been clarified. So based on everything the stake holder said, you can now summarize them as such, and you can write this down with me. The business goals are to increase the sales by creating an engaging and fun experience. Another goal is to expose more menu items and expose new items to customers. He wants to appeal to a younger audience, so there's our target, and he wants to increase number of sales by 5%, and that's something measureable we can work towards. So it's up to you to find out what the current number of sales are so that you can measure the sales when this app goes live. So that's our business goals, that's one-half of our strategy document. Now for the other half, we're going to find out what are the user's goals, and this is where you get to do a bit of homework. Now remember the Empathy Map that we learned about earlier, what you have to do now is take your sketchbook and draw this Empathy Map, and draw one for each person that you plan to do research on. Now, as to the number of people to go out and study, you want to do your research on younger people, comfortable using apps on their mobile device, and as to how many, this is a question that often gets asked in the field of user experience. When you're doing this kind of empathetic qualitative research, you don't need a lot of people, you don't need the statistical numbers that market research does with the large numbers. With this kind of research, you actually get a lot of insights from very few people, and so the number that I like to use is about five to seven people per major target audience, but for your homework, I would say one or two is fine. Just to get you in the habit of doing this kind of research. What I want you to do is observational research. Find somebody who's going to be ordering a pizza. What's important is that you can follow along in this map and observe people as they actually undertake the process of ordering a pizza, as opposed to asking somebody what it was like to order a pizza in the past, or getting them to imagine some future ordering, because that's not grounded in reality. What we want in this user research is for it to be grounded in reality. As you're observing somebody order a pizza, follow along with the Empathy map with all the prompts that are written here. For example, think and feel, find out what matters most, what's the most important thing when ordering a pizza? What sort of things are they worried about? What things make it successful? As for see, it's really important to know the environment. Not all the designs we create are enjoyed in a pristine and distraction free environment, and in fact, for a lot of mobile designs, as Luke Wroblewski says, "It's one eye and one thumb that you're designing for," because a person's walking down the street and they've only got one thumb to use your design. So, consider the environment. Consider some of the things they're already using. Are they already using competitor apps to order a pizza? And from that, figure out what works and what doesn't. What kind of things can you avoid? And then you can go around and notice what they say and do, and notice what they hear, but especially note down the pain points, the frustrations and obstacles, and the gains. What sort of things are working really well, and that will give you some great basis from which to design from. Now once you've done a couple of these observations, what you can then do is fill out the user goals. So fill out about four or five user goals that are based on the Empathy Map. For example, the user goals could be the pain points, the frustrations, what the person's environment is like, and what matters most when ordering a pizza. So these are the kind of things that you want to fill out for your user goals, and then once you've done that, you can fill out this archetype statement. For example, if you have a houseful of teenagers and you're observing them as they order pizza, and you know that they're often cash-strapped, you could write a statement such as: The user is a hungry teenager who wants to get pizza cheaply. And that'll give us a nice, handy reference to design towards as we move forward in this course. So this is your strategy document. I would like for you to have it filled out by our next module. The strategy document will form the basis for all the other lab assignments that we do for the rest of this course.

User Journeys and Scenarios Module Overview Welcome to UX Fundamentals, Module 2: User Journeys and Scenarios. I'm Krispian Emert. Let's go over this module. For this module, we're going to review the strategy document and also clarify user's goals. During this module, we're going to learn about user journeys, why we make them, and how to make them. Scenarios break down the journey and help us identify features that will make our app useful and usable for users. Then I'll show you how to communicate in storyboard format even if you can't draw. Finally, flows ensure users can move throughout the site and accomplish tasks. Let's start with a review. In order to continue the design of our app, we need to carry forward the concepts learned in the first lesson. In the last module, we built our strategy document combining user needs and business goals to help us create something that makes business sense. We used the skills of user research and gathered business objectives. To reiterate, user experience is not just about the UI, good UX helps users easily accomplish tasks and hopefully feel pretty good while doing it too. Remember the brief from the last module? Our brief was to design an app that allows customers to order pizza, where the customers choose pizza from the menu, the app will send an email to the restaurant, the customers pay the delivery driver, and the app needs to work across multiple devices. Now we could take that brief and jump right into designing the interface. Let me show you why this may not be the best idea. Let me give you an example. Designing right from the brief without investigating further into the business schools or learning about our users and their goals could result in something like this. So looking at the brief, it says that customers need to choose pizza from the menu. So, why don't I just recreate the restaurant menu into the interface? Looking again at the brief, it says that the app is to send the order to the restaurant. So I'll put a nice, big send button on the interface, and then the brief states that the customer pays the delivery driver. Easy, I'll just notify user that they need to pay the driver in the interface. Since the brief also requires multiple devices, I'll take my initial ideas and start laying them out for the web as well. Am I designing the best possible experience for the business? For the users? Let's revisit the strategy document from our last module. To review, the business goals are to increase sales through an engaging, fun experience, to expose more menu or new items to the customers, to appeal to a younger audience, and to increase the sales. Now if I were to look at just the business goals alone, I may revise my interface to better reflect these goals. For example, the goal of creating a fun, engaging experience that appeals to younger users. I could come up with an idea. Maybe a wild idea. How about a feature where if I shake the phone, you could create a pizza with random toppings. I think that would be engaging, and I think that might appeal to younger users, but wait, is this what users really want?

User Research Review and User Goals Let's review what we learned about user research. In the last module, I encouraged you to go out and observe people as they ordered pizza, from start to finish, so that you could understand the process and some of the problems they may encounter. Now, your own observations may vary, but for the sake of illustration, let me tell you what I did. Since the business identified they want to appeal to younger audience, I went out and observed five younger people as they ordered pizzas, from start to finish. I took note of what worked for them, and what some of the pain points were. As I observed them, I took notes, and then I put these notes onto my Empathy Map. For example, what matters most to them? What's their environment like? What are the current tasks? And what are their friends and influencers saying? For example, I learned that reviews are very important, and that most people won't even consider a new restuarantant without reading the reviews first. As for some of the pains, I learned that when they order a pizza, they really hate searching around for cash, and they find it frustrating to try to figure out how much to tip the driver. What worked for them were that they really liked the restaurant specialty menu, and they really like apps where payment is made easy. So I took these observations and I put them into this archetype worksheet. For example, to distill down all my observations about why they would use the product, an example could be to make their life easier. The behaviors and environments could be summarized as a lazy Friday at home. The goals, needs, and motivations I'd summarize as get me food as quickly as possible, and as for all the people I observed, I distilled them into this archetype statement that the user is a hungry person who wants to order pizza with very little effort. Let me summarize the user goals based on what I observed. Before they order pizza, they used reviews to know if it's a quality establishment. During the pizza ordering process, I notice that they really like the specialty menu, and they like to see a good selection of toppings. When the pizza arrives, they want to pay without searching around for cash, and they don't want to worry about how much to tip. So now we can complete the strategy document with the business goals and the user goals, and fill out the archetype statement. Armed with this kind of knowledge, now we can really begin to build an app that will be useful and usable for users, but how do we communicate how the whole thing works? For example, my previous idea of shaking the phone to get random toppings doesn't make any sense in view of the fact that these are hungry people who are in a hurry to get a pizza, and they want to spend very little effort. I'm going to revise my approach to this app, and I'm really going to focus on the user goals. In order to communicate how the whole thing works, we need to look at the big picture.

The "Big Picture": Why We Need Scenarios, Flows, and User Journeys Remember that you want to create a great experience for users. That means taking a step back from interface design, and focusing on the big picture. Remember the iceberg example from the last module? Great user experiences happen when all the disciplines and activities are considered, not just the tip of the iceberg. In the earlier example, when I jumped right into interface design, I was considering the interface only; the tip of the iceberg so to speak. I was not considering my users and how to make life easier for them. For this course, we're going to consider all of the activities and disciplines beneath the service. Now we've already gathered business objectives and conducted user research to form our strategy document. Next, we're going to learn interaction design, information architecture, and content strategy. Together, these disciplines help design how the system works in its entirety. What is the intent of what we're trying to make? But how do we communicate this? It's hard to communicate the intent of the entire system from just looking at drawings of an interface. That's why we're going to learn user journeys, scenarios, and interaction flows. These will combine the disciplines of information architecture, interaction design, and content strategy. Let's learn about user journeys.

User Journeys Jumping right into sketching interfaces or wireframing means that you'd miss an opportunity to find delightful experiences, delightful features that will help users accomplish their tasks easily. Mapping out the user journey will help you define the customer experience of your design from start to finish. A user journey could be defined as a map of the actions and emotions that your user experiences while using your designs from start to finish. User journeys come under many names, such as Customer Journey, Journey Map, Experience Map; everyone has a different name for it. If you're mapping the journey from start to finish, this would be User Journey. User Journeys define the motivations for using your app, they define the problems that your app solves for the user, they define the different phases of your app, and they define the experience from start to finish, as well as emotions and feelings that the user may have along the way. Let's look at some examples. This Rail Europe Experience Map is a very famous map, it was made by Adaptive Path, and if you do a search online for experienced maps, you'll see this, because it's a classic example, it does a great job of showing cyclical actions, as well as linear. It's a very complex one, and probably not one that we need for students to do, but it shows you what a professional map looks like. So, to help you out, I've come up with this Journey Map template that you will find during the lab portion of this course, and it will help you plot out your Journey Map. You'll see that the different stages are accounted for, and along each way for each state, you can specify the user goals, as well as details and perhaps something about the environment, and maybe what's going through the user's mind along the way, as well as their emotions. If any ideas come to you as you're mapping this out, feel free to write them down here. Now bear in mind that you want to make this as realistic as possible, based on the user research that I taught you in earlier courses. So here's an example of filling out the Journey Map. In this example, it would be for an app that is for creating a dictionary app for, say the iPhone. So stage one, you'd have the trigger for finding the correct word, state two, you may also need reverse dictionary functionality, stage three, perhaps ideas on how to use it in a sentence, and stage four, completing the task. And so you can see how the details and environment are filled out, as well as what might be going through the user's mind. Their emotions are plotted out according to what's going through their mind, as well as ideas and recommendations.

Scenarios and Flows Let's talk about scenarios. Scenarios can be defined as outlining specific areas of functionality. You can define what does the system need from users for that particular scenario, and also, what do users need from the system for that particular scenario. Let me show you some examples. Here's a handy template that you can use during the lab portion of this course, and you can fill it in for your particular app. Let me show you an example of this filled in for the example of the dictionary app used in the last example, so if you think about a User Journey sort of encapsulating the entire story start to finish, you could think of scenarios as individual chapters from that. And so for that dictionary app, you can see that the scenario has pulled out, using the reverse dictionary feature, and what the problem and desired result are. You can sketch in how the user would use this particular feature, and how they might feel. If you think of a User Journey as say, the book from start to finish, scenarios could be individual chapters. Storyboards. Illustrating something in comic book format. They clearly show the context, and the user is the star of the storyboard, as opposed to the interface. Here's some examples. In this example, you can see the context of an app that helps people, the user, it has a trigger, and a need for the app, and there's a problem and a resolution. Communicating in this format is very effective, because it's very accessible and everybody can immediately understand what it is you're trying to communicate. Here's another example. This time for an app that helps people during earthquakes. As you can see, the user is the star of this scenario expressed in storyboard format, as opposed to the interface. There's nothing wrong with showing a bit of the interface, but as you can see, it clearly shows the user in their context, and the problem that they're experiencing, and how the app may help them, as opposed to focusing on just drawing the interface. Again, here's another example how you can see how this app clearly solves a problem. Now you need not necessarily have to have skilled drawing experience in order to be effective at drawing storyboards. In this example, the user is represented by what's called a star person. Draw a simple star with a circle on top, and that could represent your user. Very easy to draw. Flows. Flows can be defined as a way to show how users move through the system, show the ideal path through the system. You can even outline edge cases, flows can be high level or granular, and let me show you what I mean. So for example, in the dictionary app that we've been using as an example, this is a basic flow. A basic flow of how you would go to the first screen and see the splash screen, and then you can either look up a word, or go to the reverse dictionary, and then see usage examples. Very high level. This is a flow of a login. In order to go to the homepage, you must log in successfully, and this is how you would draw the flow that represents that. Here's a flow for a checkout process, say, for an e-commerce site. This example shows what happens if perhaps there's a login failure. Here's some basic flows that show what happens when you need to display errors on various interfaces or notifications. As you can see, there are very many ways of representing flows, and storyboards, and scenarios. Use your imagination, there's no right way to do it.

Lab Assignment Now it's time for your lab assignment. For your lab assignment, you're going to create a storyboard that represents your User Journey, a couple scenarios, and flows. In order to help you, you can print off these templates. You can print off the template of this Journey Map, and write down the user goals, details and environments, what the user's thinking, their emotions, and any ideas that occur to you as they move from stage to stage. Don't feel like you need to fill out this entire template. If your particular app doesn't have six stages, then don't fill the need to fill it out with six stages, just fill out however many you feel work for your app. You can then fill out this template for scenarios. Remember, think of scenarios as pulling out individual chapters from a book. If your Journey Map is the book from start to finish, say the synopsis on the back, then the scenarios are the individual chapters. Each scenario should have a problem and the desired result. And here's a storyboard template for you to fill out. Remember, you don't need to have any professional level drawing skill, star people are all it takes to communicate your user.

Wireframes Review and Core Concepts Welcome to UX Fundamentals: Wireframes. I'm Krispian Emert. Let's go over what you'll learn in this module. First, we'll start with a review, and then go over core concepts of wireframing. I'll go over a few definitions, and then I'll show you some industry standard tools and best practices, and finally, we'll do a lab project together. Let's start with a review. Remember too, that user experience doesn't necessarily mean the user interface, that it's a whole lot more. Remember the brief. Let's design an app that allows customers to order pizza. To allow customers to choose pizza from a menu, the app would send an email to the restaurant with the order, the customers could pay the delivery driver, and the app should work on many devices. Core concepts. I love this quote by Dieter Rams: "Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design." And what that means to me is that if you design without considering the people who are using your designs, you probably won't end up with the best result. Let's play a game. There's a really fun website called dedesigntheweb.com that I encourage you to try out. I grabbed a few examples from it to show you, so we could play this game where you guess the site from its wireframe. Can you guess what this one is? What about this one? Does this website look familiar? How about this one? Number five ring any bells? Or number six? For the answer, go visit the site and see for yourself. What all these have in common is they show you some examples of wireframes. Showing the interface of a site without the visual design defined, so that you can focus just on the functionality and how it works rather than how it looks. Here's some definitions of wireframes. It's a visual representation of an interface. You strip away the visual design so that the focus is on the function and the user interactivity. What happens if we have a lot of visual design in our wireframes, then people focus on the visual design, on how it looks rather than how it works. I like to think of wireframes as a blueprint. Just as a blueprint for a building won't define the interior decoration, it doesn't talk about the color of the drapes, or the carpet, etc., neither should your wireframes focus on visual design. Looking at our examples from before, here's how wireframes could be expressed when you draw them out. I want to talk a bit about wireframing versus wireframes. Wireframes are usually a deliverable that you would hand over to engineering teams to have them build your system, build your app or website. Just as blueprints are handed over to a team of builders so that the physical structure can be built, your wireframe is a deliverable or document that is handed over to teams. On the other hand, wireframing is the act of sketching, it's the act of sketching interfaces and sketching ideas as they occur to you. I encourage you to engage in the act of wireframing as much as possible, but save your wireframes until the end. In fact, a formal wireframe document is probably best created after you've done prototyping and testing, and refined your ideas. But there's nothing wrong with sketching your wireframes right from the beginning.

Wireframing Tools Let's talk about some of the industry standard tools that are used for wireframing. So I found this great resource online at creativeblog.com where they did an audit of all the different wireframing tools, and feel free to look around there and see what they have to say. What I recommend for wireframing is InDesign. InDesign is great for wireframing because you can set reusable areas, like your navigation, and have them repeat across many pages. This is why I don't recommend using Photoshop or Illustrator for wireframing because you're going to have to redraw elements over and over again, as opposed to just using masters the way you would in InDesign to keep things consistent. Another tool is OmniGraffle. OmniGraffle is for Mac only. If you're using a Mac, it's an excellent tool. It has a library of interface elements that you could drag and drop to make wireframing easy. Another recommended tool is Balsamiq. Balsamiq solves one of the problems we have in wireframing in that some people think that when you show them a wireframe, that's the finished design. So Balsamiq deliberately makes their interfaces look hand-drawn and sketchy, so that people know to focus on the function rather than the final visual design. Balsamiq is very easy to use and it's just drag and drop. Another tool is Visio. Visio has a bit of a learning curve, but if you have a PC with Microsoft Office included, Visio is often already installed on computers, so it's something you can use right away. Now let me talk about what I don't recommend. There are many tools to allow you to make quick and easy iPhone mockups, and the reason that I don't recommend them is you can see that the design is constrained by the bottom of the iPhone device itself, and so every design you come up with has to be forced into that small area. As we all know, when you use an iPhone or other device, quite often the screen can be quite long and you would scroll through it, but when you're using a tool like this, you can't make long screens at all. Now the most recommended tool of all is of course, pen and paper. Get sketching right away. Sketch often. Generate lots of ideas. Let's talk about wireframes versus prototypes. What's the difference? Like I said earlier, I think of a wireframe like a blueprint, so if a wireframe is a lot like a blueprint, then your prototype is a lot like an architectural model. When we're talking about physical structures, blueprints and architectural models are each ways of visualizing the final structure. Similarly, wireframes and prototypes help us visualize the final structure of what we're designing, when we're designing spaces made of information.

Best Practices Let's talk about best practices in wireframing. Now remember, we're not designing pages, we're designing systems of components. I love this quote by Stephen Hay. In order to better design systems of components, let's turn to a method devised by Brad Frost. Brad Frost came up with atomic design, and I'm a big fan of it. Atomic design is a methodology for creating design systems. So Brad Frost came up with five levels: atoms, molecules, organisms, templates, and pages. Atoms are the basic building blocks of matter. You can apply atoms to web interfaces. Think of them as HTML tags, such as a form label, an input, or a button. You can see that these atoms, when taken separately, are not very useful; however, when you combine them to form a molecule, things start getting more interesting. Molecules are the smallest fundamental unit of a compound. These molecules take the properties and service, the backbone of design systems. In the previous example, a form label, input, and button aren't useful by themselves, but when you combine them together, we make a search the site molecule, and that can be reused all over your system. Organisms are building blocks. When you combine different molecules, you can join them together to form complex, distinct sections of an interface. In these examples from Brad Frost, you can see different organisms: headers of a site which are comprised of search the site molecules, or navigation molecules, or the logo molecule. When you combine them all together, you have a header organism that's comprised of different molecules. So this is where Brad Frost's chemistry analog is broken, so that we can talk about templates. These are groups of organisms that are stitched together to form pages. This is where you see your design coming together, and you can see your layout in action. And then finally, pages. You can think of a page as an instant of a template. This is where you can start adding some real content and photos to see how it works. In terms of wireframing though, I want you to think about this level of fidelity as opposed to this level of fidelity. Remember too, to think responsively. In this example here, we have a responsive grid that is illustrated to show how it would respond and adapt to various device widths. Here's another example.

Lab Assignment Now it's time to do your lab assignment number three: Wireframes. What you need to create wireframes are, like I said earlier, the best tool of all is pen and paper. Here's what I want you to do. Thinking about designing your pizza app, don't just jump in and create a big blob of interface. Remember to think of designing systems of components. Think organisms. Think modularly. So first of all, define the common components. You can see here I've created a few organisms created of molecules. The molecule would be the navigation, or login area, or a location and map, and how I've combined those molecules into an organism for header, and how the header might change when people are logged in. So also think about different states. You may want to think about designing an organism of footer that's comprised of a navigation molecule. So define common components that would be reused throughout your entire site. Then, design a container that would respond and have those components inside of it. Place your components into the container. So give it a try yourself now. Open your sketchbook, and start sketching.

Prototypes Module Overview Welcome to UX Fundamentals: Prototypes. First we'll do a review of earlier modules. Then we'll talk about the benefits of prototyping, the different types of prototypes, the different tools for making prototypes, and then finally we'll do our lab project. Let's start with a review. Remembering all the different disciplines and activities that we can do in UX, the previous module: Wireframing, had a lot to do with the information architecture and interaction design. When we prototype, we're going to put them all together. Now remember the brief. We need to design an app that allows customers to order a pizza where they choose it from a menu, the app will then send an email to a restaurant, and then the customers pay the delivery driver. Remember, you need your app to work on multiple devices. So bear this in mind when you start your lab project later.

Core Concepts Let's talk about core concepts for prototypes. What are prototypes? As I said in our wireframing module, if you think of wireframes as a blueprint, then prototypes are like the architectural model. It's a different way of looking at the system, and it really helps bring it to life. Prototypes are very important for, first of all, you as a designer to test out the different kind of interactivity and flows, but they're also important for you to communicate the intent of your design to others as well. Why do we prototype? There are many benefits. First of all, they'll bring your ideas to life. They'll provide feedback with the proper context, sometimes it's difficult to imagine how your design will look on a screen if you're looking at a piece of paper. Benefits also help you find interaction issues early. Prototypes help you quickly iterate and refine ideas. Other benefits are it helps reduce development time. Less changes once the project goes into development. Prototypes are also useful as a reference for other teams. I think of them as a great way to augment and enhance wireframes. They encourage collaboration because everybody on the team can see what you mean, and that results in stronger solutions.

Types of Prototypes Let's talk about the different types of prototypes. So when thinking about what to prototype, there are two main scenarios that you want to prototype. First of all, the flows. You want to test the navigation, you want to test how users would complete a task, how they would move through your system, but another thing you can prototype are the interactions within the interface itself. Does a panel open vertically or does it open horizontally? What are all the interesting micro animations that you could put into your interface? These, you can prototype as well. The different types of prototypes are low fidelity, quick and easy to make, for example: sketching out a paper prototype, which you'll do in your lab project, or you can make clickable sketches. That means that you could scan your sketches and use something like POP to make them clickable, or you can make clickable wireframes. You can make a clickable PDF, for example, from your wireframes. As we move up in Fidelity, then we can start moving into prototypes that are made with prototyping software. As I'll show you in our tools section, there are many prototyping softwares that allow for quick and easy drag and drop interactivity. Often, they're made in black and white, so again, the focus is on the interactivity and how it functions rather than how it looks. Once we move into high fidelity, then we add how it looks onto how it works. Pixel perfect, you include a lot more design elements. Quite often, high fidelity prototypes are coded in HTML and CSS. This will help users and your stake holders better visualize the final product.

Prototyping Let's talk about the different prototyping tools. As I move through this list, you'll see that there are many, many different prototyping tools. Because there are so many tools out there, I invite you to download the trial and try out each one for yourself, to see which one works for your particular preferences. Many of them are very easy to use, and some of them have a higher learning curve. For example, Adobe Experience Design and Adobe After Effects have a steep learning curve, but they give you lots of power and control. On the other hand, you can use PowerPoint or Keynote to make your prototypes. There are many, many tutorials online that will teach you how to use all these different tools, including in Pluralsight. So I invite you to look them up. For the purposes of our lab assignment, we're going to make a low fidelity paper prototype. Here's what I need you to do. Grab a pen and paper, and create a paper prototype. To give you an example how easy it can be, I'm going to show you how I would personally make a paper prototype for our pizza app. So the first thing we're going to do is take our wireframes from the previous lesson, and draw them out on paper. On the example you can see here, I've created a menu at the top with order, locations, and menu; and then I've decided to put some feature pizzas with photos of the pizzas below them, your closest location, perhaps would have a map embedded, and then I was thinking a large image, or a hero banner could go underneath that. The great thing about paper prototypes is you can move things around easily and discard ideas that don't work. What I've done here is I've switched things around. I decided to have my hero image at the top, and put the photos of pizzas and map below the hero image. I like that a lot better, so I'm going to stay with that. What happens when someone presses login? Do they go to a new page or does something pop up? With this paper prototype, it's really easy to test ideas. In this example, I've had the login come up as a popup. I go back to my interface and think, why would happen if someone selects menu? Would they go to a new page? Would something pop up? In this example, I decided to have a dropdown menu. I made it into what's called a mega menu, which means it has lots of information inside of it. So when someone selects the menu option at the top, they can see the basic categories of the pizzas and even some examples of what goes into them. So that's my menu prototyped. Another thing I played with was what would happen if you go to the menu page? How would we lay out the basic categories? In this example, I've played with an idea of collapsed accordions, and what happens if we select one and expand it? You see pictures of the pizzas with descriptions of the basic pizzas underneath. So hopefully this gives you an idea of how fun and easy it is to make a paper prototype. Happy prototyping.

Lab Assignment For the purposes of our lab assignment, we're going to make a low fidelity paper prototype. Here's what I need you to do. Grab a pen and paper, and create a paper prototype. To give you an example how easy it can be, I'm going to show you how I would personally make a paper prototype for our pizza app. So the first thing we're going to do is take our wireframes from the previous lesson, and draw them out on paper. On the example you can see here, I've created a menu at the top with order, locations, and menu, and then I've decided to put some feature pizzas with photos of the pizzas below them, your closest location, perhaps would have a map embedded, and then I was thinking a large image or a hero banner could go underneath that. The great thing about paper prototypes is you can move things around easily and discard ideas that don't work. What I've done here is I've switched things around. I decided to have my hero image at the top and put the photos of pizzas and map below the hero image. I like that a lot better, so I'm going to stay with that. What happens when someone presses login? Do they go to a new page or does something pop up? With this paper prototype it's really easy to test ideas. In this example, I've had the login come up as a popup. I go back to my interface and think, why would happen if someone selects menu? Would they go to a new page? Would something pop up? In this example, I decided to have a dropdown menu. I made it into what's called a mega menu, which means it has lots of information inside of it. So when someone selects the menu option at the top, they can see the basic categories of the pizzas, and even some examples of what goes into them. So that's my menu prototyped. Another thing I played with was what would happen if you go to the menu page? How would we lay out the basic categories? In this example, I've played with an idea of collapsed accordions, and what happens if we select one and expand it? You see pictures of the pizzas with descriptions of the basic pizzas underneath. So hopefully this gives you an idea of how fun and easy it is to make a paper prototype. Happy prototyping.

Usability Testing Module Overview Welcome to UX Fundamentals: Usability Testing. In this module, we're going to go over usability testing. We'll start with a review of previous modules, and then we'll go over core concepts of usability testing, how to, and the finally, a lab project. Let's review what we learned earlier. Again thinking about all the activities and disciplines within UX, when we conduct usability testing, we're focusing on the information architecture and interaction design, but really, we're focusing on all activities as well. Now remember what we're trying to design in our lab project. You want to make an app that allows customers to order pizza where they choose it from a menu, the app will send an email to the restaurant, the customers pay the delivery driver, and it works on computer, mobile phone, or tablet. So keep this in mind as I go through this lesson about how you can design your app to work this way.

Core Concepts Core Concepts. With usability testing, you're really going to help understand what is a good experience versus a bad experience? When you have people who are not you using your designs, some of these things become quite apparent when you see people struggle with your designs. Remember, user experience means designing great experiences for users, and so if you don't get your designs in front of users, how will you know if it's a good experience or not? Usability testing ensures your designs are user-centric. Now after we conduct usability testing, what do we do with the results? Well, we use them to refine our designs. So don't be afraid to change your prototype between each session. Don't be afraid to iterate constantly. That is the heart of user-centered design: getting your designs in front of people as quickly and as early as possible, and then refining and changing your designs based on that feedback. That's how you make user-friendly intuitive designs.

Usability Testing How To How To. Before you start usability testing, you have to think to yourself: what do I want to test? Just as when you're prototyping, you can prototype the entire navigation, or flow, or how a user may complete a task, this is quite often what we want to test as well. So when you're writing out the script of what to test, think about the main task that you want users to complete. Additionally, you can also test the interactions within your interface. Can people figure out how the button works? What happens if they expand a panel? Does that interaction make sense for the user? So those are two different things that you can test. Remember to use a script. Your script should have at least three major scenarios for your site. So what you need to do is adjust your prototype, now that you've got some practice in creating a prototype, now you go back and adjust your prototype so that it supports at least three major scenarios, as per the script that you write. Paper prototype or digital? What I found works for me is that if you start off with quick sketches and create a quick paper prototype, and get it in front of people early, then you get some really good ideas that you can then use as you move along in fidelity into more digital prototypes. So I invite you to use a combination. Start with paper prototype, like we've made in the earlier module, and then move into a digital prototype. Both will get you feedback from users early, and give you meaningful results. Once you've got your script in your prototype, it's time to recruit people. Now try for about five to seven. If you're working in a professional setting, you may want to get more people, but five to seven is good for a project such as this. Always try to recruit from your target audience, meaning, if you're trying to design software for kids, you want to recruit kids. Or if you're designing, say, software for senior citizens, then you want to recruit senior citizens. So always try to recruit for your target audience, and try to get a nice sample, a nice range of ages, and a mixture of men and women, etc., so that you're not biased too heavily towards one population. For student work such as this, it's okay to use your friends and family. What I always say is some user testing is better than none. After you recruit your participants, then create a schedule. For example, I'm going to have participant one come in at 5:30, participant two will come in at 6:30, participant three at 7:30; it could be as simple as that. When you're working in a professional setting, it's important to have consent forms and incentives. Now these aren't necessary for a student project, such as the one we're working on here, but if you need to do user testing professionally, talk to the people at your organization, usually the legal department, about creating consent forms, and then you'll also talk to the powers that be about what the incentives could be.

Lab And now it's time for our final lab assignment: A Usability Test. This is what you'll need to do. As I said earlier in our how to, you recruit people. Try to get five to seven that follow your target audience. Friends and family are okay for student projects. You'll also need your paper prototype like you made in last module. Here's a handy usability testing checklist that you can print off and use for your own lab project. Let me walk you through it. Before testing, you'll need to create a script for three major scenarios for your site. So for example, for our lab project for our pizza app, you would want to script out the major scenario of looking through the menu, adding a pizza to the shopping cart and placing an order, and perhaps writing a review afterwards. For those three major scenarios, adjust your prototype and make sure that it supports those scenarios. Then go ahead and recruit and schedule your participants. On the day of testing, print out your script, as I said before, you probably won't need consent forms or incentive to pay them, but it's always nice to maybe buy your participants a cup of coffee if you want. Then you set up your recording device, and ensure that your prototype is on the device if you're using a digital prototype, or if you're using a paper prototype, make sure that you have the paper prototype handy. Happy testing! Good luck.

Course author

Krispian Emert Krispian has worked for award-winning agencies in Canada and Australia, and has provided strategic UX consulting for some of the world's top brands. She's keen to improve the discipline of UX, and...