Interaction Design 101: User flows, Wireframes, Prototypes, and More!

1. Welcome to Interaction Design 101: Welcome to Interaction Design 101. In this class, I'll teach you how to map out user flows, sketch user interfaces, and bring them all together in wireframes and prototypes to communicate interaction design to developers and other stakeholders. You'll use these skills in your project in each lesson. This class is aimed at students who have at least a basic idea of what UX is and want to understand interaction design in greater detail. It's ideal for freelancers or visual graphic designers who want to move into interaction design. Another way you can utilize these skills is if you're already a UX designer and just want to brush up on interaction design. Each lesson will follow the following structure. First, I will explains some of the theory. Then, I'll guide you through an example of the step using a coffee ordering app as my example, giving you tips and tricks along the way. Then, before the next lesson, you'll put these steps into practice yourself using your own class project. Put the idea in the community board and I'll give you feedback. By the end of this class, you'll have a user flow for your own app or product idea, some wireframes, and a prototype of the screens documented. Have a think about the idea you want to use for your project. It could be an existing idea you've got in your head or you could use a fictitious example, such as an alcohol order delivery app or car-sharing app, anything you can think of really. If you can't think of one, you can use an existing product and look at ways how you could improve it. This can go into your portfolio. Have a think about what example you'd like to use and put it in the community board. Do this before next class and I'll make sure to give some feedback. See you soon. 2. What is interaction design: In this lesson, you'll learn about what interaction design is. So what is it? Interaction design goes beyond what the interface looks like or the UI design and thinks about how users will interact with your product or service. Visual design is just the tip of the UX iceberg. Underneath the surface of what you say, the visual layer is what actually makes up the entire UX. This is the interaction design, the information architecture, the way information is presented and organized, the interaction design, the content, and the conceptual design of how the whole system hangs together. In graphic design, you don't necessarily have to think about how people would interact with your product or use it over time. But in interaction design, you do. Let's look at an example. We need to consider the interactions. So on the surface, this image looks like a good enough design. But if I'm a developer, I have questions. What happens to the placeholder text when a user clicks into the field? If it disappears, does the user know what field they're in a more to enter? What happens if the user enter something invalid? Where does the error message fit in the screen? Does everything moved down? What does the error message say? When does it appear? What's invalid? The address field is just one field. What format is the user meant and to hear? How did they know? Where's the tooltip? What is it using to match the address? Is this a Google Maps API? Is just free text? What validation is there? Answering all these questions, and probably more I haven't mentioned is interaction design. The process I liked to take when designing is first understand the user flow and what they are trying to achieve. Then sketch the interface to explore possible solutions. Next, create wireframes with the more final design, then prototype a solution. Making the wireframes interactive, I came to the final product and finally document the interactions so that it can be built. Depending on what the project is and how your team works, you might not actually go through all of these steps. For example, if it's a small tweak to an existing screen, you might jump straight to wireframes. You might even just prototype in the browser, you might have a chat with the developer and if you work somewhere that has a pretty sophisticated style card, you might not need to specify all of these interactions. They'll already know what happens to the placeholder text when you click into the field, what happens with error messages, etc. Don't forget to think about what example you want to use for your project throughout this course and pop it in the community bullet. See you soon. 3. Mapping user flows: So now that you know what Interaction Design is, in this lesson, we're going to start doing the first step, which is understanding the user flow. So what is a user flow? Well, it's a map or diagram of the steps or screens that a user will go through while using your product. It can also be an illustration of someone moving through the system. Why don't we do this step? Well, it helps you understand the logical of flow of steps that the user may take. It helps you work through what needs to go where, and what will happen. It helps you think through what happens if things don't go right. In an existing system, this helps you see where things are not as efficient as they could be, or where there are problems with the current process so that you can improve them. It also helps you communicate the flows to your stakeholders. Let's work through an example. I'm going to use my fictitious coffee ordering app. You can do this using many different tools, for example, pen and paper or a white board. You can also use specialized software like Visio, Lucidchart, Miro previously real time bullet or just symbols in Sketch, PowerPoint, Word, etc, anything you are comfortable with. Today, I'm going to use Sketch. So we have the beginning and I'm going to walk through the happy path. That is what happens when things go right? This is the path where most chooses to take most of the time. I'm more designed to help them down this way. So Catalans or coffee, she opens the app because she already knows about our product. We're doing the simplified flow which doesn't have to go login, sign up we just looking at the key points. Then the next step in the process is maybe selecting a coffee. Now that I'm thinking this through, maybe selecting the milk type is a different step in the process. Select what coffee you want then the milk. I'm going to add this to my order. Reuse "Lines" or "Arrows" to denote next step. Opening app, then "selecting coffee", "selecting coffee", then "selecting milk type", etc. We have an ending, the end of the process, "success". So that's a simplified happy path, but that's not always how things go in the real world, things go wrong, people need to make decisions. A diamond is usually used to represent a decision point. The decision point may be a decision that the user makes or it may be something that the system is doing. For example, the system now looking up, do we have the credit card on file? Can say I'm going back and changing my flow because originally I hadn't thought through all of these extra complexities. This is where using something digital can be beneficial. I can easily rearrange and rename the boxes. So as I'm up in this set, I'm thinking through a few things that don't work and making changes. Maybe go to the checkout page if you'd done already has a credit card, so you have an order confirmation and then there might be an extra screen to enter your credit card details. Sometimes there will be errors, we need to make sure we think about the error recovery or fail paths and how users can recover from this. For example, credit cards can be declined. So we need a loop to go back to the "Add credit card" or update credit cards grain. So now we know at least part of the user flow and can decide what screens when they need to design for. This process helps you think through the different paths or screens native. Originally, I wasn't thinking that while you might not have a credit card on file, the mapping through this process allowed me to come up with that. Each step in the process may be a different screen, or it may be a different field that is needed. You may have multiple steps on one screen. You can share in this format, or you can make the flow into more of a user story board with illustrations depending on how understood user flows are in your team. Here's an example comic of how these product could work. Someone wants a coffee? Why can't they go and get one? Maybe they injured, maybe this is our business model. Then they remember about app or the intellectual they need to do, and then they're happy. It's more of a user a story than a user flow. We could also look at abstracted screens and draw them with arrows between. So we haven't gone into too much detail, we still just looking at the flow and the way that people move through the system. Now, try to create a user flow for your own product app or idea, don't forget it to put it in the community booth for feedback, see you soon. 4. Sketch the interface: Now that you have your user flow, it's time to move on to the next step in the process. Sketching the interface. As I mentioned in the last lesson, you may have multiple different screens for each step or each step may be on one screen, or combination of the both. You'll probably also think about things and steps you missed along the way as you're going through this process too, and that's absolutely fine. It's part of it. It's really important to know that sketching is not about art, it's about communication, it's about thinking through the process. As you will see from my sketches, I am 100 percent not an artist. They are not beautiful but they don't need to be. The purpose of this step is about helping you think through the logical flow, what interfaces are needed, what interactions are needed, how might we get the user to do that interaction? Looking at my user flow from last lesson, I'm going to start sketching. I'm going to use pen and paper for this activity. But you may want to use a template, for example, something that already has, the sizes drawn for you. But this isn't necessary. Really, just pen, paper, or a white board is absolutely fine. I tend not to use digital at this point because I don't want to get too bogged down in, what are the colors? What size should the font be? I really just want to think about what elements I'm using and why. I'm starting with a rough outline of the screen with a head above. Maybe we've got our recent orders on the home screen, and a big call to action, which I'm outlining in Sharpie and coloring. The arrows represent moving to the next screen, I hit New Order. So now I'm on order screen. What do I need to do? Select Coffee Type. Maybe we use a drop-down box for that. Once I've done that, we move to the next screen, and my coffee type is there allowing me to go back and edit it. Now I need to select from a drop down box for the milk type I want. Maybe soy costs more. Now I've got my coffee type and my milk type. Which cafe is going to deliver it to me? Maybe this is a single select because I can only select one, and it's giving me the estimate of how long each cafe will take. Then I hit Checkout. Here, I go to different ways to pay. Maybe credit card, maybe PayPal. Can we do cash on delivery? Not sure. Can you tip the driver? These are some things we're going to think through. Then I fill out the credit card, big Pay button and I'm done. We haven't thought through everything. What happens on the other side? What are the drivers say? What does the cafe say? But this just gives us a bit of an idea of some of the flow that we are going to work through. As you can see, they're messy. But that's fine. The point is that I thought through the process and the flow and have come up with a couple of different interaction paradigms I might want to use. I'm now ready to move to digital. Now try sketching the screens for yourself, for your own project. As always, put them in the community board. See you soon. 5. Create wireframes: My sketches from the last lesson are essentially low fidelity wireframes. The next step in the process is firming up those wireframes. Wireframes are basically a blueprint of what is to be built. There's a famous Frank Lloyd Wright quote, you can use an eraser on the drafting table or a sledge hammer on the construction side. This isn't saying with software. If we go ahead and write down the code, we're just going to have to re-do it, throw it away and it's going to be more expensive. We need to have a blueprint or an idea of what we're going to make before we start coding. Wireframes help us think through the ideas and really start stress test them before we build and they help us communicate the idea so other people know what to build. Low-fidelity prototypes do not look exactly like the finished product. They may be made drawing, they may look a little bit sketchy, or maybe the visual design is just enough for next. The benefit of using a low-fidelity prototype is that you're going to get, say back at the right level. You're not going to get comments like, I don't like the color, I don't like the font. What you're really looking for at this stage is feedback on the flow and the interactions proposed. It also manages expectations. You don't want a client take something that looks like exactly the finished product and then they don't understand why is it still taking so much longer when I've already saved the design? It can also prevent developers from accidentally picking up and building something. If it's really clear that it's not a finalized blueprint or design. Low-fidelity prototypes are also quick and easy to make, and therefore, you know, as married to them and you're more willing to throw them away and start again, try again, try another idea. High fidelity prototypes do have their place. If you were to take low fidelity wireframes to usability testing or user research. You're not going to get really strict answers. High-fidelity prototypes are the best for this. Wireframes can again be made using many different tools, Adobe products, Balsamic, which is really good for sketchy looking ones, and Jill or sketch. Today I'm going to use sketch and you'll say I have libraries installed that have a lot of components I'm going to be using to help me save time. I took about half an hour to do this activity and it's nowhere near complete but I'm just going to talk through a few different things I did and a few different tips and tricks. Again, it doesn't matter too much about the colors and the font and the size is at this stage, but you will see me changing them a little bit just to show order, things that are bigger or show actions showing links are blue and that thing. But at the end you'll say that it's obviously nowhere near finished. You'll also see that as we're going through, I'm changing my mind and realizing there's different things that we should add so going back and adding it, this is obviously why we shouldn't start the code, having to go remove things, reorder things is going to cost a lot of time and money. I'm duplicating my art boards so that I can have the same basic frame for each thing. I've clicked new order, so we're moving into the next screen. The ones that I was sketching in earlier lessons. As we go through, you'll see me selecting items from libraries I have installed in my sketch. This just saves time. I push out to draw a rectangle and it's just a bit of a shortcut and type to get text up on the screen. I've started with coffee type so I'm going to write a bunch of different types of coffee that I can think of. I'm just making these up. But obviously in real life, you do analysis and you'd figure out what coffee shops offer. Again it's not a real app, so I've only got some coffee, I don't have to pay and other things you might want to buy. I also haven't put any prices at this stage. You also say that I'm just putting a bunch of different coffees that I can think of off the top of my head. Having to go and check the spelling for some of them. But I'm placing them in random order so that at the end I can place them in alphabetical order. It makes sense to be in alphabetical order especially [inaudible] don't know what's in the list and then might know what they feel like so they can scroll through it. Here I'm selecting all of the items in the list, right-clicking and selecting distribute vertically. This will evenly spaced the items. I've selected place on sub pixels because again, I'm not looking for pixel perfect design. But I just wanted to look a little bit measure. At this point I've realized that I haven't asked for size and maybe that's something you want to do upfront. I feel like a large coffee or feel like a small coffee rather than select what you want and then the size. Well, they're probably [inaudible]. I'm just rearrange my screens and going back and adding the same. You can say the way I've got the art boards is from left to right in order of the action that happens and I'm showing what it looks like when it's closed, what it looks like when it's expanded and what it looks like when it's selected. This does show a bit of the interaction if you know what you're looking for. For the coffee size, maybe you want to know what that coffee size is. We'll put in just a place holder for how many milliliters the coffee is. Although this probably isn't going to work in the real-world, because does every small coffee from every cafe have the same size? I also have input costs in here at all and obviously the coffee may be different prices based on different cafes. That's just some complexity I'm leaving out of scope for now but in real life you'd have to think about what that interaction would look like too. At this point, I've realized that my buttons still says new order because I was copying it across. Now I'm going back and changing it to say add to order. Once we've got our item added to our order, will be able to say it in some summary view with the ability to go back and change it. Now we need to use it to select where they want to get their coffee from. I've decided in this model, we're looking at cafes that have these coffee that you voted available. Because you can only select your order from one cafe, I'm going to use radio buttons, which suggest to the user that only one can be selected. I haven't bothered to look at the quantity. What happens if you want to order multiple coffees at once, which I'm sure would be in scope. Again, these interactions that you have to think through. Once again, for simplicity, I'm just having the ability to pay with credit card and I'm assuming that I haven't already got a credit card on record. This interaction is really high-level depending on how complex the real system was you may need to map out a lot more. You may need to map out all the different fields and it would take a lot longer than half an hour I've spent on this one. But you can see we've already got a bit of a flow of what's happening? What's going on? What could it look like? What types of controls where we use a drop down box, radio buttons, big code action, big purple buttons for coal? Things we want users to do and edit links for things that won't be used as much but still need to be, able to be accessed in the interface. If I were to take these wireframes to usability testing uses would have to make up an awful lot about how the interactions work and you might not get true results. Similarly, having this idea to developers in this stage may need them to make a lot of decisions about what the interaction does, like we spoke about in the second lesson. In the next lesson, you'll learn how to prototype to get through these headers. Now, try and create wireframes for your project and remember they don't need to be pixel perfect. It's about communication at the moment still and low file is better as we spoke about. Don't forget to upload them to the community board for feedback. See you soon. 6. Prototyping: Prototyping solves some of the problems we spoke about at the end of the last lesson. Show don't tell the interaction. If a picture is worth a thousand words, then a prototype is worth a million. A prototype is essentially a sample or a model of a system or a process. There are two main types of prototypes. There's a clickable or tap-able prototype and there's an interactive prototype. A clickable or tap-able prototype is one where you just take your wireframes and you put hotspots on some of the core actions and then clicking that links to the next grain essentially. You can do this in vision or sketch and I'll run through an example of how to do that. We can create one of these clickable prototypes in sketch. We go to the prototyping menu and click ''Add Link to Artboard.'' You select what you want to click, the button for example and then add to artboard and click the artboard which it links to. It does leave these arrows on the screen so you can see the interaction. The shortcut to do this is hitting the WK while you've selected something on an artboard and then hitting the next artboard and it will make that link. Then you can play the prototypes, so clicking where you made those hotspots will move to the next screen. But you can say because my screen is a different size, the image is moving up and down. If you spend a little bit more time you can make this a little bit smoother but again, you see it's just moving to the next. That's not really how things would go. If you click the button, it wouldn't move to a new screen. It would just animate in or select in some other way so that's the only limitation of these clickable prototypes. To make more interactive prototypes where users can actually type in things, select from drop-down boxes, say what the button looks like when it's clicked, you can use the code but obviously this might be too time consuming for some designers. Or you can use tools like Ajua which is what I'm going to use today. Now, this will look a little bit more old fashioned, the styles aren't as modern as you see in sketch but it gives you the interactivity. You just have to balance showing the interaction between showing what exactly it will look like in the browser in the final product. This is Ajua or Axia, I'm not sure how you pronounce it and I'm just using a free trial. What I'm doing to save time is copying my wireframes from sketch and writing over them. I'm putting a button from Ajua which has actions associated with it over the button I have just in my image. To make interactions in Axia you use cases, so I've selected the button and I'm going to add case on click. When the button is clicked, it's going to do whatever I set here which is to open another page of the prototype in the same Window. Now I'm adding a drop-down box and again, I'm just putting it over the drop-down from my image at y frame and add which items I want to appear in this list. I can add many at once which is useful when you're writing several at once. What I'm doing here is making the second item a dynamic panel and setting it to hidden. This is because I'm going to add an interactive case on the coffee size that when an item is selected from this list, the next drop down will appear. This just saves having to go to multiple different screens because you can do it all in the prototype. Ajua has some really complex interactions that you can choose and that is rather out of scope for this class but you can have a play around if you're interested. Again, I'm just working around my wireframes. I'm going to add a rectangle to cover the stuff from my image and replace it with the radio buttons available in Ajua because these are going to be fully interactive radio buttons and show what they should do and how they interact. You can preview the prototype. This opens it in the browser and shows you how the interactions work. When I select from this item, the next drop-down appears as we set it up to do. You'll see that the radio buttons are working. These took me about 20 minutes but again, if I played around and spent a lot longer, I could have it looking more like the final system would. It just depends how much time you want to spend, whether I'm just showing the interaction or whether it needs to look exactly pixel perfect. There are newer tools coming out. We can actually design in the code but I'm not going to look at any of those today. If you have really complex interactions that you want to show, another way to do this is to cheat by using a GIF or a PowerPoint animation and I'll show you how to do this as well. Let's fake an animation in PowerPoint. Let's say you have a list of things that you can save and when you save it, it gives you a little hint and tells you that it has gone up into your menu. I've got two stars that represent the saved state and I'm making them both appear at the same time. Then I'm doing a half animation so I can make the star go up and away where I want the animation to go. I want that to happen with previous. You click the star up here and the animation happens. Then we need to make it exit so you don't just have the star floating up by the menu. What I'm going to do is make sure I'm selecting the right one and have an exit effect and make this after previous. When you play, you fake the interaction. Click ''Animate Disappear.'' In reality at this step, we probably take this prototype to use erasers or usability testing. This is to check that the users can complete the tasks that we're expecting them to be able to do with this interface and it will show us if anything is confusing, or tricky or hard to use. Now, make a prototype of your own project and don't forget to put it in the community board for feedback. Again, it doesn't have to look amazing, it's just about showing the interactions. So even if it looks a bit old-fashioned in terms of the texts, the styles and all of that, it's still okay. See you soon. 7. Documenting the interaction: Now you've pretty much completed the interaction design, well done. My prototype is still pretty rough, so in real life, I'd work with visual design to finesse what it looks like in the spacing before handing it off to development. Depending on where and how you work, depends how you need to handle the interaction design. If you're an agency who doesn't do development, all the development's outsourced, then maybe you need a really thick requirements document with really specced up, mocked up field saying, "When you click this, this happens, this happens next. This is the screen reader order." All of that really nitty-gritty detail. Maybe you work somewhere that has a pretty complex style guide already, so you don't need to bother specifying all those little minutia. But regardless of which one it is, having some documentation will help. You may not be around when they pick it up, or there might be some lag between when you finish the design and when it's picked up and people can forget the interaction. What I like to do is share the prototype, share the images, and for anything complex, document it. That could be just text, doing it in Sketch, annotating, marking it up, just with images, with symbols, with words, or with a plug-in, or you could record a video of the prototype being used, and talk over it or add little boxes to fly in and fly out. Again, it all depends on how much time you have and how busy you are, and how complex the interactions are. Is it worth spending half a day mocking this up, or is that just a waste of my time that no one's going to look at, will anyone read the menu? If not, don't waste your time. I'd like to do a combination. I'll just run through an example of how I would document this if it was a real product. What I would do in Word, or Confluence, or whatever tool you're using; is have what the product is link to the prototype. Just copy the actual URL, say who owns the project, so who to come to for questions, and then also have links to where I've put the individual images with the comments. This is because not everyone will have Sketch, so they won't be able to download it. I'll often copy and paste them either in this document, or somewhere that they're visible. In terms of actually documenting, I'll just move so I have a bit of space in-between the appboards, and in-between the appboards I'll put some text. When they click this button, they move to the next page. Once they've selected which type of coffee they want, the film uses progressive disclosure, so it shows the next field which needs to be selected. It also then moves what has been selected up into this edit mode, with the ability to click, change and go back. Now I've decided to add an extra link in here to show that process. I might also mock-up where different things come from. I'm mocking up that the order details collapses once you get to the next screen so that it's all on one line. 8. Recap - Interaction design 101: Now you know what interaction design is. Everything to do with how the user interacts with your product over time. Not just the look and feel. You know the steps to achieve that create the user flows, a diagram of the steps a user takes or the screens they go through. How to sketch the interface, to think through how you might design the screens, how to make wireframes. Framing up those designs and thinking through which interactive components to use, prototyping Next, making an interactive prototype to test and better show interactions. Finally, documenting to communicate your designs. Remember that you don't need to follow all of these steps for every project. It depends on how big the pieces, if it's just a small change and you can just mark it up in the browser yourself, or whether it's a big Greenfields project where you're going to want to do all of these steps. As you get more experience, you'll learn when you can decide which steps to drop and which ones you need to do. That brings us to the end of Interaction Design 101. Please follow my profile and review the class. If you liked it, spread the word. Good luck on your interaction design careers. I'll make all the slides available and upload them so that you can refer to them later. Happy designing.