 My name is Jeff. I'm a user experience designer and design manager. I work for Aquio, as the slide suggests. And I've been doing user experience design for about 17 years. Most of that time, my work has been focused on creating web applications versus websites. So in those web applications, it's largely role-based, permissions-based, profile-based. So not unlike Drupal. So Drupal was a pretty good fit. In addition to being a user experience designer, I'm also a design manager. So I've spent a lot of time working with companies, building user experience departments, and making sure that design and user experience fits within engineering and product and marketing. And in that time, I've learned that selling design is really hard. And that most of my customers, albeit through the freelance world, or through working for their different companies I worked for, I've just learned that customers have certain expectations on design. They sort of think design is just brand. The thing at the end that makes pretty pictures or that makes a pretty interface that ties on to the end. And so a lot of my work is trying to convince them that's not necessarily the case. I think some of their obstacles that I've hit is that they, like I said, they map design to just visual design, but additionally on top of that, they see deliverables and user experience like usability testing, and they have preconceived notions and ask questions like, why would I do usability testing when I have QA? Do I have to pay for both of those? Or why would I do design research? Because I've done the business analysis, I've done the competitive analysis, and because of that, I can accurately represent the user. So I don't really want to extend my timeline and pay for design research or usability testing. And so being a design manager is a lot of solving problems like that and ultimately trying to avoid situations where you have interfaces like this. So as bad as this looks, I've got to give a few props back to Microsoft, believe it or not. It takes a lot of work to build a UI like this. You actually have to go in and assemble all kinds of toolbars. But the thing I find interesting about it is if you look at all the redundancies in here, I think you see things like the checkbox mod thing, the checkbox control here. I think it probably shows up like three times. So they haven't done the work for solving the redundancies in the UI, but I also think that even though this isn't the default out-of-the-box experience, it paints a really good picture in terms of a general design rule, which is try to focus on the 80%. In this case, using Microsoft Word, your 80% is to create a document, bullets, justification, italics. And so your 80% is down here. You type in this little tiny place. Versus your 20% is all this other stuff. So it's exactly reverse of what you'd expect in a user interface. But again, props to Microsoft and the fact that most of the time they did lead with the 80%. None of these toolbars show on the surface. So about 10 years ago, I watched this video that NBC produced where they interviewed IDEO. Did everybody know IDEO, the company IDEO? Not many. So IDEO is a company in Santa Clara, California. And you're probably all using IDEO products. They're probably the most successful product design company in the world. They've designed things like, well, they designed the original mouse. They also designed, you remember the toothpaste things there? We always had to screw on the cap of the toothpaste and always made a mess. Well, they designed it so that you can stand a toothpaste bottle straight up and a flip top cap, just general things. And when I watched this video, I realized that the video does an awful lot in terms of painting a really great picture in terms of solving the obstacles that I was having with my clients, albeit in freelance or through jobs. They do a really good job at showing the value of creating an end-to-end user experience process. And the thing that's interesting about them is that in this video, they were asked to do this in five days' time. And because they're so successful, it's really kind of hard to argue with their design process. So the video series itself is actually like an hour long. Obviously, I'm not going to show you the whole thing. I've cut it down to its bare bones. But if you're interested in creating a culture that fosters innovation, I highly suggest you try to find this series and watch the whole thing because it's just a brilliant video. Here was the premise of the program. We went to IDEO, the product design folk, and said, take something old and familiar like, say, the shopping cart and completely redesign it for us in just five days. Nine in the morning, day one, and these people have a deadline to meet. So welcome to the kickoff of the shopping cart project. This is Palo Alto, California in the heart of Silicon Valley, and these are designers at IDEO, probably the most influential product development firm in the world. We're kind of experts on the process of how you design stuff. So we don't care if you give us a toothbrush, a toothpaste tube, a tractor, a space shuttle, you know, a chair, it's all the same to us. We want to figure out how to innovate by using our process of applying it. And so for the next five days, the team will apply that process to bringing the supermarket shopping cart into the 21st century. The team splits into groups to find out firsthand what the people who use, make, and repair shopping carts really think. Okay, go. The problem with the plastic cart is the wind catches it. And these things have been clocked at 35 across the parking lot. Man, that's actually a pretty good point. The trick is to find these real experts so that you can learn much more quickly than you could by just kind of doing it the normal way and trying to learn about it yourself. From everything I read, these things aren't that safe either, you know? So probably the seed itself is going to have to be redesigned. What you're seeing here is the kind of social science anthropologists. You know, like you go and study tribes. What is it that they do that we can learn from that will help us design a better cart? One of the interesting things for me is looking at how people really don't like to let go of the cart except for the professional shopper whose strategy is to leave the cart at various places. Each team is going to demonstrate and communicate and share everything that they've learned today. People went off into the four corners of the earth and are coming back with the golden keys to the innovation. A shopping cart has been clocked at 35 miles an hour shoveling through a parking lot in the wind. We were in the store what, two hours? And it was truly frightening just to see the kind of stuff going on. You got to designate some people to make damn sure that the store's point of view is represented. After nine straight hours, the team is tired. They call it a day. Day two at the start of IDEO's unique brand of brainstorming. They call it a deep dive, a sort of total immersion in the problem at hand. IDEO's mantra for innovation is written everywhere. One conversation at a time, stay focused, encourage wild ideas, defer judgment, build on the ideas of others. That's the hardest thing for people to do is to restrain themselves from criticizing an idea. So if anybody starts to nail an idea, they get the bell. The deep dive begins and for the next few hours the ideas pour out and are posted on the walls. Oh, the blind, the privacy blind. Like when you're buying six cases of condoms, no one sees nesting. It sort of has to nest. If it doesn't nest, we don't have a solution. Bell crow pants and bell crow seats for the kids and you just drop them down there. Bell crow seats? Bell crow pants for kids? Yeah, see, you have to have some wild ideas and then you build on those wild ideas and they end up being better ideas than if you said, if everybody only came up with sane things, you know, kind of appropriate things, you'd never, like, have any points to take off to build a really innovative idea. It's organized chaos. Organized chaos. It's not organized. What it is is it's focused chaos. By 11 a.m. the group begins narrowing down the hundreds of ideas written or drawn on the walls. How? By voting for them. Vote with your post-it, not with an idea that's cool but with an idea that's cool and buildable. Okay, Peter, we're done. Back at the shop, it is six o'clock and the four mock-ups are ready for showing. Baskets also can be... If you think you will have more volume, baskets can be put in. A modular shopping cart, you pile handbaskets onto. A high-tech cart that gets you through the traffic jam at checkout. You could mount a scanner on the shopping cart so that you as the customer, as you pull it off the shelf, would scan each item. One that's built around child safety and another that lets shoppers talk to the supermarket staff remotely. Yeah, where can I find a yogurt? But the adults again decide more work needs to be done before the mock-ups can be combined into one last prototype. Why don't we have all the carts come up here for a second? I think you take a piece of each one of these ideas and kind of back it off a little bit and then put it in the design. The design is still not there, but there's another motto at IDO, fail often in order to succeed sooner, and some of the team will be up half the night trying to put together a design that finally does work. So we took the best elements out of each prototype, designed this entire cart in a day, and then this cart was fabricated in a day with an amazing team of people in our machine shop pulling this off, working in shifts throughout the night. Wow, I'm impressed. So are we. The cart which is designed to cost about the same as today's carts is different in every other way. Hand baskets that stack in a metal frame and major improvements for all. You just lift the handle up, you put the children in, and then you can close the handle right over them, and they instantly have some little bit of a work surface that they can play with. What do you think? Well, I'm very proud of the team. I think it's great. Does this work for you? Works for me great. It's also beautiful. I mean, let's take it over to a local supermarket and see what they say. Yeah, it works really well. The cart's wheels turn 90 degrees so it can move sideways, no more lifting up the rear in a tight spot, and you shop in a totally different way. Rather than taking your cart everywhere you go in the store, through a crowded store like this, it's much more efficient to take a small basket and rush around to where the particular shelves are and come back and put them here. Treat this as like a center for your shopping. And with a high-tech scanner so that in the future you skip the checkout traffic jam. That's how you would scan an item. Reach over and pick up anything like the salad dressing, and I would scan it, and if I want to accept that item I would just press plus and then drop it in my basket. Because stores don't yet have those high-tech scanners the team designed, checking out today means doing it the old-fashioned way. But the bags are hung on hooks on the cart's frame. Remember, there is no basket here. Why get rid of the big basket? The basket is tyranny. The basket is tyranny because it's not really needed. If all your stuff ends up in bags, why need the basket in the first place? Talk to me about theft. There's no value in this cart without the basket because you can't carry anything. It's useless to anybody. There's a barbecue, so it's not going to get stolen. That's right. So this ought to appeal to store owners. Yes. I love it. I think it looks great. At first I was a little shocked, but I think you have some fantastic ideas here. It needs a little refining, but I think that it's great. I mean, we would want them. It makes us feel great. And she also gave us some really good comments about how we can make this thing better. So here's why I like that. Number one, they went out and they basically assumed that I don't know what people who need shopping carts need. If I was to just tackle this without doing contextual inquiry or anything, I might just look at just shoppers and maybe streamline the shopping cart, but by doing contextual inquiry, they learned that safety is a concern, that speed across these things, across the parking lots is a concern, that theft is a concern. They learned that the regular shopper, which is probably your default expectation and if you were to do this yourself, it's like, I'm just going to design this for the shopper, that that's not the only actor, that there's the store owner, there's the guy that pushes the cart, there's the shopper, there's the professional shopper. In addition to that, they basically were able to brainstorm on all different kinds of ideas really rather rapidly. And on top of that, they basically said, a design is not good enough, I have to actually use it. I have to prototype it, I have to play with it, I have to understand how it works. And then after that, they brought it to market to see how that prototype actually works, pretty much a user experience design process on the web today. Now, the other interesting thing about this is that all of this work was done in five days and not a single ounce of money, or ounce of money, or any money, was spent on manufacturing. So they now have a design that's completely validated, they know it works for their target and nothing has been spent on engineering, which I think is just phenomenal. I don't know how old the study is, I think it was 2006, IEEE did a study on why software fails. And they basically said something along the lines of overall $1 trillion is spent on IT. And of that $1 trillion, 15% of all projects fail because of a lack of requirements. And on top of that, 50% of that is work that's unavoidable. And then last, fixing an error that happens after something has been manufactured cost 100 times more than that as if it was found ahead of time. And so these guys have fixed all of those problems in something that actually took manufacturing, I mean they had machine presses and everything to build that thing. And so they've solved all of these problems and if we can do that on the web, imagine how much money we could actually save. So this statement seems so obvious. It's written by Whitney Hesch of HappyCog who is a really wonderful interaction designer that basically says to find the right solution, the how, we need to prioritize the features we invest in, the what, and to determine our priorities we need to define the problem, the why. And to define the problem, we need to identify the intended audience, which red-backwards means you pretty much have to know who you're designing for in order to understand what their problems are in order to come up with solutions to those problems in order to execute against them. And despite how elementary that sounds, I see over and over and over and over and over and over and over again people that cannot do this. So let's transition a little bit into the web and the types of things we're doing at Acquia to try to... well, I guess not all of us is at Acquia, but it's the things that I advocate for and try to do. Some of this stuff doesn't quite make sense in Acquia, but I've included it because different products may require this more so than ours. So identifying the who and the why. Who's using your software and what problems are they having? Or why do they need a solution? The first one is pretty much what we saw in the video, which is contextual inquiry. I think the video was a little dark. I couldn't tell from where I was standing. It was where they headed in a co-odd section. And it's basically field researchers that are rooted in ethnography or anthropology that go out and observe people and try to understand what their natural behaviors are. It's really good for fleshing out the why or in the case of the shopping cart where you can just go to the grocery store also understand the who. Who's using it and what problems are they facing? In terms of the cost, I mean, it depends. It depends on whether you're going to do this yourself and just go and observe. But basically it comes down to something like some moderator or a field researcher that I'll see up above. I have one to two moderators. And if you have to compensate the participants, it's $50, $75 to compensate them. Again, in the case of the grocery store, there is no compensation. You just got to go there and observe and figure out how people are shopping. Surveys kind of goes without saying, but surveys are another way to kind of reveal why people are having problems on your site. It's not, even though I say it's good for fleshing out who, it's not the best for fleshing out who, but if you do lead your surveys with things like what's your primary role, then you may learn through doing a survey of your software that maybe who's using your software is different than you expected. I've listed on the side this whole presentation that's kind of formatted this way. There's these different services or tools that I use. Some of them I know a little bit more of than others. Some of them I actually learned through creating this presentation. And the ones with arrows pointing to them are tools that I use or we use regularly. So Woofoo and SurveyMonkey have been around for a long time. You probably know about those. They just good survey with a lot of good analysis. Drupal Gardens has web forms built into it, so that's also really good for doing some basic surveys. The analysis needs to come up to the other tools, but still good things. Zoomerang is a lot like Woofoo or SurveyMonkey, except I think they give you two more questions for free over Woofoo. So like Woofoo, you get 10 questions, 100 response for free versus Zoomerang, you get 12 questions, 100 response. Interviews are probably my favorite method of coming up with an interface, and basically it's just a one-on-one interview with the experts of the problem that you're trying to solve. How many of you guys have used Views 3? So Views 3 was a good portion of it was my design, and the way that I did that was, it was actually one of my favorite recent projects, just because working for Aqua, we have a staff of people that train people in Drupal. We have a staff of people that help people with their problems, and we also have a staff of people that kind of go on scene and get people up and running on these things. So I had experts all around me on this Views project, and so it's really just sitting with them, learning about their problems, learning about their desires, and taking all that analysis and blowing it up and being like, okay, well, 80% of the people wanted these particular features, and therefore that's what we're going to build. Unfortunately, there's no services or tools, it's just a matter of using your time to schedule it and make it happen. Usability tests, so I'll cover this more later when we get down and start talking about the what and coming up with ideas, but it's basically just, if you have a product already, it's really just asking people to go through your product and understanding where the pain points are or those products. There's two different types of tests, which I'll cover more of later, too, which is moderated versus self-moderated, and then there's actually a third one called static self-moderated. And then, of course, there's analytics, right? Probably everybody's using analytics if you're on the web. Some of the popular ones, Google Analytics, which is probably what most people use, but CrazyEgg is another really interesting tool. What CrazyEgg does is it has a bunch of different things, so the two things that I think are most interesting about CrazyEgg is it provides heat maps that show where are people clicking and where are they scrolling. Are they actually scrolling all the way down or not in missing important content? But where it gets really interesting is it understands the data that's coming to the site. So if you searched, let's say you were using aquey.com as an example, if you had CrazyEgg installed and somebody came to aquey.com and had searched for Drupal, well, it'll provide a heat map that's based on that search criteria. And so you can see where people are clicking based on that search, versus if they had come into aquea using Yahoo and searched on CMS or something. Maybe they're the same clicks. Maybe they're not the same. I guess one thing to note about analytics is a lot of people pay an awful lot of attention to unique page views, which obviously can tell you some things, but there's things that you gotta watch out for there, too, and that just because your site bumps up and you're getting more traffic, it doesn't necessarily translate to exactly maybe what you wanted. I think there's a lot of work to define the metrics that you want to use in your site. So, for example, again, page spikes doesn't necessarily mean what you wanted to. Maybe if you look for number of comments or something like that, that could tell you a little bit more about loyalty or number of comments by the same user. That could tell you a little bit more about loyalty, too. And then there's other things that come into question like what's more valuable if somebody that comes to your site every single day for 10 minutes or somebody that comes to your site for four hours and leaves and goes and tells all his friends about the product, that latter one you're not gonna be able to get through analytics. So if you're gonna use analytics, a lot of these other things come into play, too. You may get that information through a usability test where they get done doing some tests and they're so ecstatic about the product and maybe they tell you, I'm gonna go tell everybody about this. So analytics is only one form of method to kind of understand what problems might you have on your site. Oops, I lost my control here. So what? Now we know who's using our product and why they're having problems, why there's a need to do anything here. Now we kind of got to understand what are we gonna do for them? What's the process of arriving at various different solutions? One way that we use is using design principles. And a design principle is sort of a guardrail for the design process. So I've listed Aquia's design principles on the right here. Yeah, they differ pretty much every product. I was gonna say they're mostly for Drupal Gardens, but they're negative for every product. And so a really good example is, let's say you're trying to figure out whether you want to add a feature or not. You got a couple of people on opposing sides. I think our users need those. I think they don't need them. So you're not really sure. There's probably a case for them to use it, but not 100% positive. And so you can have a design principle that says when in doubt, go without. And so that doesn't, if you were to look at your personas, that doesn't tell you, I mean your personas, it doesn't answer that question, but a design principle does. So a good solid set of design principles is really helpful to kind of keep the experience creation process going in the right direction. I'm really just scratching the surface here. If you Google design principles by Jeremy Keith, he does just a fantastic job at talking about what goes into a design principle and how they work. In fact, I think he's got an hour-long session just on design principles. So ideation. One of the things, just to point it out, I've got this little accelerate tag at the top. And so the point of that is that I think there's ways that we can accelerate design, which also addresses some of the concerns up front about selling design and some of the misleading facts about design. I think that if we can accelerate and get faster, then we don't have to answer the questions of why do we, you know, or respond to the cutting of usability or cutting of design research because they're too expensive. So if we can accelerate and get faster, then, you know, obviously the whole entire design process is going to get cheaper. So what ideation is is very similar to what IDEO did in the beginning, where they did the contextual research. Now they know who and why, and they're all kind of getting together and brainstorming and coming up with a solution that potentially works. The way we've done it in the past is we create a design brief, which is sort of a loaded word that sounds a little scary. But when you think of design brief, you think 10-page document. That's not what this is. This is maybe two paragraphs outlining the problem that you're trying to get to. And then you go around, you bring in all the stakeholders that matter. If it's a whole bunch, maybe you got to do a bunch of these series or maybe the duration is a little bit longer. We try to keep these to an hour, and at an hour we've found that six participants is the max that we can hold in an hour. And the way that it works is everybody has this design brief and all the people that are involved in the room are asked to sketch a solution to the problem. And after they sketch a solution to the problem, they have to present it. You don't have to go be a good drawer. In fact, most of the sketches that come out are hardly even legible, but they at least give you points that you can talk to. And so they present their designs, and after they've presented, everybody in the room goes around and critiques that design. And they give three positives and three negatives. And then at the end of that, you have a document that looks something like this. So, I don't know, it might be hard to read, but I can kind of walk through it. So at one point in time, we had this problem in the Drupal Garden steam builder within height. We put that in there to control the dibs and change the columns of things, and it was causing all kinds of problems. And so we had a design brief that said, we need to fix the design, we need to fix the width and height, but it's not a process of removing it. What's the solution that we would actually do to put it in? And so this is only a subset of the people that participated. But everybody went around the room, sketched just as I said, and critiqued the person that did the design is inside of a Google Doc capturing the feedback from other people. And as soon as you hear something that two people liked, it gets an additional tick, et cetera, et cetera. So it looks like the colors are a little off here. I can't really tell from my perspective, but, you know, I did this just for this presentation, but what I did was outline all of the issues that nobody liked, and all the issues that people did like. And the great thing about that is, you know, when you leave that, you can at least know that you're designing something that's not going to the stuff that is just not going to go anywhere because nobody, none of the stakeholders liked it. You may go an entirely different direction, but at least you're not going down that pitfall of coming up with designs against the things that nobody's going to buy off on in the end. So task flows, I actually thought about omitting this slide. They're kind of, I mean, they've been around for a long time, but the reason why, I mean, I don't do them anymore, but the reason why I don't is because mostly I'm working within a predefined system. For example, views doesn't really need task flows. However, when we started doing Drupal Gardens, the whole process of registration and how understanding all the touchpoints of registration, those had task flows. And that's really the main point of a task flow is to understand the site at the 50,000-foot level. So if you were to think of an analogy of Google Maps, the U.S. boundary with all the different states might be a page flow. It doesn't give any details. It's just really kind of talking about the high-level stuff. Some of the tools that have been around forever are things like Illustrator, Visio, PowerPoint. But lately, there's been services coming out like Kaku, I think is how you pronounce it, Lucid Chart and MindMaster. I think they're probably better than the old-school tools like Illustrator and Visio because they're immediately online and everybody can kind of collaborate in terms of what that task flow is outlining. This is an example of a task flow I did probably like, I don't know, 12 years ago. And it's just a furniture exchange connecting manufacturers and distributors. And it's for a given use case. And my point was to figure out all the pages that were going to be involved and then kind of break out. I even started getting to this wireframe to understand what that might look like once I actually did get to this phase. Grayboxing, I think, is kind of a new term that's popping up. It's, in my mind, it's not any different than a wireframe except it's a conceptual wireframe. It's just kind of looking at an A-specific page and trying to figure out what are the big areas that are important. And you're using them to, if you have a customer and you don't really want to get down into the weeds and have them critiquing what a specific link says or where a specific link falls or the structure of a table. That's what it's for. It's to kind of say, just look at the page and try to get a general sense of what it is. This is a gray box that was produced by Floor from Chapter 3. And in my mind, this is actually a little too close to a wireframe if this was my idea of a gray box. The navigation at the top there wouldn't have been broken up into five buckets because then you're starting to make connections like, oh, are you only saying that I'm going to have five links up there? Instead, I think it's better if it's just a single bar that says this is navigation. Additionally, you get into these things right here where it says like block header and kind of gives a picture and the details and that kind of creates questions like, well, what kind of imagery are we going to put in there or why does it say block header? If this was my gray box, it probably would have just been a feature goes here, a feature goes there. This would be content, that's the primary area for displaying major featured content. And what it does is it allows the customer to at least understand where your head is at in terms of how things are going to be placed, where is my logo going to go, et cetera. Storyboards are sort of my sweet spot and I think they're different than a wireframe in that a wireframe by nature or by definition, if you look at Wikipedia, a wireframe is a black and white skeleton of a site or a UI. And a storyboard in my mind can be that if it wants to be, but more importantly, it's sort of representative of the end state. And I think we haven't seen storyboards around an interface design largely because of the tools that are available to us or the historical perspective of the tools that were available to us. So for example, in 1995, Don Norman coined the term user experience. So that was what, 16 years ago? My math is not all that good. 16 years ago. So the industry is really young. And 16 years ago, if we were to think about this user experience space that has blossomed into what it is now, back then there were just a couple tools available to you. Probably Illustrator, Visio, and Photoshop. And when you're working with a customer, you need to iterate as fast as possible to just churn through the different designs. And if you were to use Photoshop to do that, I mean, you just might as well just kill yourself. It's like they'll just take way too long. But fast forward to 2011, and that's not the case anymore. You can produce designs that look exactly like the end state, but at the speed of Visio or Illustrator. And so I kind of think the reason why we do these black and white designs is just based on history, but I try to move my department away from that so that you're doing visual designs and interaction designs at the same time, or at least you have that choice to do that. So, I just lost my thought there, but this is kind of an example. So, I've got this little test for you. So, which tests and sells better? And so what I mean by that is that, by test better, I mean, if I was to put this design in front of you and ask you to use it, how well do you think it would test? By sells better, what I mean is, if you are my customer, and I'm trying to present this UI back to you, which one of these designs are you going to get excited about? Which one are you going to probably sign off on and say, yes, take that to the next level? Uh-oh, I lost my connection here. The Wi-Fi in this conference is out of control. Okay. So, based on that, now that you know what I mean by test better, sells better, tell me which one of these you think tests better or sells better. A, B. They're all the same design, just different levels of fidelity. Or C. I mean, it's sort of a rhetorical question in this case, right? If I put a paper napkin in front of a customer or an end user, and I have done that, a lot of times they look at you like, you're smoking crack, you know, like, what do you mean you want me to test a napkin? You know, versus if I put something like this in front of them, they at least make the connection that this is an interface and that, you know, you want me to do something in this space. And so, you know, because it's a rhetorical question, it doesn't have a lot of value. But bringing it back to what I was saying, you know, now let's ask that same question in terms of which one of these do you think is faster to produce? A or C? I'm interested. B, B is fastest. Is that the general consensus? C is fastest. Yeah. Which one, what was that? All right, so I'll answer both of those. C is fastest. I was able to produce that at probably a 50% faster rate than I was able to produce B. A may have been faster if it was truly a napkin sketch that I scanned into the computer or something, but that's not what I did. I actually had a Wacom tablet and I was trying to draw this and I had to push them down hard to make it like show up. So, you know, if you can do this at the speed that you can do those other ones, then why would you do a wireframe? And before I come back to your question, Claudio, it was Claudio, right? Some people may say, yeah, but it's black and white, Jeff. You know, we're not even talking about the same space here, but this is a wireframe, too, right? It's completely in the end state. It's 100% vector-based outside of a few objects. Like, these are some 3D rendered files that were pulled into the vector-based file that allows you to still, you know, take this guy here and scale it and change the text and whatever, so it's pretty much just a wireframe except in its end state. And when I present ideas like that, my customers get excited, right? They're not looking at a black and white thing and they have to somehow mentally map that to what it's going to be. Additionally, I don't, you know, if I don't want to go to my customers first, if I want to prove out the design, I can actually go and test this with users and then go back to my customer and say, guess what, you know, this is the design and guess what, it tested really well. In terms of maintaining, C is still easier to maintain. As long as you're using the right tools, there's ways to create symbols and so, you know, I use fireworks for a tool to create all these things and I'm constantly in Drupal, so the way that it works for me is actually I'm constantly in Drupal and going back and forth between this site, even though this is a little bit of an older design. And so what I've done is I've created libraries of things like I've got a seven, you know, the Drupal admin theme is called seven, so I've got a seven combo box, I've got a seven field set, I've got a seven, you know, overlay admin, so for me it's just a matter of taking the fields and dragging them on, so. So let me stop for a moment and show you an example of the views project. So this is... Can you see that? Yeah. So this is a storyboard of views and basically the way that I map all these storyboards is for something as complex as views that has... I don't even know how many use cases in it. What I try to do is first map the general flow of the 80% case through the tool, which I'm not actually doing right here at this moment, but, you know, for example, I want to create the view, I want to show... I don't know what's a good example, I want to show just blogs, I want to create a page of the blogs, I want to show the blogs as teasers, as well as I want to create a block of titles and be done, right? That's a pretty common case. Or maybe I'm not quite done, but I want to tweak that view and add some various fields to it. That's kind of the common case and then you get into edge cases like I want to configure a table wizard, I want to add relationships, I want to add arguments, all the different edge cases. And so when you look at a file of mine, I have it broken up that way, so you have a main flow through the file and then the various edge cases and all of these are listed in one file. So let's get to that. So here's your list of views. I've got some specced stuff on the edge too, just so that it can actually go over to a module maintainer and they can execute on against it. How you could browse different code-based views, select a code-based view. This is your creation process. This is what it looks like on the surface. This looked like they were reversed a little bit, but if you say you're going to create a page, so you're showing a sequence of events through a different product, different contextual fields, what it looks like when you get into the view and just kind of see if I can screw this up on a Mac. So, you know, this file, what it looks like is I've got the... I'm lost without a mouse. So I've got these different states. You know, I've got the main flow, I've got other views, you know, table settings of what it looks like with a master query, you know, how the filters all work, how do the filters and or UIs work, all of which are certain task flows. And then when you drive into a specific page, so all of these are pages, a page has many different states. So these are the ones that I was walking you through, all the different states. And this is how I create storyboards. And the interesting thing about this too is that these are all ping-based files, so what I could do is just export this and they'd be immediately ready for consumption in a web-based prototyping tool, which I'm going to talk about in a moment, too. Additionally, I got that same Wi-Fi issue again, sorry. Additionally, if every now and then I get... Every now and then I get somebody who sends me wireframes or design mock-ups of Photoshop, and I'm initially like flashback like 10 years because I've got a zipped-up file, and the zipped-up file is like 300 megs, and I open up the file, and inside the 300 meg file, there's four wireframes, and I'm like... This file, which has, I don't know, probably something like 70 wireframes in it, its base file is probably something like 8 megs. So I can send this file around to a bunch of other people, and it's not all that taxing. Another example, if I go back to my home, maybe I should do that just because. So another example here is this idea of a marketplace. So Aqua has been toying around with building this theme marketplace or a template marketplace, and so these are some storyboards for those. And note that there's a slight difference here in that in this case I've consciously decided that I don't want to worry about brand, I don't want my viewer to be asking me, why do the stars look like they do? Why are the links that color or stuff like that? So I tried to strip it down to the wireframe approach, but I still consider this a storyboard because it's still task-based, and from this wireframe I can scale up to... I can scale up to the final finished result really quickly. And what I mean by that is, even though this is in wireframe mode, I can come over to this style guide that we have here, which has everything in here, and let's say I wanted to start to upgrade this thing really quickly, I can just paste attributes really fast. Maybe I don't want that one, maybe I don't want links. So everything just automatically comes up to a wireframe. I think I can even multi-select, and they all get adapted really quickly, take all these things, and really quickly I'm able to take this wireframe that I'd used solely for the purpose of stripping out this final result, but in a matter of an hour I can roll this up to... so maybe probably even under an hour, I can roll it up to look something like that. So that's kind of how I differentiate wireframes and storyboards, is that it's primarily task-based, it's a sequence of events. Unlike a wireframe, you can't really... it's not really a great tool to show how transitions work, and transitions are becoming a part of everyday web design with things like jQuery. If you were to kind of show what drag and drop might look like in a black and white wireframe, it's not really helpful, especially from a user testing perspective. Okay, so the next one, prototypes. So one of the things that we can do from a storyboard like that is export all the different states, and because they're sequential, you expect that you can just click, and if you're going to be... if your plan is to do usability testing, you can map out these tasks and have those tasks work to those master flows, export them out, and then use some of these various services out there to start to build these prototypes to figure out how it actually feels to work with. Now, a lot of the services that are out there, they're not really super-rich interactions. They're good for testing basic click-throughs. If you have really rich jQuery interactions, then you probably want to use something more like Dreamweaver or TextMate and more of a professional developer to take it to the level, but I just wanted to outline what they are and why they're important. And just like the IDO video, if I was to take that views design that the storyboard that I just showed you and send it over to a developer and say, develop this, I wouldn't be happy when I got it back because sometimes just you learn things through interacting with it just like with that shopping cart. They learned like, you know, I don't know what they learned, but I know they learned stuff through interacting with it. So I really kind of encouraged this notion of building prototypes and kind of learning from other industries as like, you know, going back to that user experience is only 16 years old. If, you know, there's other things that have been built for years that cost a lot of money and if we were to learn from those industries, you'd learn that all of them do prototypes. Like for example, if you were to build, you know, some type of skyscraper, you can bet that there's a prototype showing how the sun hits it and what it's like at different times of day. Additionally, cars also really expensive. There's always prototypes built for cars. So I think there's lots to learn from other industries and trying to build prototypes before you take them to market. So it can save a lot of money. Ooh, I got it back. So now we know who we're designing for, why they have problems now and we've come up with a bunch of ideas to solve for those problems. We basically need to validate. And so I put this quote up here because I think it's a really good one, which is, you know, an expert, there's a man who knows you stuff, but as a designer myself, I follow this to heart. I mean, I have some good ideas from doing this for a long time and I have some assumptions in terms of how things will work, but I never really believe that I know the answer. I believe that my customers know the answer. And so I think you always should validate whatever you're building that seem to be working. I got it back, but it doesn't work. So how do we do that? We can do it through moderated tests, which is what most people know by usability testing. And a moderated test is just that. You have somebody that's sitting in a room that's trying to guide a customer through a specific task. These can happen in a lab setting. They can happen in a remote setting. I've actually learned through doing both for many years that I think a lab setting is kind of a waste of time in that you can get largely the same results from a remote test now, given the tools that are available to us. And you don't have the problems that come into play with the lab. If you've got a lab and you've got multiple resources, well, you've got to schedule around that lab and so the lab becomes a bottleneck. Additionally, a lab costs an awful lot of money. Damn, I lost it again. Self-moderated tests. We kind of mix and match the two of these things. So a moderated test we do if we are really, really interested in getting the right customers involved. Recruiting can take a lot of time. For example, I cover this later, but one of the primary things that we use to find users is Twitter using my account or the Drupal Gardens account. So the people that are going to come in through those accounts are going to be people that are somewhat familiar with either Drupal or Drupal Gardens, versus if I want to learn more about designers that don't have any knowledge of those things than we would use a professional recruiter. And then along the sides there are these different services that are out there that allow you to do usability tests that are unmoderated. And there are some problems that come into play with that, but there's still a great way to supplement what you're doing to make sure that your designs work. So user testing.com is the service that we use, and we use it because they have their own pool of people that are already ready to go. So all you have to do is create a survey so that you're soliciting the right kind of people. And then user testing.com does the rest to try to bring those people in. And you basically set up a series of tasks that you want those users to do. And they go forward and do those tasks. And the outcome is a bunch of recorded videos that you then have to do analysis on. But, you know, it doesn't really take any of your time except for setting up the test and pointing them to the right location. And then all the testing and everything happens and the sidelines, which allows you to do two or three or four tests at once. You can have one big moderated test going on at the same time that you've got four or five or 10 self-moderated tests going on. And then there's the static image self-moderated tests. This Verify app up there is my new favorite of all of the usability tools that have come around. The static image self-moderated test is you're basically taking a image of a page like the Drupal Garden's wireframe I showed you earlier, putting it up to one of these services and you're asking them to do things with it. Maybe it's a five-second test where they have to tell you what stands out to them and if you present the UI to them and then take it down, they have to tell you what stands out or there's different things you can do with label tests, lots of stuff you can do there. But it's basically all around a static image and getting feedback off that static image. Navigation tests. So there's this tool that's been around for an awful long time, WebSort, which was if you're trying to figure out the navigation of your website, the idea is to take a bunch of index cards and organize them all in such a way or ask people to organize them all in such a way that you can analyze and figure out what are the big patterns. It requires a lot of users to do the test, but it's good if you're not really sure what your IA should be. You can use a service like WebSort to try to help you figure that out. There's two different types of tests. There's open sorting tests and closed sorting tests, and the difference is a closed sorting test is you have a navigation in mind and you're trying to figure out how a bunch of people place various pages into that navigation. And an open test is you've got, you know, people are just organizing it how they see fit. A closed sort test, you need less people than an open sort test. The other tools there, I think, are pretty interesting, too. A tree jack and plane frame. A plane frame is actually a child of WebSort, and what that does is it allows you to test your navigation devoid of the interface itself. So, in other words, it's like all you're doing is interacting with a tree structure. And you ask people, like, use an aqua.com, for example, we might say, you know, how would you learn about DrupalGuard and suaqua.com? And they're not going to the aqua.com site. They're actually just using this tree structure, and when they get it right, they say that they think they've found it. And that way, you can tell, is it your navigation that's working or not working, or is it the site design that's working or not working? DIY testing. Do-it-yourself testing. You know, so I whole-heartedly believe that anybody can do their own usability testing. There's just certain things you've got to watch out for. Like, you've got to make sure you're targeting the right audience. You certainly don't want to do a usability test or else you're just wasting a bunch of money. You have to learn to be unbiased, and that is, you can't ask questions that have the answers in them. Like, if you were to do... if you were to ask people and ask Drupal users to find content, well, the answer is given away in your question. So instead, you have to ask questions like, suppose you created an unpublished article a month ago, how, you know, can you tell me how you'd locate that article and republish it? That's how you can be unbiased in that case. You have to do more listening than talking. It's a really hard thing to do, but 95% of the job is just listening. And when they ask you questions, which they will ask you questions, it's pushing those questions back on people. Usually I tell people, you know, I'm going to do this, I'm going to push them back on you, and only when you feel that you would quit or bend in or call support, tell me when you would reach that point and then I'll give you the answer, and then I'll just know from that it's a task failure. So I'm not leaving them hanging. And then the last is you've got to document patterns. It doesn't do you any good to, like, fix every anomaly that shows up. You're looking at all your test results and looking for the patterns that show up and you're trying to address those patterns. You fix those patterns and then you reiterate and test again. So another test for you. Which of these tests, which of these UIs do you think tests better? A or B? A, show of hands? B, show of hands. A, interesting. So this is from Jared Spool a while ago. So, I mean, you can read it for yourself, but you're wrong. B tested better. And B tested better, because what happens is people try to sniff out information. They're looking for a specific keyword and sometimes you can shorten that information so much so that the information no longer makes any sense. But the point that I'm trying to make here is a lot of times when you're looking at a UI and you're making your own judgments, a lot of times you make incorrect inferences in terms of what the problem is. And so when you look at what happened after this, it's really kind of funny. So, you know, this is what the customer of this specific test said. So it seems that business executives prefer to look at fairly plain textual content online rather than cheerful graphic interfaces. Plus they prefer vertical to horizontal groupings. You know, of options that are longer, wordier, textier click links. After I thought about it a while, it made total sense. Users are trained to allow their eyes to scan down something that looks like search results, which was what it looks like. Graphics and images are not what the eyes train for online. You know, it's like, so this guy has, like, he's made these inferences and if he didn't have somebody like Jared Spoole on there to help him through it, you know, he'd run into trouble. Am I out of time? Okay, all right. So that's all I had, I guess. So thanks.