Hello and welcome back. Today we'll talk about communicating all of these great design ideas that you've come up with to stakeholders. There are very few benefits to actually communicating the ideas to stakeholder early, often, at the end, at the right granularity. The idea is that you can actually get a lot of feedback early on in the process before you devote a lot of resources to something. So I'd much rather hear a user say, wow, this will never work, to a sketch that I spend 15 minutes on, than spend two years and $2 million developing a very expensive system, and then have them tell me, this isn't going to work for my needs. So there's many different ideas for communicating how your system may be used. I actually like kind of hybrid approaches, but here's two examples. So one may be something like a use case, and the other one combines a use case with a series of small drawings that we call a story board. So for example, in this use case, you describe the individual. So in this case, it's Jeff, he's serving a tour of duty overseas. And he has two kids living with his wife. They have a single brightly colored system, which we called Remote Presents, on their coffee table. And every day when the kids are at school, they decide on a small treat to put in the box, and then they are able to open that box only when their dad calls them. So the idea here is to help Jeff, while he's overseas, to stay connected with his kids and have kind of a fun little thing that he does with his kids every day. And so on the left you see this described as a use case, described just in terms of just using words. And on the right, you see it described as a story board, which combines sentences to say what happens with pictures of how this would actually be used. Now, in this talk I'll actually focus on the idea of sketching to communicate your ideas. And there's a few reasons why I want to focus on sketching. I think it really gets the idea across in a way that still suggests it's open to edits. So it's specific enough that you're showing the user exactly how somebody would proceed through using the system. What are the different steps of it? Even maybe a little bit about what it looks like or how they would go about using it and where. But it still can be kind of low effort enough that the user will feel comfortable giving you feedback. They won't feel like, well it looks like they've spent hours on this thing, I can't say that it's never going to work. And that they'll give feedback at the right granularity. So for example, if you show a sketch of a system that doesn't really have colors yet, it's just a pencil sketch, the users can't common on colors if that's not the kind of feedback that you're looking on. And that can be really helpful, because sometimes if you show a very well-defined sketch, something like a mocked up prototype in PowerPoint, and it looks fairly complete, the users will comment on kind of low-level characteristics, like font size, or the buttons, or the layout, rather than the kind of feedback you may be looking for, which is, is this something that you would useful in your life? Is this the kind of system that you would want to use? So, since I'm going to ask you guys to sketch, I wanted to go through a few common myths of sketching. So, the main myth that I deal with all the time with my students, who are usually computer scientists, and so are fairly weary of picking up a pencil and drawing, is that sketching is about drawing. Now, I don't really think that it is. To me, sketching is about lots of things. So, it could be about planning. So for example, here's an example sketch for a website that plans out where the different parts of that website will go, how a user will interact, where you'll have things like the cost of the item, the styles of the item. Basically, planning out what it's going to look like eventually. You could also say that sketching's really about communicating ideas. So, one of my favorite online comics is xkcd.com. The writer always draws the examples using stick figures. So, it doesn't require realistic drawing to communicate an idea. You can actually do them very briefly through brief sketches like these stick figures in this drawing. And also, this is a great comic for programmers. I will give you a second to read it. So, stick figures can be very effective. I also think that sketching is really about understanding something. This is an example of a self-powered flashlight. It's a handheld flashlight that could be powered by cranking a handle, that I actually took apart and kind of gave an exploded view of, to figure out what all the parts inside it were, and how they all connected together. So by doing this, by sketching it out, I was actually able to understand how all the pieces fit together and where all of them were. It was very specific, I couldn't miss a piece of this flashlight, because then I'd know something was in the physical model but not on my drawing. And I think that specificity is very important to understanding something. So then, as I provide these arguments for why drawing could be helpful to people in explaining their ideas, I frequently get the argument of, well, but I can't draw. I'm a programmer, I'm a computer scientist, so what do I do? And the two tricks that I've covered with my students that I found very helpful, and these are actually examples of real student work, is to simplify shapes and use stick figures. So as we see in the example to the left, hands are represented by a very simple kind of s-shaped, a tablet is represented as a rectangle, people are represented as a circle and an oval. And nonetheless, it still communicates the idea, communicates how the system would be used and what somebody would do with it. The other solution that I really like is actually taking a photo and tracing it. So in this case, the students took a photo of somebody using the phone. And then instead of drawing the interface of the phone as it was on the screen, they added their own interface to it, to show how somebody would use the system. So again, there was no drawing skills required here, it just required a photograph that you then trace with a pencil. But, both of these drawings kind of communicate the same thing. So they could have a sketchy quality to it that makes participants more comfortable giving feedback that is still formative, saying, no this will never work, or I don't think you're going about this in the right way. They are black and white, so participants can't get stuck on details like color. They are still fairly sketchy in terms of the layout and the sort of things they show. So, you might get the kind of feedback that you want about whether the participants would find the system useful, whether they would use it in their everyday life. Rather than more specific lower-level feedback, that you might not want quite yet. So if you like this, if you think sketching could be something that you could use in your work, there's one book I really recommend looking at. So this is actually my favorite book of all time on user interface design. It's called Sketching User Experiences, The Workbook. It shares lots of different strategies for how you can sketch to communicate your ideas, and it really assumes no knowledge of drawing ahead of time. Because as I mentioned in this lecture, sketching is not really about drawing. So that's all I have for you today, and I hope to see you in the future video.
