Welcome back. In this video, I'm going to introduce our topic on prototyping. Looking at what, why and at least a start of how. So when we talk about what, I go to the dictionary. I look at Merriam-Webster which had a wonderful definition of a prototype. A first or early example that's used as a model for what comes later. And it gave all sorts of examples about prototype cars. And prototype devices. And we do the same thing when we're designing interfaces. Whether they're physical or on screen. A prototype is any early example. Any early, started in implementation. Where an implementation define very loosely, that can be used to help evaluate or further design an idea. So our goal, in we think about a prototype Is to have something that helps us move forward. So that's what. What about why. The why in prototyping really starts with the notion of lower investment. Now why not just go all the way build the thing to completion? Well there's a number of reasons but the biggest of them is that at the beginning of a design process we don't know exactly what we want to create. We don't necessarily even know the features, we certainly don't know all the details of the implementation. And by prototyping we can with lower investment explore that design space and figure out which parts of the design we want to keep. And finalize which part we might have to change. Investment is also closely tied to commitment. One of the real problems with building a piece of software or frankly building anything Is that once you've done it, you're very hesitant to change it. Because you put a lot of effort in. This would be true whether you built a car. Maybe just a really small car for a child or whether you've built a software system. I went out one time and built a whole package of software tools to do grading. And, the great pain that came up was, what happened if the kind of grading, I wanted wasn't supported by the tool? And there was an immense temptation to say, well If it's not supported by the tool, we don't really need it. Because I'd hate to have to do that much more effort. And so, the second reason why we prototype, is that prototypes are easier to discard. They're easier to change or replace. And in fact, some studies have shown that when you give somebody a prototype that looks like it didn't take a lot of effort. Something hand-drawn, for instance, it elicits more significant constructive feedback. These people took prototypes that were actually programmed on a computer, but in one case, rendered using hand-drawn labels and hand-drawn boxes. And the other case labeled with traditional buttons and formal text labels and found that when you gave people the one that looked finished it tended to lead people to small comments about well this might be lined up here or the label could be changed. And when you gave people something that looked like a sketch, they were more willing to talk about whether the whole idea was a good idea. Well in user interface design we really want to focus early on figuring out if we have the right idea if we're solving the user's problem. And to get that kind of feedback, we may need some very sketchy prototypes that people are fully willing to critic in a harsh way. And save us from putting in a lot of investment for something we'll have to change later. So, that brings us to the question of how to prototype. And the type of prototype you build really depends on the questions you're trying to address. There's a couple of wonderful stories of this. Perhaps the most famous one is Jeff Hawkins' Block of Wood. Jeff Hawkins was the inventor of the PalmPilot. One of the early PDA's, or personal digital assistants. And early in the process of coming up with the idea for the PalmPilot he knew that the first hardest obstacle, was going to be, is somebody willing to carry around a device about this big in their pocket. And take it out every time they want to check their calendar, every time they want to do anything that involves organizing and planning, look something up in their phonebook. The early PalmPilots didn't have phones built in, they were just digital assistants that had calendars. And had In the early case, not even Internet connection, you would dock it to your computer to update when you got back to the office. But you could take notes on it and you could have a phonebook in it. And to test that, he got a block of wood, about the size that he thought a PalmPilot should be. And spent a bunch of time walking around. Every time he needed to check his calendar, he would pull out the piece of wood and tap on it to see if that felt like something he'd be willing to do. And that was a very specific purpose prototype. It was testing the form factor and only the form factor. Scott Hudson, a researcher at Carnegie Mellon university has over the past more than a decade built a whole series of physical prototyping tools. Starting with little bits of electronics that would communicate wirelessly, have embedded power where you needed them. And could be pinned on to styrofoam and other cheap prototyping material, so that you could create a physical device that had interaction in it and see what it would be like cheaply and quickly. More recently, he's evolved that to take advantage of 3D printing. Which is often the technology that's used for creating somewhat higher fidelity but still relatively cheap prototypes of 3D devices. But we should recognize that you can do prototypes on the back of a napkin with a pen or a pencil and sketch out here's an idea what do you think of it? Let's see if it makes sense. You can move to more detailed sketches. Sometimes what are called storyboards where you look at a series of sketches through a narrative of somebody doing something with the interface that you're looking at. Wireframes are a continuing of the evolution here of getting much of the functionality and the components and the basic layout. But not all of the functionality working and all the way up to executable prototypes. There are some prototyping tools, we'll be talking more about them, that make things easy to click on and get to the next screen. Even if they don't have all the back end functionality, that would make the application real. Getting something up and running quickly can be a lot cheaper and a lot less effort than getting something up slowly. But this gets us back to the key point, what you build really depends on what you want to know. Are you trying to test is the concept useful? As you testing is it appealing, are you testing is the tool useful in its design, is it usable are you going to have people try it out? Are there particularly tricky interactions that are the hard part of something? G I can do all of this stuff except selecting an account number, nobody knows an account number. And I'm going to build a really simple paper prototype to explore five or six different ways that people could narrow in on an account number. And thus in turn the type of evaluation you're going to do with a prototype may very much constrain how you build it. So I want to bring this together with my own prototyping story. Net Perceptions, which is a company I co-founded in 1996 and that was working in the recommender systems space, was exploring in the late 90's the idea of building a tool to manage email marketing campaigns. I worked with a product manager who was trying to push for this particular tool. And what he asked for was, can we create a prototype to show the functionality of what a marketing management tool would do to prospective customers? So that we can go out and gauge demand before we build it. By the way, his first thought was, why don't you just build it, just don't build it well? And I told him how much time it would take to get something that really worked. And he said, we don't have that much time. I said, that's good, cause we don't even know we want to build it. And we agreed that we'd come up with whatever prototype I could produce in no more than two days. At that time, as a professor, it's probably not a surprise that the tool I'm probably fastest in is PowerPoint. And so, I went and built about a 40 slide PowerPoint deck. With interactions built in so that you can click on things and it would take you to the right next slide or put something up on the screen. And we created a prototype. Now, I don't know where the original prototype went, but I saved about six of the screens from it to give you an idea of what this type of thing is. It was a tool called MarketLens. We had my own, really not very well-designed logo, customers, products around a magnifying glass. And it had components in there and we filled this is in with something reasonable. So we started with the idea of a customer browser were we could look at things geographically or by other categories. And you can see here this is all mocked up in PowerPoint but here's a place to go look at area codes. This was awhile ago the area codes all had zeros and ones in the middle in the U.S. they don't anymore. We could see individual customers almost all of whom happen to have been employees of the company at the time. We could look at a particular customer print out reports, get a summary of the products that they had liked from our companies products except of course we didn't have a company yet so we didn't have any products. So that was the first piece of this is we could browse customers. We could start a campaign and we did this with a wizard style. What segment are we trying to reach? Well we're going to go for the southern US which for us had 8,000 customers. Why these numbers I no longer remember. How many of them are we going to try and reach? We'll reach half of them, we'll see what happens. We're going to pick people based on the best match. So that we're only going to market to the people we have something to market to. As we go through, we start saying, well what products are we trying to sell? Well, we could do sporting goods. We could add other products. We could remove products. None of these buttons worked, except next. Next worked, so that it looked like a pretty neat tool. And we told the story as we sat down with customers about so you're trying to market sporting goods, you're doing this in the south. We're going to send people an email with up to five products per customer but only things we have an indication that customers would really have a high probability of liking. We're not going to send them recommendations for anything that they've purchased before but if they say they liked it and they've never bought from us, we'll include it. And when through all of this and created there's templates here, we're going to send out these emails. All of the difference stuff that was out there because there's only one email per customer then we don't worry about intervals. We made it fake but really good looking, other than graphically you can tell graphic design is not my strength. And as we went through this we would set up the duration of the campaign, talk about how we're going to get reports. And then finally came back and talked about sort of product sets and summaries and all sorts of other things on here. We sat down a set of individual customers and walked them through this PowerPoint deck clicking on each of the things. We never said next we would click on restrict, if that's what we were going to do and it would take us to the next steam. And it was really interesting, because customers gave us a lot of feedback. They told us features they needed, they told us they were interested in it, some of them told us they weren't interested in it and why. They told us what it had to integrate with in their existing databases. The one way in which we had in some ways I think disappointing results was that people didn't understand even though we told them we put together a PowerPoint to show this to you. They didn't get that it was a prototype, they got engaged in the story. One of the people involved asked if he could keep our PowerPoint deck so he could run it on a few things as a test case. And we had to explain that PowerPoint decks don't actually run email campaigns, it doesn't connect to your database, it's a mockup. But we got the results that we wanted. We figured out whether it made sense to launch that product. As, it turned out that product as we designed it, was not right. We saved a lot of time and effort in development. I spent two days putting together the 40 screens probably less than two full days. There was a lot of copy and paste. There are better tools available today for this. And we saved a whole lot of effort and shifted our development towards what it really needed to be. So PowerPoint is an example but any kind of prototype that saves you effort is worth considering. So let me give you a quick outline as to the rest of this topic. First you're going to see a number of videos around low-fidelity prototyping. Paper prototyping, physical prototyping, in the quick and dirty mechanisms. We'll then move into higher-fidelity prototyping. Enhancing paper, looking it Wireframes and prototyping tools, we will close this with a little discussion about the limits of prototyping. When do you run into things that what you need, really needs much more detailed construction in order to figure out if it's going to work. And then you've got two forms of evaluation in this topic. They'll be a paper prototyping assignment that will be peer-graded. So you'll be doing the assignment and the peer grading. And there will be a brief quiz where we take you through many of the different techniques, how they get used. Where they're applicable so that we test your ability to have absorbed and apply the different ideas around prototyping. We look forward to seeing you in the coming videos.
