SpoolCast: Documenting Design with Dan Brown Brian Dan Brown interviewed by Jared Spool. Recorded November 25th, 2008. Christiansen: [music] Brian: Welcome. I am Brian Christiansen, producer of UIE Podcasts. In this week's episode Jared speaks with Dan Brown, the founder and principle at Eight Shapes, a user experience firm based in Washington, D.C. Dan is author of the book "Communicating Design: Developing Web site Documentation for Design and Planning, " which discusses documentation for usability testing, content inventories, wireframes, and more. On that same note, Dan will be presenting "Communicating Design: Essential Deliverables for Highly Effective Design Teams" at our Web App Summit, which takes place April 19th-22nd, 2009 in sunny Newport Beach, California. You won't want to miss it. And now here is Jared. Jared Spool: Welcome everyone. I want to welcome you to another interview on the SpoolCast here. Today I have with me here Dan Brown from Eight Shapes. He wrote the book "Communicating Design: Developing Web site Documentation for Design and Planning". He is going to be presenting at the UIE Web App Summit in April in Newport Beach, California. Dan, welcome. Dan Brown: Thank you Jared. It is a pleasure to be here. Jared: It is great to have you. So, now, you wrote this must-have book here about the documentation that one needs to communicate great design to the team members. In this book it covers a whole varietyÉ you've got site maps, content inventories, personas, and usability test plans. I have just got to commend you. This is like an awesome book. I can't tell you how many times I have had clients come to me and say, "We need to be communicating with the rest of our team and we don't know how to begin to get this stuff down on paper or into our... Should we put it in a wiki or should we have it online? How should we do this?" You have really laid out these really nice comprehensive, and I have got to tell you, good looking diagrams here. Dan: Well thanks. The motivation came from having... I had to think about documentation for so long. My history is filled with working on very large clients, very large projects; lots of stakeholders. While I think a lot has happened in the three years since I wrote the book, that a lot of us still face these problems; multiple stakeholders, very complex projects. As much as new technologies can help us do those things, we still need simple and elegant ways to communicate to all of those stakeholders. So, I hope it remains relevant. Jared: I think it is. One of the nice things I like about your book and all your diagrams is that the diagrams are clear, they are concise, and they are professional looking, right? It doesn't take a lot to make a professional looking diagram. You just have to have a consistent layout and a good sense of sticking with a font and making it not be Comic-Sans. Dan: Yes! Jared: But, it is really nice because I think it is hard for people to take design of this type serious, but then when they see these professional diagrams they realize, "Hey. There is something to this." It is not just, "Hey. Let's get something out on the whiteboard and then we are going to go code." Dan: I appreciate your saying that. I think part of that comes from the underlying philosophy of communicating design, that you can break documentation down into its component elements. Where I think a lot of people who are working on documents get scared is they don't know where to begin with respect to creating those diagrams. So, hopefully the message in the book is, "Start with the basics." For each of those deliverables that you mentioned I boil it down to, "Here are the essential elements that you need to include. Focus on those." And then as that story develops, start to add to add additional layers... layers is a term that I use... layers of information to build up a more comprehensive or elaborate picture. Jared: Yeah, it makes sense. It is sort like taking the way maps work. You think of Google Maps where it just starts with the cities and the roads, but then you can put on it the terrain. You can layer on top of that the actual satellite imagery. Each layer gives you different information. Sometimes just seeing the road in its abstract form is all you need. Sometimes zooming into the intersection and seeing which way, where the store actually is on the side of the street, that is what you need. Dan: I think it is a good metaphor, because the notion of being able to present both a broad, holistic picture as well as some of the gory details, so to speak, or the street level details, we should say, is a challenge that a lot of design teams face. They need to communicate the big picture, the overall experience, to get buy in from... whether it be the marketing department or whoever maintains sort of business ownership. But, then those street level details are crucial for the development team. Ideal documentation should be able to do both of those things. Good documentation strives to do both and often has to either strike a balance or identify a means for doing both of those things; both the broad picture of the US National Highway System and then digging down deep into what that I-95 corridor really looks like; just to beat that metaphor to death. Jared: That is right. We can continue to beat it to death as this interview goes on. Dan: Yes. Jared: We will find other ways to map into that. Dan: OK. Nice! [laughs] Jared: OK. Back to reality here. So, the book has like 10 deliverables in it, right? Dan: Yes. Jared: It is sort of like asking you to pick you favorite child, but is there one or two that stand out in your mind as being particularly powerful, something that if you have to start somewhere, this is the place to start? Dan: It is a really good question. I organized the book around a very loose methodology. I really tried to stay away from methodology because that seems much more controversial than the outputs themselves. So, the book starts with things like persona and usability testing and things like that. Honestly the design work and the conceptual work are sort of the middle chapters there. The document that I get asked about a lot is concept models, and it has really emerged as my favorite child, so to speak. I imagine people who have talked to me before may get sick of me beating this drum, but the idea behind a concept model is that it shows the relationships between the important elements of a website. It provides some initial planning activities or planning outputs for us so we can start to get our head around, "What are the key elements here? What are the key living pieces of this site?" What is advantageous to a concept model is that it doesn't box you into any particular approach for displaying this information. It doesn't confine you to just showing web pages or web templates. The idea is all I am trying to show is the relationship between different concepts. Those concepts can be as concrete as a specific web page. It can be as concrete as a specific product type. It can be a specific person involved in the process. These end up helping us paint that big picture so that we have that foundation to start with as we delve into the details, which might be revealed through wireframes or similar deliverables. Jared: The concept model, it is really just a way to get that sort of initial slice. I guess what I am wondering about is do you use this when you are first starting the design or is this something that you find yourself updating all the way through the design process? Dan: It is a great question. I have used it in a number of different ways. When I was starting at a new government agency, one in which I had virtually no experience whatsoever, their business model was alien to me. The kind of stuff that they dealt with was alien to me. I used the concept model really just for myself; as I was doing research, looking at third party sites, just trying to get my head around, "Who are these people? What do they do? What is important to them?" A concept model I would pull together different audience types, different kinds of information that they were involved with. Because it was a government agency I could look at regulation and legislation and start to pull those things together and paint those relationships. So, at the very simplest it is a learning tool. It is a mechanism for me to learn more about the domain or whatever it is that I am looking at. Your point of, "Do I evolve it over time," I think it is an opportunity for us to take a first cut at, "What are the kinds of information on the site? How do those different kinds of information relate to each other? What might user expectations be around my ability to navigate this information?" Inevitably, because it sort of has one foot in design and one foot in more of a requirements gathering tool, it evolves over time to the point where I can, by the end of that iteration, look at it and say, "All right. I have a much better sense now of the kinds of templates that I need to create and the kinds of interactions that users might expect." Jared: OK. So, you are building this thing out and it is showing the different components of how the various parts of the design relate to each other? Dan: Yes. I have been doing a lot of work just in the last 12 months on product marketing. Big, big high tech companies that sell very complicated products. At the core of that information architecture is the product page. But, there is a constellation or ecosystem of information that lives around a product. It might be smaller products, so to speak, that support the product. It may be services that support the product. And then there is this whole mish-mash of assets and documentation, and white papers, and press releases, and all of the case studies, all of these things that relate to that product in some way. So using that as, in a sense, the hub that everything else orbits around, so to speak, the concept model helps me understand the range of content types that are available and then how people might expect to navigate from a product to any one of these other pieces of information. Jared: So, it would seem to me that one of the really nice things about the concept model is that you can pick a piece of the model, some area that you working in, and you can sort of take the deep dive and build out that portion of the model, leaving the rest of the concept model general and loose because you are not focusing there. Then when it is time to focus on another piece you can jump over there, take a deep dive in the model, just keep growing, and it naturally extends. Is that a true...? Dan: Yes. I have definitely used it in that way of, "Let's get our arms around the bigger problem here and then let's prioritize. Let's pick out one or two of these concepts where we really need to generate a new set of templates, for example, " if you are looking at more of a content focused site, "generate templates around these things and we can save the rest of it for later." A concept model may have elements that I don't even ever touch, but they paint that complete picture. If I am showing the relationship between, say, a case study and the very people who have to contribute to that case study, that may be relevant for a content management system implementation. But, for me as a designer of web pages it may not be relevant. But, at least that whole picture is painted so we are all working off that same foundation, so to speak. Jared: Is it a diagram that when you are working in a team different people are building out different pieces of it, or do you build it as a group? Dan: It is a great question. My experience has primarily been to use it as a planning tool for myself. I am continuing to study and explore how to use concept models in a more collaborative setting or as a client presentation tool. Sometimes it works well. Sometimes it doesn't. I think there are enormous opportunities to build concept models collaboratively. That is to say, people standing at a whiteboard identifying lots of concepts and trying to identify how those stitch together. As I have indicated previously, I think the use of this as a planning tool is still in its early stages. So, there are opportunities to explore there. Jared: Cool. What other tools do you feel are good starting points for folks that have a lot of power to them and don't often get used? Dan: We at Eight Shapes do a lot of consulting with design teams to help them instantiate documentation standards in their practices. One of the things that we do as part of that process is interview stakeholders and actually conduct surveys of the design teams. It has provided us with actually a relatively rich set of information about design teams do documentation. One of the interesting pieces that has come out of that is we have been able to compare people who create these documents, people like you and me, the designers, and then the people who need to use these documents, whether those be business stakeholders, developers, QA, or people like that. So, we compare between those two groups the level of appreciation of a document; honestly whether they like the document or not. One of the disparities that we notice is with flow charts, actually, where flow charts are maybe not enjoyable for us as the designers to work on. The consumers of the documents love them, generally speaking. That is to say, they tend to rate much higher among business stakeholders, IT folks, because I think, like we were talking about before with the maps, they paint that big picture to set context. As a designer, I think my partner, Nathan, has made this point, which I appreciate, which is, as designers we're mired in the details and we have that big picture on the back of our heads at all times, presumably, but people who are not necessarily as involved day to day with a project, may need a reminder about that big picture. And so something like a flowchart, which I should probably define formally for you, can provide that big picture, a view of: here's the overall experience, here's the overall interaction for this particular task. And then once we dig into the wireframes, we have that context. Jared: When I think of flowcharts, I think of well the 1970's. [laughs] Dan: Yes. Jared: You know these big honking things with diamonds for decision points and you represented output as something that looked like a tore off piece of paper and storage was represented by things that looked like a disk drum, which is probably something that nobody who is listening to this, remembers what a disk drum was [laughs]. Dan: No, but you know what's amazing Jared, is that language has survived. When I do my documentation workshops, I'll ask people to do a flow and I won't give them any examples beforehand. It's sort of my -- the closest I get to the Socratic method of education, which is, I'm just going to tell you what a flowchart is. I'm going to give you an assignment and you've got to invent a visual language, and people gravitate towards that. And even if they didn't use it in their own flows, when I put examples up on the screen, they recognize the symbols and they have an understanding of what those symbols are. So, they are wholly un- sexy diagrams, no doubt about it, but there are ways to improve the visual language, and I've got lots of examples in my portfolio of how I've tried to take that convention and evolve it to make it more attractive, or more readable, or more legible, but ultimately, people get those symbols. And in a sense that universal language is useful to us because it allows us to take our ideas and express them in a way, where at least we can start that conversation very easily with other people who may not be, again, as mired in the details as us. Jared: So, one of my memories of doing flowcharts is this really arduous process -- now in the days when I first started doing them, we didn't have online drawing tools. So, you did all the flowcharts with literally plastic template stencils. Dan: Yes. Jared: And you would draw out these shapes and you'd write in these stuff. And my sense was that it was really hard to sort of match the scale of the detail and where you were in the detail thinking with what you were trying to communicate. It's the map problem again. Do I show where every mailbox and sewer pipe is on every street, or do I give this high level look at the flow. You could so easily get mired in putting in every decision point and every question and every little thing, that it was very easy to lose perspective on what it was you were trying to communicate. It was really hard for people who were just getting started with flowcharting to understand what level of detail their audience needed. How do you help your clients figure out what's the level of detail, either in flowcharts or concept maps, or I guess any of these tools, what's the level of detail that you need to have to make the communication successful. Because, go to deep, it's a problem, right? Dan: Yeah. It's such a great question, because it's so easy. If you start to think of these documents as people, which sometimes I do, a little strange, you might imagine giving them too many responsibilities, right? And so you want to use some caution in trying to assign any one deliverable too much responsibility because it won't be able to pull it off, right? Every document, just like every person, has its limitations. The advice that I give, and to your point, it's really consistent across any document that you want to create, is to establish a purpose for it, which sounds self-evident. But, what we find is that a lot of people don't apply the same principles that they would to a design problem to their own documentation. By coming up with a purpose for the document, what am I trying to accomplish? What is this document's role in the design process? You can be smarter about the decisions that you make. It's like a novelist coming up with an overall theme for his or her story. Having that theme gives them an anchor, gives them something to latch onto, so that everything else is in service of that theme. Everything else is contributing to that message in some way and it allows you to be ruthless about decision making that you make. So you can look at it and say, "There's a lot of detail here that's not contributing to my purpose, so I'm going to leave that out." Or conversely, "I'm not accomplishing my objective here. I've got a story that's painted out here, but it's still missing a level of detail that's required to meet my purpose of, say, be very clear about the business rules for this particular template. There's stuff missing here, so I need to add that information back in." Jared: So do you test your documents like one might test a design? Do you put drafts of it in front of the audience and say, "Is this working for you? Tell me what you're getting out of this thing." Basically, do an iterative process on the deliverable documents themselves? Dan: I think it's my responsibility as a designer to do that. I think designers who don't test their documentation, however informally, are doing their clients and their customers a disservice. I might even go a step further and even before I've done any documentation for a project, show documents from a prior project and say, "This is the kind of stuff I do. Is this going to work for you?" Because at least you're getting - it's almost like competitive usability testing right here - sort of getting feedback on a preexisting format that gives you that starting point. HAFS doesn't believe that one should reinvent the wheel every time, but a good standard provides wiggle room to adjust to the needs of each new problem that you need to face. So, even though we work from an established set of standards, we also acknowledge the level of flexibility that we need to make sure that we're meeting the needs of whomever the target might be. Jared: OK. So, now you wrote the book a few years back, and it's at this point you've had a chance to sort of go around and really field test the book itself, and talk to clients and see how they're using it. What has changed in your thinking since the book has come out? Dan: Yeah, it is an interesting question, probably when I wrote it a few years ago, I never would have thought that my thinking on documentation practices would have changed. I think there are two ways to look at this. On the micro level, I might look at each document again and identify additional elements that are essential for a particular diagram or particular visualization that I didn't necessarily include before. So, my opinions on specific documents have changed. For example, I think my Competitive Analysis chapter is extremely robust and there is a lot going on there, that a lot of elements there that I say are essentially that maybe I would not come down so hard on that anymore. I think my thoughts on wireframing have evolved significantly where in the book I called Annotations Optional are not essential elements, I would probably say today that they are very essential elements. But overall, I mean to take a more macro view, I would want to draw a better bridge between all of these deliverables that in a sense they all work in concert, the deliverables that one selects as appropriate for one's project to work in concert to paint an entire picture. And so, the book treats each document in a very silo'ed way. Even though I do try and address some relationships between them, really they need to tell a bigger story. And the other aspect to it is this notion of documentation lifecycle which we talk a lot about internally in Shapes. That a document starts out as one thing and then evolves over the life of a project and that is not interesting to tell in the book. So, I think there is sort of more broader organizational issues that the book is missing, and that I would probably want to revisit. And then just with each deliverable, there are little, little things like optional elements or elements that I call essential that maybe aren't so essential anymore. Jared: Well, I think you know all those things seem really critical, particularly the lifecycle stuff. Definitely in the work that we have done, these documents do - I like that you sort of think of them as people and that you give them responsibilities, and their responsibilities change over the life of the project. At the very beginning, those documents are serving one purpose and then as you move through the project, they serve a different one and then you have someone new join the team and then also on the document service, you had another new purpose. Dan: Yeah, yeah. And in fact what we find is that people don't create multiple documents or if they do, they create a very small number and in fact that they are creating one and allowing it to evolve with the course of the project. Jared: Yeah and that makes perfect sense to me. Now you are going to be doing at the Web App Summit in April, which is going to be in Newport Beach. You are going to be giving a full day workshop on some of the documentation tools. Can you talk a little bit about what you will be talking about there? Dan: Sure. Well, like I mentioned before with my workshops I try and take a Socratic approach where I throw people into the fire, so to speak, and we do some hands-on documentation in class with the understanding that people are spending no more than 10, 15 minutes on these things. It does give us a chance to talk through technique and planning around these documents. So usually, the way I structure these is I will pick three or four different documents, will do an exercise around each one and then discuss them. And I think for the Web App Summit, which seems the most relevant besides flows and wireframes, which are the ones that I typically do, I have also done personas in the past, but I would be curious as to which documents people want to focus on as well. So, I would welcome some feedback as to which documents are most top of mind for people these days. The Web App Summit also gives me an opportunity to inject some of this new thinking into it. So, identifying not only some new best practices and techniques around creating effective flows and wireframes and other documents, but also revisit some of the core elements and the defining elements that I talk about in the book and take those to the next level. Jared: Well, if people have ideas of what they'd love to hear, they could go to our blog where this podcast is posted. You can get there uie.com/brainsparks or just click on the blog link on the uie.com home page and they will find the post for this podcast and in the comments, they could just put their ideas. Dan: Nice. Jared: Yeah, I think that is a good place for that conversation to start. Dan: I will subscribe to the RSS feed, so I can be immediately updated. Jared: Well, there you go. If you look at the bottom of the post, there is a link there where you can subscribe to the comments from the feed. So, everybody who is following along can follow that in their reader. Dan: Great. Jared: Well, I think this is going to be really a lot of fun to have you in Newport Beach and this has been really, really interesting. And again, for those of you who have forgotten since I started the podcast, we are talking here with Dan Brown and we are talking about the deliverables that come from design. Dan wrote Communicating Design, Developing Web site Documentation for Design and Planning. It is a New Riders book, a great book. I recommend that you get at least one copy off Amazon, maybe a couple for the rest of your team and in fact, it makes a great gift. Dan: [laughs] nice. Jared: Yeah. Dan: It is the season [laughs]. Jared: It is, it is [laughs]. This has been a lot of fun. Thanks for doing this Dan. Jared: Jared, I had a great time. Thanks for having me. Dan: OK. Take care everybody. Thanks for encouraging our behavior. Brian: Don't forget, if you would like to hear more from Dan Brown, be sure to join us for our Web App Summit, which takes place April 19th through 22nd, 2009, in sunny Newport Beach, California. Learn more at webappsummit.com. That's all for this week. Thanks for listening. Goodbye.