My name's Steve Hickey, I'm a user 0:02 experience designer at Fresh Tilled Soil just 0:04 outside of Boston and today I'd like to talk you a bit about prototyping. 0:06 Before I jump into that, though, let's get to know you a little bit. 0:11 Anyone in the room who's a designer could you raise your hands? 0:15 Okay good. 0:19 Anyone who's a developer could you stand up, hop on your 0:20 left foot, and spin in circles for a bit for me? 0:22 Okay. 0:25 I figured you'd be used to requests like that from designers. 0:26 Okay. 0:30 And how many people in the room would classify the way they work as water fall? 0:31 Anybody brave enough to admit it? 0:36 Okay. 0:38 Just in case, none of you remember what that is. 0:40 Everyone's whose moved past it, that's the one two three I've gotta do 0:42 this first and then that and at the end you launch your product. 0:45 Now, could anyone who works agile and lean raise your hand. 0:49 yep, okay, keep em up. 0:54 Keep the agile and lean hands up for a second. 0:56 Good amount. 0:58 Sorry. 1:00 Sometimes I gotta call B.S. on that. 1:01 If you're not as good at high school 1:03 Spanish as me, I did subtitle that for you. 1:04 It's ok though. 1:08 If you do have a bit of waterfall in your process, it's not really your fault. 1:10 It's the kinda thing that got taught in design schools. 1:13 Big firms work this way, smaller agencies that sprang out 1:16 of them work this way and it kinda became a habit. 1:19 The thing is, it really doesn't make a lot of sense 1:24 to work that way, with the digital products that we work on. 1:26 I can sort of understand where it came from from the 1:29 print world, where you have fixed production points and things like that. 1:31 But, the great thing about the web is it allows us to put something in front of 1:35 the user, and see how they react, really quickly 1:38 and we can do it really cheaply as well. 1:41 We have infinite ability to fix and redo things 1:44 and there's a lot of power and opportunity in that. 1:46 We should be taking advantage of it. 1:49 Instead we've been showing our work to users at 1:51 the logical point that springs out of a waterfall process, 1:54 which is unfortunately right here at the end when you 1:57 launch the product and you think you've done everything else. 2:00 And here's what happens when that's the first time they see it. 2:03 All the feedback you get is complaints. 2:06 If you want a great, big list of things that you that you did wrong 2:09 once it's too late to fix them, that was a really great way to work. 2:13 Thing is, because, just because your coworkers and your boss thought you did a 2:18 great job throughout the process, it doesn't 2:21 mean that you actually did a good job. 2:23 You don't design for your peers, you 2:25 design for your users, users don't appreciate 2:27 the subtlety of your color choice if they can't find contact info on the website. 2:30 They don't notice the cleverness of you type pairings. 2:34 What they notice is that they can't figure out how to cancel an order. 2:36 So we need to find a way to avoid these problems and it's pretty simple. 2:40 We're just gonna show users the product earlier in the process. 2:44 We're gonna do it several times and we're gonna 2:48 listen to them every time we show it to them. 2:49 When we expose our work to users early and often, and we're going to 2:52 do our best to learn from what they tell us when they do that. 2:56 But this doesn't fit well into the old process. 2:58 Waterfall, for designers creates one very specific deliverable. 3:02 Very Pretty BULLSHIT. 3:08 It's entirely focused on making things look good, and this 3:10 is really the wrong thing for us to focus on. 3:13 A lot of us may be visual designers, but 3:15 whether or not the product is pretty is actually kind 3:17 of unimportant in the grand scheme of things and 3:19 it's surprising how often we lose sight of that fact. 3:22 Especially cause here in how robotically we spoke the two 3:25 sayings on the next two slides were about to show you. 3:27 So, sorry about this one. 3:31 There really should be a limit on Steve Jobs quotes at conferences, 3:32 I'm pretty sure that Matt from Gooza just completely took up the 3:35 entire quote the other day during his talk, but design is not 3:39 just what it looks like and feels like, design is how it works. 3:42 Here's the other one. 3:46 Form ever follows function. 3:48 Pretty much the same thing. 3:51 But with every time you set or agreed with some form of one of 3:53 those statements, have you really, ever really 3:55 ever stopped to think about what they mean? 3:57 The greatest sin of designers is our attachment to making things 3:59 look good and as a result, we've forgotten our own commandments. 4:03 So we have the ability to focus in on tiny details, to sacrifice every other 4:07 consideration just to get the smallest things correct, 4:13 and sometimes and for some people, depending what 4:16 your role on the team is, that's a really powerful thing to do, but a lot 4:18 of times all it really causes is for us to burn time on the wrong stuff. 4:22 Waterfall pushes us naturally towards this problem 4:26 and we need to be better than that. 4:28 So, let's take a look at how we can retro fit our process to help us out a bit. 4:30 So, first thing's first in any project what we really need to 4:35 do is become familiar with the problems and needs of our users. 4:39 Everyone has a completely different way of doing this. 4:42 At my company we do something called a deep drive. 4:44 Google Ventures has the product design sprint. 4:47 It's all based on personal presence, time, resources. 4:51 You know, the old stuff. 4:55 Figuring out what you're gonna do to do this is beyond 4:56 the scope of my talk but let's agree on one premise. 4:59 If you feel like you understand the 5:02 problem, it's time to move into making something. 5:03 I've always found that a natural byproduct of this stage is a great deal of sketching 5:06 and white boarding, you're gonna end up with 5:09 a lot of really rough ideas for interface elements 5:12 and functionality, and this kind of thing is 5:15 rarely complete at this stage, but a good 5:17 idea is to try to take some of this and just build onto them a little bit. 5:19 To see if you can get some tiny piece of product out of them to 5:23 learn something, no matter how limited in 5:26 scope and functionality it is at that point. 5:29 Thing is you don't wanna make them perfect right 5:32 then, what we're going here for here is good enough 5:34 because until you put it in front of the user 5:38 you have no way of knowing if it's just right. 5:40 No Photoshop, no Fireworks, no Sketch, not right now. 5:43 We wanna keep things rough, so, I know, from my experience, that we all 5:46 experience the desire to perfect things, but this in reality is a delaying tactic. 5:51 The longer we go without showing somebody else our 5:56 work, the more we risk making really serious errors. 5:58 Going down wrong paths, wasting a lot of time. 6:02 Well, we don't wanna work that anymore. 6:05 So, the old way, we would move onto wire frames after 6:09 we got a good understanding of how how the users worked. 6:13 But do you think we're gonna keep doing that? 6:18 No, cuz, one very simple reason, wireframes are a trap. 6:21 They trick us into thinking about the wrong 6:27 thing, in too much detail, at the wrong time. 6:29 We're not going to do them anymore, because they're way, 6:33 way, way too specific for this point in the process. 6:36 Instead what we can do is make a clickable prototype and in 6:40 fact, I would advocate that we 6:43 can completely replace wireframes with prototyping. 6:44 What you see here is an app that 6:48 my company did for a pharmaceutical sales company. 6:50 This was designed to help their reps to know what they 6:53 were gonna do everyday and what we did was old process. 6:55 Move through sketching. 6:59 Thought we had everything right. 7:00 Moved into wireframes, made some exhaustively 7:01 detailed documentation and then, we had a 7:04 couple days left before we actually had to go talk to the client. 7:07 So, just on a whim, I tossed it onto an iPad and 7:10 just to see what would happen if I started clicking on things. 7:12 Turns out the navigation was terrible and I didn't know that. 7:15 I burned two weeks on exhaustively 7:20 documenting something that didn't work at all. 7:22 But I found that out really quickly. 7:25 I had a couple days to fix it and so I was able to put 7:27 something together that function properly, put it 7:29 on the iPad, walk in the clients office. 7:31 Turns out they actually kinda love this shit. 7:34 You hand a client something right from the get go that 7:37 actually works, that you can click on, that you can do things. 7:41 They tend to think you're a wizard of some sort. 7:44 They thought that we had actually made the entire applica, whoa. 7:46 [LAUGH] Was that an earthquake? 7:49 They thought that we had actually made the application for them and they were pretty 7:53 excited to play with it a bit and give us really great feedback early on. 7:58 The 8:01 goal here was to get to something testable as quickly as possible. 8:04 Our first test was when I tried the first version on iPad and it was terrible. 8:07 So we fixed it, the second test was when we gave it to 8:12 the client and they could walk around with it and understand how it works. 8:15 The third test was when we refined that a little bit. 8:18 We're able to put it in front of a couple 8:20 of their sales reps and see how they did and 8:22 from then on we were able to run more tests 8:25 every couple of days as we improve and refined things. 8:27 And that was a lot better than just a stack of PDFs that were going 8:30 to go off to a development team without 8:34 any validation whatsoever, so, this is what I 8:36 think beyond a reasonable doubt is the most 8:40 important thing you can do to make sure 8:42 you're building the right thing in the right 8:44 way is to prototype as early as possible. 8:45 Instead of checking off 1, 2, 3 on some 8:48 sort of list until the client is happy, what 8:50 we're gonna do is make really rough, really dirty 8:52 functional prototypes and we're gonna do a lot of them. 8:55 We're gonna find out if they make users happy. 8:57 We're gonna fix the things that don't and then 9:00 we're gonna keep doing it a few more times. 9:02 Ideally the last prototype is well on its 9:05 way to being some sort of production ready code. 9:07 A good enough artifact to actually communicate to the team 9:10 building the product exactly how it's gonna work and the great 9:12 news is there are now some great tools out there 9:16 that will help you build functional prototypes as quickly as possible. 9:19 So I talked about Sketches a little bit earlier and how much they can convey. 9:23 There are a couple of tools, that'll actually let you 9:28 take those sketches and turn them right, into the clickable prototypes. 9:29 This is a good one called POP, for prototyping on paper. 9:32 It's an iOS and Android app. 9:36 It allows you to photograph your sketches. 9:39 You can add clickable areas to them, that'll 9:40 help progress to other sections of the mock-up. 9:42 You can create an entire prototype in a matter of minutes just from 9:45 the sketches you've done on a white board or on a piece of paper. 9:48 This will actually also incidentally work with high fidelity 9:51 mock ups that have been uploaded into your photo gallery. 9:54 So you can make this better and better as you move along. 9:56 This is mobile only though, it's restricted 10:00 to small screen output at the moment. 10:03 InVision App has become really popular lately. 10:06 We started using in my company a few months ago, I've talked 10:09 to a lot of other designers and they've been really happy with it. 10:12 We're very excited to keep going with this and see how 10:14 it develops but some of the features you get out of 10:16 this are the ability to click and drag to create hot 10:19 spots and quickly pull links together in a visual interface online. 10:22 You can get transition animations for mobile devices. 10:27 You can determine scrolling versus non-scrolling areas. 10:30 You can do both web and native prototypes so there's full range here. 10:34 They can be installed on mobile devises directly on the home 10:38 screen so you can actually mimic a native app very effectively. 10:41 They have a dragon drop image loader or you can sync with a folder in Dropbox, so 10:44 instead of having to upload new files every 10:48 time you change something, it'll just sync them automatically. 10:50 And one of the best parts, I think, is results can be annotated by members of 10:53 the team and commented on, and they can be commented on by the clients as well. 10:57 You can send them a private link that other people can't find. 11:00 They can comment in line in the prototype, and then you have 11:03 a checklist embedded in your artifact that you can use to keep working. 11:06 I think this has made a huge difference in how we work. 11:10 We've been using it on most of our projects lately. 11:12 There's also some great competitors to it. 11:15 Flinto and Marvel come to mind, so I'd recommend checking a few of those out. 11:17 But these make a huge difference in workflow for us. 11:21 There's also all the old stuff. 11:26 The things you were using to make wire frames before. 11:27 Every one of these pieces of software, I 11:30 think with Balsamiq, Axure, InDesign, Keynote and PowerPoint, 11:31 give you the ability to create hotspots and 11:36 click from slide to slide in different ways. 11:38 So if you're already really used to one of 11:40 these pieces of software and you wanna stick with it. 11:42 You want to get the speed that you've 11:45 learned out of it and you know, maybe you're 11:47 arguing with a project manager, about how much 11:49 time it's gonna take, to learn the new tool. 11:51 They can't really argue with you, doing it the way you were already doing it, 11:53 and spending a few extra minutes to make 11:56 something you know, communicate better to the client. 11:57 So, I would recommend looking at one of these, if you're 12:00 not quite ready to jump over to a new tool yet. 12:02 There's also good old HTML, CSS, and JavaScript. 12:06 You can write a really good prototype, a really rough prototype, really 12:10 quickly if you have a lot of experience and know what you're doing. 12:13 There's a lot of frameworks and tools that'll allow you to do this quickly. 12:16 So Bootstrap, Foundation, Sass, and let's you write CSS a little bit faster. 12:20 There's even built in functionality from Dreamweaver and Fireworks 12:26 you know, if you're into that sort of thing. 12:29 The great i, the great thing about all of those though, is it allows you 12:33 to get your code out quickly it allows you to get your idea out quickly. 12:36 And if you're disciplined in how you write 12:39 your code, you can even evolve as things go 12:41 along so that your final prototype is production 12:43 ready instead of having to go through another step. 12:46 There's also another great side effect of using JavaScript in your prototypes. 12:50 It's that you can start faking database interactions really quickly. 12:54 I suck at databases and it's actually probably fair 12:59 to say that I worse than suck at them because 13:02 I've never successfully gotten one to work long enough 13:04 for me to determine if I could figure it out. 13:06 They just don't work for me. 13:09 But I can write really bad JQuery as you can see here. 13:11 That's really easy for me. 13:14 So you can use the HTML5 local storage API with 13:16 JavaScript to load data in and spit it back out. 13:19 You can even actually take user modifications throughout a 13:22 session, store them as if it's a database and allow 13:26 the interface to react to them, so they can, you 13:29 can get a much better testing experience out of it. 13:31 This also gives you a really great excuse to involve developers from the beginning. 13:37 I've heard through different talks this week, 13:42 a, about many different ways of working. 13:44 Some people still hand off PSDs to a developer later on in the process. 13:46 Other people are lucky enough to 13:51 start working with developers from the beginning. 13:53 That's how we do it at my company. 13:54 That's how we advocate people do it and this is just a really great excuse 13:56 to say you need a developer from day one so you can collaborate with them. 13:59 But if you don't get to work from the, 14:06 with the developer from day one, if you're gonna 14:08 have to hand this off eventually, this is a 14:10 good way to hold everyone accountable towards what you developed. 14:13 As a prototype gets refined, as all the little 14:16 interactions get smoothed out and all the niceties get figured 14:19 out, the client is going to fall in love with this in a way they can't fall in love 14:22 with a static mock up and when the devs 14:26 come in to handle it, they now have an example 14:28 of what needs to be built, a very clear and 14:32 communicated example the client loves and is bought into already. 14:34 So this helps hold everyone on the team 14:38 accountable for the final quality of the product. 14:40 So, going into detail on usability testing would take 14:45 a lot longer than I have available for this talk. 14:48 The only really valuable piece of advice I have to give you here 14:51 is just to buy this book and read it six or eight times. 14:54 It's a really great book. 14:58 It's got some good tips like tricking people into going into user testing 14:59 with boxes of donuts and things like that, so Steve Krug knows what 15:02 he's talking about, it's well worth the 20 bucks or so, and I 15:05 will reinforce one point from his book again, test early, and test often. 15:09 The entire reason we're gonna be prototyping is so that we can do 15:15 that, so that we can learn as much as possible before we launch. 15:18 [BLANK_AUDIO] 15:21 All right, so, what about web design? 15:24 I've said a couple of times that we're way too worried about you 15:27 know, things being pretty, and we need to concentrate on more important things. 15:30 But visual design does come into it at some point. 15:33 A polished visual design is part of the 15:36 experience and helps users understand what's going on. 15:38 So, how do we work an effective visual design process, 15:40 like what we've become used to, into our new prototyping world? 15:44 To do that, we're gonna have to admit an unpopular truth first. 15:48 Mock-ups are completely and utterly useless. 15:51 See, Keanu's confused. 16:00 Look, a Photoshop mockup does one thing really well, 16:03 it makes clients feel comfortable and if your client wants 16:07 to burn money on being comfortable instead of getting 16:12 the best product possible for their users, then that's great. 16:15 Just do Photoshop mockups all the time, and work the way you used to work. 16:18 But the problem I have was not, with them is that I think it 16:23 forces you to make really complex final 16:26 visual decisions way too early in the process. 16:28 And because the level of polish and consistency expected in 16:32 visual comps is so high, you're gonna burn a ton 16:35 of time getting those little details right, because the client 16:38 will notice every time something is a couple of pixels off. 16:41 We've all encounter that. 16:44 Somethings just like a buttons five pixels too narrow and it's 16:46 the only thing the client sees in the entire review process. 16:49 It's really annoying. 16:52 But the thing is we're not gonna totally avoid comps. 16:55 We're just gonna be way smarter and more efficient about them. 16:58 So the sketch phase is actually gonna accomplish a lot 17:02 of the functionality and layout problems that you've been dealing 17:04 with and as you move through some of the early 17:07 prototyping stuff, you're gonna get more of that figured out. 17:09 So, you really don't have to go into 17:12 full exhaustive detail with that in Photoshop, what you 17:14 would do wanna do, is figure out the 17:18 visual style, and Photoshop is pretty good for that. 17:20 You don't have to make a full mockup 17:23 though if you use a couple of different tools,. 17:25 So, one thing I've started doing is what I'm calling UI studies. 17:27 If you look at the notebooks of master painters from 17:32 the renaissance up to today, it's not like they set 17:35 down, it's not like Da Vinci sat down and painted 17:38 forty Mona Lisa's until the last one was just right. 17:40 Like you go through notebooks and you'll find 17:44 little details of pieces of the final composition. 17:46 You know, he'll spend months figuring out how to 17:49 draw two hands and their relationship to each other, 17:51 something like that, and then you have this entire 17:54 collective group of interface, well not interface in his 17:57 case, but little experiments that combine to form the 18:01 final whole and I've started trying to do stuff 18:04 like that with Photoshop and with tools like code 18:06 pen and any variety of other things available to me. 18:09 Like, one thing that works for me is take in like a half size canvas in 18:13 Photoshop or sketch and doing a really zoomed 18:16 out experiment with final look and feel because 18:19 it keeps me out of the little tiny details so that I can refine later but 18:21 it gives me a great idea of what this is gonna feel like to a user overall. 18:25 And I can also work on various break points next 18:29 to each other, this and start to give an idea 18:31 of how things shuffle around for a responsive design, and 18:33 when I'm having problems with specific interface elements a lot 18:37 of time I'll try to work on those a bit 18:40 in isolation from the rest of the project, just to 18:41 try to figure out the specific problems I'm having there 18:44 before I reincorporate them back into the prototype as a whole. 18:46 Another useful method would be style tiles. 18:52 So maybe you get some of the look and feel stuff out of the 18:55 way and then you wanna start experimenting 18:57 with more detail in your interface elements. 18:59 So I might assemble an example of part of the interface and start dealing with that. 19:01 You know, button radiuses and shadows and typographic relationships. 19:06 I think that's really useful instead of 19:11 having 700 different Photoshop files that are all 19:13 attempting to copy the exact same distance between 19:15 the bottoms of paragraphs and things like that. 19:18 If I just have one good example of how it's supposed to 19:21 happen universally, and then that into, 19:24 that gets incorporated back into a prototype? 19:25 I've also been working on designing in the browser a lot more. 19:31 Like I said, if I want the same spacing at the 19:35 bottom of paragraphs, it's a lot easier to go into the inspector 19:37 and just tweak that value in Chrome, instead of going back through 19:41 my 700 Photoshop files and trying to make sure it's consistent everywhere. 19:44 I can actually do a lot of 19:47 really simple effective refinement, that will apply globally. 19:48 And if you get the settings right in chrome it's even 19:53 possible to save those refinements directly back to your CSS files instead 19:54 of having to copy and paste or remember them, so the 19:58 inspector can be a really powerful tool once you get comfortable with 20:01 it, but I think the overall point I want to make here though, is 20:06 what you want to do is use the right tool for the job at hand. 20:09 Throughout your entire visual design process, you're going 20:13 to come across a great variety of problems. 20:15 Sometimes your problem, the most effective way to 20:18 solve it is gonna be a Photoshop mockup. 20:20 Other times it's way more effective to solve in code. 20:22 For example let's say you're working on transitions. 20:25 A Photoshop mockup is never gonna convey a transition properly because it's static. 20:27 A Photoshop mock up is a picture of a website, not a website. 20:32 And so, a problem like that, the logical place 20:35 to figure it out is in code in the browser. 20:38 Maybe it's even easier to go back and figure out in sketch 20:41 form if you're just trying to get layout problems figured out right. 20:43 But, there's no reason to be in Photoshop just because 20:46 this is the part of the process where we do Photoshop. 20:49 Just pick the one that's best for you, where you are right then. 20:52 And you're gonna end up with much better results. 20:55 So let's take a look at a couple 21:00 of examples of why prototyping can be so effective. 21:02 First one is gonna be Google Glass. 21:06 I'm sure you've seen, there's been a couple 21:08 people walking around wearing it today and yesterday. 21:10 I actually wish I'd gotten a chance to take a look through it 21:12 yet, somehow I've never encountered one but i hear they're kind of interesting 21:15 tom chi who lead prototyping on the project for google was kind 21:21 enough to do a write up on their process and he provided some 21:24 really great insights on his project so the quote we have here 21:26 we were working with the hud literally on my first day at work. 21:29 And we're learning a tremendous number of 21:32 things that you couldn't possibly just guess or 21:34 estimate or print out on a spreadsheet, or a project map, and that sort of thing. 21:36 That's because the first thing they did 21:39 was assemble this disgusting conglomeration of wires 21:41 and pieces of little plexiglass and things like that that told them if this could 21:45 even work, whereas maybe, even as early as recent as a couple years before 21:48 that they might have actually just burned 21:53 a thousand engineering hours talking about it instead. 21:54 This is a picture of what they built, this is the 21:58 first sketch for what would be the first prototype of Google Glass. 22:00 It's basically pieces of plexiglass suspended 22:04 from coat hangers hanging from a whiteboard 22:07 with some little hairbands attached to strings so that the use can keep 22:09 their hands down by their side and trigger actions, changing what was on 22:13 the screen which was projected by a 22:17 Netbook and a crappy little Piko projector. 22:19 But that told them that Google Glass could work. 22:21 That you could actually put a little, tiny monitor right in front 22:23 of somebody's eyes and accurately project things unto it and have them be 22:26 able to react to them while still interacting with the environment around 22:29 them and the best part is, it was incredibly cheap to do that. 22:32 They just grabbed stuff they had lying around the office and assembled it. 22:36 So, another trick they figured out. 22:40 Your ears can take a lot more weight than 22:42 your nose, so if you can create a system where 22:44 the ear becomes a fulcrum, then the perceptual weight disappears 22:46 and this took me about two hours to figure out. 22:49 So this was one of the vital tricks they learned that made it more wearable. 22:52 If they had taken all of the electronic components and the battery 22:56 and all that stuff and shoved it right up here where the 22:59 computer actually is in Google Glass, then somebody would have had this 23:01 thing sliding slowly down their nose every couple of minutes, all day long. 23:04 And maybe if you're demoing the product for 23:09 five minutes, that doesn't seem like a big deal. 23:11 But the first time you have to 23:13 wear it around that's gonna become intolerably annoying. 23:14 So, using modelling clay and coat hangers and some paper, 23:18 they just moved some of the weight backwards to a 23:22 place that could handle it much more easily and all 23:24 of a sudden, the perceptual weight of Google Glass disappeared. 23:26 Two hours of work with children's 23:30 construction materials solved a huge engineering problem. 23:32 So this is the second example I want to go through. 23:38 This is a game called Encantor, which we worked on fresh tilled soil. 23:40 This is a real world massive multiplayer RPG 23:44 game and the gist of it is that players 23:47 are in contact with encantors who come from, and 23:50 they're basically wizards from like, five lost magical realms. 23:54 And so they figured out how to reach into our 23:58 world with magic and so, people who play the game, 24:00 they have a phone, which is how they communicate with 24:04 their Encantor and they also have a Bluetooth magic wand. 24:06 Harry Potter style. 24:11 It's, the game was just so, so fucking cool. 24:13 I don't think i could've ever brought myself to play it because i don't think i 24:19 would want to run around the streets of 24:22 Boston with a wand casting lightning bolts at people. 24:24 But i know a whole bunch of people i talk to who 24:27 immediately wanted to know when it was being released and were very excited 24:29 about it when we were engaged to do is design an interaction model 24:32 where we keep users involved in the real world as much as possible. 24:36 Because the thing is, what they're doing is interacting with 24:40 these digital sprites and ghouls and things like that and you 24:42 can't just see them running off over in the distance, 24:46 you have to look down at your phone and see them. 24:49 But the point of this game is keeping people in the real world. 24:51 So how do you design an interface that supports that? 24:53 My colleague Mark Rambo, he designed the interface for a playable demo 24:57 and this was our first prototype. 25:03 The client came into the first meeting with us, and they had 25:06 already come up with their own version of interaction model for this. 25:09 The way the user would navigate the interface, cause they would have 25:14 this phone strap to their wrist, and they would bump their fist left 25:17 or right or forwards or backwards to move around the interface, and, they 25:22 are pretty convinced that this would be the best way to do it. 25:26 So while we are talking, it sounded to me like you would be 25:29 a problem so what I did was i downloaded an accelerometer app from 25:31 the app store and then I strapped my iPhone to my wrist and 25:35 then I verified that you could in fact get unique signatures on the accelerometer. 25:38 So we learned two things the first is that you could actually 25:43 navigate that way and the second is that if we did set 25:45 it up that way you'd have groups of children running around Boston 25:49 common looking like rejects from the Jersey shore fist bumping the entire time. 25:51 And we really didn't want that we thought 25:55 it would look ridiculous and would be kind of 25:57 tiring and weird so we started casting a 25:58 vote for a different way of dealing with it. 26:02 So, the game also involves, as I mentioned before, a bluetooth magic wand, 26:04 which attaches to the phone and it allows the user to cast spells. 26:08 So we needed to test the spell 26:13 versions, and then make some recommendations to them. 26:15 Originally, every single spell in the game, and there were dozens of them. 26:18 had its own unique gesture that the wand was supposed to pick up. 26:22 So, whatever combination of things you wanted to cast, you had to 26:25 learn a movement for that, so you go throw them at your friends. 26:28 You can also modify them, by chaining the different spell sequences together. 26:32 And I'm sure as you can imagine, this gets immeasurably complex. 26:37 We had to make sure this worked, and if it 26:40 didn't work, we had to figure out how to fix it. 26:42 But. 26:45 The company could not spare any of the wands for us. 26:45 They had these beautiful vacuum formed plastic 26:49 wands that they were going around to investors 26:51 with to try and sell the game on, so we had to make our own. 26:53 That's my wand. 26:59 I suck at wand making, in case you can't tell. 27:01 It's a stick and duct tape and this little off the 27:03 shelf bluetooth module that's basically like the guts of a Nintendo Wii. 27:07 I just taped everything together. 27:11 And we found out is, that once you take the bluetooth module which 27:13 is fairly high fidelity on it's own and you tape a stick to it. 27:16 The stick sort of even's out a lot of the 27:20 differences which allows the bluetooth module to determine what failure casting. 27:22 And all of a sudden everything just goes completely wrong. 27:26 Just completely changes the physics of the entire thing. 27:29 So we learned that with a stick, which I was pretty happy about. 27:33 And I have to keep this on my desk as a trophy because of how atrocious it is. 27:36 I'm required now. 27:40 So, this pushed us to a solution where the user has a spell bag instead. 27:42 This is the spell bag, down at the bottom of their, Their screen. 27:46 At any given time they see four to six icons at the bottom of the screen 27:51 corresponding with their spells and all they have 27:54 to remember for gestures is one through six. 27:56 If they cast one, first spells goes, if they cast four, fourth spells goes. 28:01 Very simple. 28:06 You could even swipe the spell bag left and 28:08 right as you gain more spells and grew in levels. 28:10 So, you might have another six set of spells that you like to use regularly. 28:12 You swipe over and all of a sudden one through six are remapped. 28:16 We found people could remember this fairly easily and 28:19 people also tended to use the same small set 28:22 of spells so it's much easier to give them 28:25 a few gestures to remember that they could map themselves. 28:27 Then it was to have them remember this 28:30 really complex, borderline language for assembling things together. 28:32 When 28:37 we got to designing the rest of the UI, we took advantage of the device API 28:39 in Firefox for Android so that we could 28:44 fake full screen native apps in the browser. 28:46 So these would do things like vibrate to provide feedback 28:49 to the users, just like the native app eventually would. 28:51 And what this did was, it helped us validate a swipe-based UI, where the phone 28:54 was the central play hub, and support screens 28:58 were accessed with quick swipes in different directions. 29:01 So instead of having to look down and hit very precise buttons. 29:04 You could just swipe the phone in a different 29:07 direction without even paying any attention to it, and 29:09 you would trigger different parts of the interface, We 29:11 also used web sockets to tie the two interfaces together. 29:14 So, what we have here is a large screen 29:17 with some options that a controller can click on. 29:20 Somebody would sit in a different room with this, 29:22 and then the test user would have a phone. 29:24 And they would see this interface. 29:26 Depending on what the user did on the phone, 29:28 the interface on the test screen would change to match. 29:31 And if the user controlling the test screen 29:34 wanted to change the scenario, they would just click 29:36 on a different link, which would cause the user's 29:39 phone to react and go to a different state. 29:41 So we were basically able to build this in sort of like web sockets 29:42 Dungeons and Dragons game with this diabolical 29:46 dungeon master sitting in a different room. 29:48 Instead of a horrifying complexity data base and bunch of algorithms for 29:50 how things are suppose to behave, which are not things were good at. 29:53 So, this was incredibly cheap and easy for us to assemble. 29:56 And we were able to learn a lot from. 30:00 So, wanna wrap up things up a bit for you. 30:03 This are the important points of my talk today. 30:07 Wants you to sketch a lot because it's quick and efficient. 30:11 I want you to stop wire framing and start prototyping. 30:14 That is incredibly important. 30:17 Test early and often, that's why you wanna get the prototypes. 30:18 We're gonna void comps for every screen and 30:22 state now because we can work more efficiently. 30:24 We're going to eliminate all the redundant parts of our workflow as much as possible. 30:27 And we have to remember process is not a straight line. 30:31 A good process jumps all over the place so that you use the tools you have available 30:34 to you to solve the problem at hand in the best way possible at any given time. 30:37 So thank you [SOUND] It looks like I have 30:42 time for questions if anybody has any. 30:50 >> [INAUDIBLE] But you, you talk about. 30:57 [INAUDIBLE] comps to get the clients sign-off [INAUDIBLE] etc, But isn't 31:03 it part of the testing also that [INAUDIBLE] argument with the test. 31:08 >> Mm. 31:12 >> Like you prove something works, or you prove something didn't [COUGH] [INAUDIBLE] 31:13 >> Yeah, I mean. 31:19 We're focused in our process a lot more on the 31:21 functionality of the prototype displays, so when we're testing the 31:23 prototype, and we get res, the results we're looking for 31:27 outta that, that validates a lot of our decision making. 31:30 We've been able to prov, persuade our clients of 31:32 in many cases that well, visual design isn't purely decoration. 31:34 It's less important then the functionality then were actually testing. 31:38 Which is how we get the way with not being tied to mock up so much. 31:41 And that when they have us doing mock ups, there really just 31:44 paying for us to burn time on the wrong part of the process. 31:47 It's going to be much more important to them if there users are actually 31:50 able to use something, than if the screens we gave them earlier on are prettier. 31:53 And on. 31:57 I'm not sure I'm sorry if that answered your question or not. 31:58 But. 32:00 Yep. 32:01 All right. 32:02 Anybody else? 32:02 Yeah. 32:03 >> Hi, I'm wondering how has it been working with clients when you have 32:05 been able to get [INAUDIBLE] how have you been able to, 32:10 talk to clients and make sure that they're okay with having that many people? 32:16 Do you ever get push back and if so how do you deal with that? 32:21 >> I'm sorry I missed the middle of that, could you say it one more time? 32:26 >> Oh. 32:29 When you have [UNKNOWN] >> Hm-mm. 32:29 >> [UNKNOWN]. 32:32 >> Oh, OK. 32:33 >> [UNKNOWN] talking about cost and having [UNKNOWN] 32:33 early on. 32:39 How do you [UNKNOWN]. 32:39 What are some [UNKNOWN]. 32:42 >> We basically don't give them the option. 32:45 What we tell them is, you hired us for a reason, 32:48 our process is very effective, you've vetted us through other channels. 32:50 We do good work by working this way, and it's not like developers 32:54 in the room at the beginning are a line item that saves you money. 32:59 We're gonna charge you the same amount of money regardless of who's in the room 33:01 at the beginning, so you might as well 33:04 have the developers there because they're incredibly helpful. 33:05 I know not everyone has the luxury of doing thing, things that way, 33:08 but we thought at first that that was gonna be really stressful as well. 33:11 And it turns out people just go,okay, we're good. 33:15 >> [INAUDIBLE] 33:19 >> It's mostly the part where you tell them 33:20 it's going to cost the same, that fixes it. 33:22 [LAUGH] >> [INAUDIBLE]. 33:24 To a project if they have like one project [INAUDIBLE] and 33:27 then another project in development which could go to that company? 33:30 >> Probably not. 33:36 We do a lot, we're moving a lot towards strategy these days. 33:37 So a lot of the beginning part of the process, into the prototyping. 33:39 So there are definitely some projects where we don't handle the 33:44 final visual design or we don't do the frontend development for it. 33:46 But that's part of why we're focusing a bit more on prototyping these 33:50 days because we want to make sure that whatever part of the process we're 33:53 involved in we're delivering something that communicates 33:56 really well to the final team what 33:58 they're supposed to be building and is gonna be most effective for the users. 34:00 >> So a developer actually has a place in 34:04 that first project even though it's not a developer project? 34:08 >> Oh yeah, yeah. 34:11 actually, my co-worker Tim sitting right behind you, he's our development director. 34:11 And what he likes to say, is that everyone of 34:15 fresh soils and experience designer, just some people's tool and Photoshop. 34:17 Another people's tools are code. 34:21 [SOUND] Any other questions [SOUND] All right, thank you everybody. 34:23 [APPLAUSE] 34:31