A prototype is not a sketch, a prototype is not a wireframe, and it's not a mockup, right? These elements, they're important to the process, but, they're not interactive prototypes. And again, this is one of those things where-- This is the definition that I chose for this, right? There are other people that will tell you that, a prototype is anything, that is not the finished product, right? Or everything leading up to the finished product. But the key differentiator here, in this definition, is the interactivity, right? So, technically, a wireframe is a prototype but, the key differentiator here, is the interactivity. People can, you're starting to design the behavior, of the interaction. So, sketches, paper sketches, let's you explore ideas really quickly, and help you experiment and refine. While wireframes, are more of a detailed map, of the project, sort of, like, a visual guide to it's internal structure. And mockups, that we're not covering here, because we're not covering visu...
al design. But for the sake of completion, mockups are, like, a more refined representation, of the finished design. But, what's missing from each of these, is the ability to show how an application actually works, from screen to screen. Showing the actual behavior and the interactivity. So, the definition of prototype, that we're using here, is that it's the simulation of how the finished product will work. You know, and prototypes can be at any level of detail, depending on what you need at the time. The important thing to remember is that, prototypes are questions. So from early on, the explorations you have, will be really broad. Is it going to be a mobile interaction, or is it going to be a terminal? And as you evolve, and you get more feedback, the range of questions, that you're exploring, gets narrower and narrower. And, as you evolve further, you know that these alternatives get narrower, and by the end, you know, you're still asking questions, but, you're no longer asking questions of, is it a mobile device or a kiosk? You're asking questions of, "Oh, is it going to be nine point font or ten point font?". "Is this the right shadow?" "Is this transition fast enough?" So, at each step of the process, you're creating prototypes to ask questions. That you explore the application flow, how the interactions work. And they let you test quickly. And, here you see in the next segment, so, in real life, the lines aren't as clear. Like, when you're transmitting information through, through teaching, you have to, sort of, give it in a sequential manner, because that's the only way that you can communicate it. But in real life, the lines are, kind of, blurred. So, you can draw a detailed wireframe on paper, if you're good at sketching, and you can create an interactive prototype, out of paper too. And, it's not something that I do, but a lot of other people do it, and it's effective. I think that the take away is, it's not necessarily what tool you use, it's the message that you're trying to communicate. So, you're trying to communicate certain ideas, or a certain vision, of how something will work. And you're trying to get people to understand that vision. And, if your tool of choice is, drawing it out on paper, and creating a prototype that way, and you're most effective in that way, go for it. I'm not most effective in that way. That's why I always use, I tend to go to digital tools, a little faster, than some other designers do. 'Cos, I'm really, really fast at them. Okay. So, one of the greatest benefits of, creating early prototypes like this, is that you can test much earlier in the process. So, in that way, you can get really great feedback, about general ideas and the general direction, of where things are going. And, you tend to get really good feedback that way, because, if you show people super polished stuff, again, they might be too polite to give you real feedback. Because, they can tell that you've already put so many hours into it. But if you showed them a paper sketch, or, like, a super rough electronic wireframe, they're more likely to give you honest feedback. And, of course, it's fast. It's fast, it's easy to change, and if it's too polished, people will start to focus more on, intricate details, versus the entire flow of the application. Another cool reason, to do interactive prototypes, starting with paper, is, you know, not everyone can code, most people can help with this process. Like, if you're testing this out with some people, in an office, you can, if, the executive has an idea of how they would work, how they would solve a particular problem, They'll just take a piece of paper, sketch something out and add it to the prototype, that you've just made. So, there's interactivity there. Paper's always there, you don't need to learn the software. But it still works, right? So, when you're doing paper prototypes, all you need is paper, scissors, tape. And, what you can also do is, I mean, what I like to do is, there are these PostIts, that are double wide, vertical, PostIts, and they roughly have the rectangular shape, of a phone, right. So, if you're designing a mobile app, you already have the form factor on your paper. That let's you design things in that form factor. So, Okay, those are paper prototypes and, you know, there's a lot of different ways that you can mold them. Here's an example of how prototypes can look in digital. But, you'll notice, even though this is prototype, this is a wireframe, an interactive prototype that I did a couple of years back. And you'll notice that even though it's in a digital form, and it, kind of, has a header at the top. It's still looks, kind of, sketchy. There's no color, there's no real design elements here. It's just an inventory of the content, and the flow. And, yeah. The most important thing to remember is that, prototypes are questions and, you know, depending what questions you're trying to answer, at which point in the process, you create different prototypes.
Would you say there's any risk to showing, let's say, more like an enterprise, sort of, scenario, showing too low fidelity, prototype, or even, back to the wireframing, in your experience, have you experienced anything, that's been risky in making that decision, to show too early?
Are you saying showing things too early in the process, or showing multiple versions?
A little bit of both, showing one, possibly, before really having the concept fully ironed out, and showing really low fidelity options, for concept.
It depends on how involved your stakeholders wanna be. One general rule, to remember though, is that, when you're, if you show, your stakeholders multiple options. Make sure that those are all of the good options, that you're happy with. Because, its almost a natural law, like gravity, That if you show three options, the client will always pick the worst one. (laughing) It's like you have gravity, energy conservation, client picks the least optimal concept. So you always want to show things, that you think are really good. And then, other than that, I think , generally it's a good idea to get people involved early. The benefits are greater, than the potential downsides. The only problem that I see, is that some clients, just don't understand it. So then you, sometimes you work with people, where you have to go hi-fidelity. Because, otherwise, you don't get any, anything from them. They look at the wireframe, they just don't understand it. Okay, so to summarize. Interaction design is a conversation, the best interactions, are the one's that aren't just what, a considerate person would give you, but what a person would give you, that really gets you. And can anticipate your needs, before you even ask them. And, that's the lens, if you don't take anything else, from this course, I would take that from this course. Is the idea, that interaction designs are conversations, and the best interactions are smooth, right? And then, as you look at other UI's, as you go through design libraries, or using your apps, looking at them with this new lens, you'd be like, "Oh, that feels kind of awkward," that's, kind of, like a weird conversation, not something that feels natural. Also, without knowing, you always have to know about the people that you're designing for. Otherwise, you can't design well. And finally, no one cares about your fancy design, as much as you do. That's a very hard reality to understand, and accept, about the design profession. Like, there's almost, no non-designer's gonna look at your UI, and be like, "Oh wow, I really like this, the timing on this transition." They're just gonna be like, "Okay, was I able to book this plane ticket?" "I wanna book a plane ticket, I wanna answer an email." "I wanna," you know, whatever, "book a babysitter." That's what they care about. And, your real job, is to help them become more effective, at accomplishing those tasks. Not to assert your ego, and what you think is cool, onto these designs. Finally, there were a couple of questions, around resources and tools. And, those are things that I include in the bonus material. Some of the best resources, to become better as an interaction designer, because you might watch this course, you'll feel good about yourself, you'll feel kind of fun, but this is really stuff that you have to, apply and practice. From the bonus material, we're gonna help you create a plan, for how to go from this course, forward, for becoming a better interaction designer. Alright, well. That is it. (laughing) Alright, well thank you Jamal, let's give Jamal a round of applause. (applause)