SpoolCast D Keith Robinson Brian Keith Robinson, interviewed by Jared Spool, recorded remotely from Christiansen: the studios of UIE, November 29th, 2007. [music] Brian: Welcome. I'm Brian Christiansen, producer of UIE Podcasts. In this week's episode, Jared speaks with D. Keith Robinson, creative director of Blue Flavor, a design and development shop operating out of Seattle, Washington. Keith is an expert on design and information architecture, most formerly editor-in-chief of Digital Web Magazine. Prior to agency life, Keith worked internally for both Boeing and Children's Hospital Seattle. Keith will be presenting his talk "Making the Translation: Critical Webapp Design Deliverables" at our Webapp Summit, which will take place March 26th through 28th, 2008 in Coronado, California. You won't want to miss it. And now, here's Jared. [music] Jared Spool: I'd like to welcome everyone to an interview with Keith Robinson. He is the Creative Director for Blue Flavor, which is a Seattle design firm. He's going to be speaking at the UI Webapp Summit in March, Hi Keith. Keith Robinson: Hi Jared, how's it going? Jared: It's going well. What we want to talk about today is lessons that we've learned when trying to get designs developed. The question I've been asking people--I'd like to ask you--is to talk about a project from hell. Something that haunts your past, just made your life a bit more complex than it needed to be. Keith: Right. Well, to be honest I think I've had a few of those, as most designer will probably tell you. I do have one in particular that I can think of that went very far south in numerous different ways. Since I've worked on that project I've changed the way that I work. And I can think of a few different things in particular that I've done differently that has helped avoid those kinds of situations. So, I'll talk about that one. I'm not going to mention our particular client. I was with Blue Flavor. But we had a client where they had basically two projects going on. One was a typical web frontend redesign, an informational based website. The other was a web application that they needed a whole lot of work, interaction design. They had an application pre-existing that they needed just a lot of consulting help with. Our first mistake, going into that, that ended up coming back to haunt us was, we didn't scope it out properly. We didn't communicate properly what we were going to be doing in specific. I think sometimes with smaller projects you can get away with that. But when you have a large project that has a lot of different specs to it, and you're working with a lot of different people, it's really important to not be inflexible, but be very specific about the kind of work that you're going to do. Along the way, parts of the projects went OK; parts of them were a little bit shaky. But we really took a lot of things for granted. Again, we had designed deliverables on both sites, the website and the web application site. We probably didn't do as a good of a job explaining, if that makes any sense. We created deliverables that were a little bit fuzzier than they should have been. Our wireframes, for example, for the application weren't annotated to the level of detail they probably should have been, which caused lot of rework on our end and on our client's end. It also caused misinterpretations of what it was we were going to be designing and building. So, when we got farther along in the process we ended up kind of building something that was a little bit different than what they had expected. A lot of this comes down to communication, but at the same time, we also probably could have done a better job being much more specific and explicit with some of those higher fidelity deliverables, wire frames, mock ups, things like that. Again it went back t the start, where we just weren't specific enough with our client in understanding what exactly they wanted. We just kind of did one of these things, which I think is fairly common, where we sat down, discussed the project. Thought we had a pretty good idea what they wanted. They thought that we had a pretty good idea of they wanted; when in all actuality those things weren't true. They were never documented. We didn't have any overarching deliverables that kind of defined the scope of those projects. Now we are really, really, really specific, not with everything, but with things that we feel need to be specific with, if you were to look at one of our job orders for example that we use with clients. We have a little, a box, a disclaimer at the top of our job order that says, you know: Common sense disclaimer. Please read this. Make sure that you understand everything in this document because we are going to be using this as the "Bible" going forward. If you are expecting us to do something that is not in here, we need to stop right now and make sure that we address it and that we document it and we know that we are working on that. And, you know, that is something that I've just learned in the last two years. I haven't been a business owner, working for a consultancy for that long, but I have seen a lot of these job orders and contracts and the way that people enter into business with each other and a lot of them are really vague. Jared: That can be true for internal folks, too, right? Keith: Oh, sure. Oh, definitely. In fact, it's probably less of a risk with internal folks I think but yeah, it is definitely true. It doesn't matter if you are a client service relationship or if you are an internal team working with another group internally or even within your own team. I think it's vital that at the start of a project you take the time to really... Obviously there research and kind of a requirements gathering phase where everything is kind of fuzzy, but when you really sit down and start to design and develop and build, not to be inflexible again, but you need to just have a really good idea of what it is you are building and you need to be able to communicate that accurately to everybody involved. Whether it's the stakeholders, the people working on the project that you know... if you are the designer you need to communicate to a developer what exactly they need to build and what kind of assets they are going to need from a designer end. In this case, we took a lot of that for granted, not realizing that we were doing that at the time. At the time we were just working away, thinking, oh, everything's great and when we got to the end, they didn't really get everything that we gave them. They didn't really interpret a lot of the stuff that we have given them correctly, which I put on us. We've made a lot of adjustments since then. Jared: In terms of the lessons that are learned and in particular this idea of having solid documentation as you go through your process and when you are building web based applications, the fact that you've got interaction that you are talking about. It's not just, we're going to put up this screen. It's going to have this content and we're done. But you've got business rules involved. You've got all these different aspects of it. How does one sort of plan out, based on what you learned from this project, how do you do things differently now? Keith: Well, there are a few things. I think first of all, this is something that I think is become really, really clear to me in the last year or so. Regardless of how great your deliverables are and how much that they communicate, they're never going to replace being able to have a conversation with somebody involving the right people in the creation or research that goes behind creating a certain deliverable. I think that that's one thing that in this particular instance I was talking about, and several others. Sometimes it's a budgetary thing and a time thing, and you just don't think about it. But you tend to put a lot of importance on your deliverables and let them carry a lot of the weight that sometimes they can not carry. There are certain things that a deliverable is not going to convey to somebody, but you assume or you don't worry about it. You just hand off deliverables to the next person in the chain, just thinking it'll be OK, and then they never come back and ask questions. The next thing you know, you're reviewing what they did and it's all off. So, I think the first thing is just keeping lines of communication open, not relying on deliverables. Just be a little bit more involved as a person, having a live body there to talk to people. There's that. Also, we've spent a lot of time trying to refine our deliverables, and create deliverables that are, A, appropriate for the right people. For example, our developer, something like a persona is probably not going to be all that helpful for him. He needs something that's a lot more detailed and what he needs to build than a persona. Handing him a persona, he may look at it and glean some information from it, but it's not for him. At the same time, I think it's important to make sure that deliverables are very accessible. Pretty much anybody involved with the project should be able to take a look at anything that we create as far as a deliverable, documenting any design, or development, or research of anything, and being able at least to understand what's going on with that. When it comes to the actual building of a web application, we've gotten pretty high fidelity with our deliverables. Nowadays we don't just do wireframes, for example. Wireframes on their own don't really communicate everything that needs to go into a web application. We have a little bit of a different process depending to client that we're working with. But my preferred process is to create something that I call screen description diagrams, or page description diagrams, which are very detailed. But they're not showing any visual layout, they're just pros that explain any interaction and different content elements or design elements. And then I pair those with annotated wireframes. Those deliverables really need to work together. If you look at them apart, they're not nearly as useful as they are together. Higher fidelity, more detail, and also trying to create a chain where our deliverables are linked and attached to each other, instead of being separate silent things. Jared: Say a little bit more about the screen description diagrams. Keith: It's a description of what would be on a particular screen, broken down by priority and attached to deliverables. So, for example, if I were creating a dashboard screen for an application, part of the document would describe the goals for that screen. You know, this is to give somebody a general overview of what's going on with the application, et cetera et cetera. Then, I break different interaction and bits of information into pieces, and then I rank them by priority and how they support the goals of that particular screen. Or, if you're talking about a website, it would be a page. Key here is that we're talking about a narrative rather than a visual line. A wireframe would show you layout, this is something that's a lot more narrative. Our clients love this. Jared: Yeah, I would think so. Keith: For whatever reason. I actually liked them a lot myself as a designer. For example, if I'm working with Nick [indecipherable], he's one of my business partners. If he's doing that research, upfront requirements gathering, and he hands me something like a page description, I don't feel somehow creatively pinched, but I still have a pretty good idea of what it is I need to design, if that makes any sense? Jared: Oh, it makes a lot of sense. I like that it's in priority order, so you can go down and the most important elements, like doing a dashboard, are status on current sales and status on conversion rate, and all that stuff. It would have something, I imagine, that would say, when I click on a given region in the sales chart, it would zoom in and give me detail about the region. Keith: Exactly. And the other thing that's nice about having it prioritized is, when you get further along in the design process, inevitably you will come across a situation where you may want to remove something to call more attention to something else. It really can show you what on these particular screens can be removed to make them more useful overall--from a visual sense, for example--where should I be placing the focus of the pages. But it doesn't show you, it tells you. Jared: Yeah, that makes sense to me. What I love is this idea that you're communicating through the position in the document what the priority is. So, if it turns out that there's some element which will render itself usually very small on the screen, but it's really high- priority, that's going to tell you how to color it, or choose your fonts or space it in the visual display. It's going to communicate that in this document. Whereas if you showed me a Photoshop image of the page, I may not understand why that thing as a lot of white space around it, because I don't know what the priority is when I'm looking at that Photoshop image. Keith: Right. For somebody who's not a designer, I guess what ends up happening sometimes is--if you just give somebody a Photoshop document, I'd have this happen to me with developers, they will change things because it makes more sense with how they built application with the business logic or whatever. Sometimes some things that I've deemed important, or a certain interaction was supposed to be done in a certain way and they're like, "Oh, we didn't do it, " I have to then go back and explain them why it was done, or why we needed to do it a certain way. And then they have to go back and redo it, whereas if you hand them a wireframe or mockup and screen description diagrams or page description diagrams, then they have a little of that background information. And if they read through it, they can get a better picture of, "Oh, you know what, I can't really modify this without going back and checking with my designer, at least to make sure that this is the right thing to do." Jared: That makes perfect sense to me. I had a project a few years back where we had done a paper mockup of a design, and we had tested it. We found that there was some specific wording on the screen that, when that wording was missing, nobody knew what to do. But when that wording was there--and we hand-wrote it on the paper prototype, that's how it worked--everyone knew instantly what to do. The client, because we don't have design resources in our team, hired another designer. That designer prettied it all up. But because we didn't do a good job of communicating that piece of text, that little piece of instructions, and they weren't sitting in on the test, they ended up putting it--it was still on the screen, but it was in a small font in a shade of the background where you could hardly see it, because they thought it would be ugly. Sure enough, when the screens showed up for the electronic testing, no one could use it again. We knew exactly what the problem was, because that text you couldn't see. That sounds like these documents would have solved that problem nicely. Keith: They may have. The priority's a good thing, just simply because a designer who maybe doesn't have the full benefit of the research and the background and everything, if they knew the priority, they're going to be less inclined to, say, make this bit of text dimmer or whatever, because they know it's a priority. So, there's that. And again, the description diagrams are something that you can pair with wireframes, for example, or even mockups. You can tie those two things directly. In fact, they aren't a whole lot different than doing a very well-annotated wireframe. If I had a linear process, I would just like to do something like a screen description first, because it spells out the goals, it kind of spells out to a certain degree the elements you're working with, what's going to be on the different screens. Obviously there are other documents; a developer might need a requirements document and all that. But it doesn't necessarily show what the design is. It gives you a little bit of creative freedom when you're first sitting down and sketching out those designs. And you still have a good idea of what it is that you need to design, what's going to be going on the page. Jared: That makes perfect sense to me. Keith: Yeah, they worked really, really well for us. Jared: So, what other things came out of this that you're keeping? Keith: Another thing, especially when we're talking about web applications, I think one problem that we've made or that I've made, I guess, in the past--my background lies a little bit more in informational web page designs. I've been doing web applications since the start of my career, but I didn't do them as much until very recently. Now we're about fifty -fifty. The deliverables, and tools and terminologies that you use for web page design contexts are different than web applications, especially when you're talking about rich Internet, Flash-based web applications. The interactions you can do there and the context to the user is different than a web page. So, when we first starting getting our first few web application design jobs here at Blue Flavor, Nick and I still would speak in our web page design lingo. A lot of the things didn't translate exactly. They are very similar, but we now try to draw a pretty hard line between the process we use to build a web application and what we use to build a web page, because they are just different. A designer or a developer doing a web application needs a lot more information about certain types of interaction, things like that. Jared: Give me some examples. Keith: Well, an example going back to the page description versus what I call screen description: the context of a page, something that's very informational website, whereas with a web application you're going to have multi-state screens a lot of the time. So, you'll have to describe not only more complicated interaction, but you'll also have to describe screen refreshes that aren't changing a page, for example. When you are talking to a developer, those things need to be described in a lot more detail, because otherwise you're just going to get a bunch of static screens with no complicated interaction in them. These are things that we would do, but we would all use our old web page IA process to do them. It's not exactly the best way to do it as far as a designer coming on down the road, or a developer coming on down the road. There's just a lot more to that interaction, a lot more behind the scene. It's a lot more complication. You don't need a formal requirements document when you are building a five-page informational web page. But if you're going to be building something that's got a lot of business logic, like if you're building Flickr, there's a lot more to that. And the terminology is different. Jared: Is the structure of the document different? Keith: Well, yes and no. To a certain degree it's similar, for example, when we're talking about screen descriptions, the difference between an informational-based website and a web application, for that document the structure's fairly similar. You're basically talking about areas on a screen or on a page. I say screen and page because that's how I separate the two in my head. The thing about listing priorities and different content elements is basically the same. It's just when you're doing screen description for a web application, you have to get into a lot more detail about the actual interactions. For example, a wireframe is a really good example when you are talking about the difference between designing a web page and designing for a web application. You have to annotate wireframe if you are doing a web application. Or, you have to be able to somehow show and explain interaction in much higher detail than you would with a simple web page. If I show a navigation bar for a website, I don't need to explain to a developer or designer usually how that's going to work. I might put something in explaining that if there's a rollover state or something like that. But in general I don't need to get into a whole lot of specifics. Think of Flickr where you can add in content within the page. That needs to be described in much more detail than something as basic as simple website navigation, for example. You know, and some of the terminology is a little bit different. You know, when you are in there, the terms aren't all the same, I guess. And again, especially when we are talking about developers, the level of detail and the level of complexity gets raised quite a bit. I guess on the user side, too, the context is a little bit different. One thing that I've been thinking about a lot lately is if you have a web application that's served to you in a web browser, but that application is rendered, not in HTML and CSS, but rendered with Flash, for example. Does the context and expectation change to a user? Can you do more desktop like interactions and still have them be usable? Does that expectation change? I don't know. If something's built and HTML and CSS is the front end, a user is going to expect that a certain level of web browser like interaction. A right click, a contextual menu in there might not be the best idea, because the user is not going to expect to be able to do that. Does that make sense? Jared: Oh, it does, it does. The other day I was using Google Maps and discovered by accident, not on purpose, I just accidentally clicked the right mouse and found out there is a right mouse menu on Google Maps. I don't know how long it's been there. I don't know when it first showed up. It turns out it has useful things in it like, you know, you can point to any place on the map and say, center the map here or zoom in, zoom out. That was completely new to me and it had been there for months and had I not clicked accidentally it could be another set of months before I discover it. Keith: Sure, we have a client actually that we have been working with and they came to us wanting to do a lot of, what they call, desktop like interaction. You know, we recommended against a lot of that stuff. Understanding who their user was going to be and understanding the context for which they were designing, it didn't seem like a good idea simply because, in a browser based context, the user's not necessarily going to expect that. Whether it's there and works well is a whole other argument, but there are not going to know. You could train them but at the same time, they wanted something that was easily accessible to a wide variety of different people, so we recommended more web browser traditional type of interactions than going with the right click contextual menus and things like that because of the context. But I do wonder if you did an application entirely built in Flash and your user based know that, I wonder if you could get away with a little bit more of that. I'm not sure, I just.... Jared: I think if it is in a browser, people don't expect the right menu to ever do anything useful. And, frankly, in Flash, it almost never does anything useful. Keith: Yeah, see you get the information about the Flash movie. Jared: Yeah. The right menu is what you click on to copy a link or save a file. Keith: Yeah, that's exactly my thinking, too. But anyways back to the deliverables, as far as the web page design versus web application design. I think, as far as communicating design decisions go and communicating requirements, I'm kind of a fan of over communication. Some people don't like that but I have found it to be helpful to me, so... Jared: What about it, knowing that people don't like it, what makes you persist with it? Keith: I'm somebody who, if I've got a question, I would rather make sure I have the answer to that question, most times, before I would go and get to far along, doing something kind of based on assumption. So, when I deliver documents to clients or to other people on my team, I really, really, really try to make sure they are as details as possible. So, (A) they don't have to come back and ask me questions. (B) They have as much information as possible for them to make their own decisions. All too often in my career, I have been handed some sort of design deliverable or research deliverable, that I've read through and really turned around and said, there is nothing in her that I can use. I like my deliverables to be able to tell somebody something that they can then do something with. I think that's a fairly common that people are creating deliverables out there that they think are communicating properly, but they're not. You know, we're creating a web application here at Blue Flavor, for example. We just started this fairly recently. It's an internal project and we involved our developer from the very start, because he is the guy that the buck is going to stop at him. He's going to be somewhat involved with everything, and I asked him at the very start. We talked about it, we had some documents, we outlined the scope of the project, who the user was, all of that. We had a pretty good idea of what we were building, which is a whole other can of worms that can send a project south. But we all had a pretty good idea of that, and then I turned around and asked him, "OK, you've been involved with all of this, you've seen everything that we've done up to this point. What are you going to need from me?" A lot of projects, we can't do this. Obviously this is an internal project, but he told me specifically what it was he needed. That's what we're creating, that's what we're documenting. Jared: That sounds really good. One of the things you talked about was, you mentioned early on in the project that was from hell, not having all the right people involved. Keith: Yeah. Jared: Are you finding that just getting everybody in the room on a regular basis, or on the phone on a regular basis, going over the details--you know, nobody likes more meetings. Keith: Yes and no. I guess the key for me is making sure that the right people are involved at the beginning. I do like the idea of touching base regularly. We tend to do that on our projects, I wouldn't say too regularly, and we do try to keep our meetings short. But I think the main thing I'm getting at when I mentioned that is just getting everybody involved at the start: making sure that before you get too far along that everybody involved with the project knows what they're doing, what the project's all about. Hopefully, they're involved if there's research. My ideal project, if I were to build a web application--like I said, Blue Flavor's working on one right now--I wanted to make sure everyone who's going to be working on that is involved from the start. When we're sitting down and brainstorming, talking about who our users are and what we want to do, the problems we're going to solve, everybody was in that room. And everybody was able to contribute to that. I think a lot of time, say, when you're working at a big organization internally and you're part of the web team, the web team is going to be developing a web application, you may come in halfway through, "Here's some requirements, here's some contexts, here's some wireframes, can you build this please?" I think that kind of a process, you're almost always asking for trouble. You may still have a successful outcome, but it's going to take a lot longer and be a lot more painful than if you just get everybody involved at the start. Now, that doesn't mean that you need to go and constantly loop everybody back in every time there's a decision made. I'm not saying that at all. But if you just get as many people as possible involved at the start, as long as it realistically or practically makes sense, you're going to avoid a lot of problems down the road. That's what we try to do. We recommend that to our clients. Sometimes we get hired to do design work only. They say, "We have a web application, we need you to do some consulting for us. Tell us how we can make this better. Maybe do some design work for us, and then we'll just hand it off to our developer. " We try to get one of our developers involved with in those meetings so that they can get an idea in case we have to bring him in later. But also, they can share some expertise with us about things that may be helpful when we give whatever our final deliverables are back to our clients. Again, it's a kind of a hard one, because you can't have everybody involved all the time. That's just not realistic. But I think the more you can do upfront with everybody involved that are going to be working its better. Jared: Right. I was reading a book recently called "The Point of the Deal". It's by Danny Ertel and Mark Gordon. They make a big deal about how a lot of deals are made without thinking about the actual implementation. They're all about getting the deal signed and then down the road someone else is going to have to worry about how we're going to implement this. Keith: We'll figure it out... Jared: Their point is that the most successful deals are the deals are deals where you deal with all these implementation issues up front. Get the people that are going to be implementing it into the deal make process and then they bring up the, "Well what about this case, and what about that case? How are we going to do this? How are we going to get things from this system to that system?" All those little things that really are the things that if you don't get those little details worked out very early on it really comes back to haunt you later. Keith: It's true. I know in our case - involving a developer, for example, in the web application process from the start -there's other benefits beside the fact that he's going to be more informed on what it is he needs to build from an early standpoint. They're smart. They'll think of things that we won't think of. It's not all about "OK, I need to know how I'm going to build my schema and how I'm going to do my developer stuff." They'll think about interaction. They'll think about what may be a feature that we think is really great for a particular product and it's really not. Or it's so hard to implement, it's not really worth it, that kind of thing. I guess what I'm getting at, it's not only to inform them. Having a lot of people in at the start doing the research and doing the brainstorming; if you're doing contextual inquires and you're talking to potential users, involve your designer. It's going to help build empathy so that they can do a better job when they're designing. Involve your developer. It's going to help them realize that some features really are important. Their input into that process I think is very valuable as well. So it's a win-win. From what I can tell, it's not rocket science. It doesn't take a whole lot of extra time. I think the savings in the long run, both effort and probably budget-wise, are probably worth it. Jared: Cool. This has been great. I'm very excited about your session at the web apps summit. Where you're going to talk about your processes and how you've done this in a little bit more depth. Any sort of last thoughts you have here? Keith: I'm really excited to distill a lot of my thoughts about our process and the process of others; deliverables and how we get thing done. And also get some feedback from people on what they do. Hopefully I'm going to teach them some things that will be helpful. But anytime you're teaching somebody something or you're engaging with somebody on that level, you are also learning some stuff. I'm really looking forward to it. Jared: Well excellent. I'm looking forward to it to. Well thank you... Keith: Great. Thank you. Jared: This has been great. We will see you in March. Keith: all right. That sounds great. Jared: OK. Keith: Bye-bye. Jared: Bye. [music] Announcer: We hope you've enjoyed this podcast. You can comment on this and other episodes as well as find more UIE podcasts at www.uie.com/audio. You can win free admission to our next virtual seminar by filling out a short listener survey about this podcast. Please see the corresponding blog post at www.uie.com/brainsparks for the survey link. You can enter once for every podcast you listen to. Don't forget: If you'd like to hear more of Keith's thoughts on deliverables for web apps design, be sure to catch Keith at our web app summit, March 26-28, 2008 on the sunny isle of Coronado just off the coast of San Diego, California. Learn more at www.webappsummit.com, that's all for this week. Thanks for listening. Goodbye.