Adaptive Path Blog

Two of the speakers at this year’s UX Week have new books out: Dan Brown’s Communicating Design: Developing Web Site Documentation for Design and Planning and Dan Saffer’s Designing for Interaction: Creating Smart Applications and Clever Devices (both from New Riders). The two Dans recently had a conversation about their books. This is part two. Read part one.

Dan B: Dan, some web designers believe that documentation is a waste of time because it distracts from the purpose at hand — namely, to build a good product. You indicated that Designing for Interaction discusses models as tools for designers. Do you think that models are essential to the design process? Are there other tools that you consider essential to the design process?

Dan S: For me, Dan, models are the design process! Just about everything I do, outside of things like project management, is all about making models. First: modeling the design research in conceptual models and personas. Then modeling user actions in task flows and potential user actions in storyboards and scenarios. Then modeling the design itself in the form of sketches, wireframes, and prototypes. In a sense, to me, all design is about model making.

Part of that is, of course, documenting. It’s in vogue now to shun documentation and go straight to the prototype or even right to building the product. Which is a fine way to work, although it’s not mine. I’m definitely of the “measure twice, cut once” school, because, man, once you get code going or physical models being made, it gets increasingly difficult and expensive to change.

In design school, one of my professors Jodi Forlizzi used to pound into us that the quality of the documentation you make is an indication of your quality as a designer. And although I was annoyed at the time at having to make things like designed CD covers instead of just scrawling a label with a sharpee, I’m come to agree with her. I hate seeing sloppy, ugly deliverables. Whether it’s true or not, it makes me feel that the design itself isn’t very good. I don’t trust the documentation: it doesn’t communicate to me the quality of thinking that went into it. I imagine you talk a lot about this in your book, Dan.

As far as essential tools go, for me the two inescapable tools have been and remain wireframes and prototypes. Wireframes gather up all the thinking–the business rules, the technical constraints, the features and content needed by users, the controls for those features, the states, etc.–that I’ve discovered and brainstormed over how many weeks. They become “the bible” for the product. I’ve found that they get referred to over and over and over again, way more than any other document by far.

Wireframes don’t convey timing, animation, or feeling very well, though. And for those, you need prototypes. Ideas that seem brilliant in wireframes are terrible in practice. And visa versa–stuff I’ve thrown out in the wireframe for seeming too clunky work well in the prototype. Over the last year or so, I’ve been experimenting with low-fi animations made with animated gifs (now that’s old skool!) in order to convey how something should feel and how the timing of, say, a drag-and-drop should be. And some tools you simply can’t experience well until they are working. How can you tell if a drawing tool is going to help you draw until you build it and play with it (and have users test it)?

I’m curious to hear what you have to say about wireframes, Dan. How do you build them using your concept of layered documents?

Dan B: I like your thoughts on modeling because it’s clear that for larger products, it can be difficult to prototype the entire experience all at once. Modeling allows us designers to focus on certain aspects of the product or web site, hashing out obscure business rules or dealing with specific user needs. As you imply, wireframes are a crucial tool for this process.

The chapter in Communicating Design on wireframes is the longest, clocking in at 40 pages. It’s the document that a dozen designers have thirteen different opinions about. In many ways, it’s the ideal layered document because there are so many different kinds of information that you can include in a wireframe.

At its heart a wireframe, as I’ve defined it, displays content and priority–what’s on the screen and its relative importance. These two elements (plus some identifying information) constitute the first layer. That is, the information that makes the document what it is.

Many designers include layout in their wireframes, so the book defines this as a second-layer element. Annotations also appear on the second layer. You can get away doing wireframes without this information, but the wireframes may not be as meaningful for your project team without them. I’ve done some brilliant (if I do say so myself) layout-free wireframes that emphasize priority and functionality, giving the visual designer free-reign over the look of the pages, but the design team needed more direction for layout.

Honestly, I’ve never done wireframes the same way twice. Every project calls for a different focus and emphasis. Some wireframes include detailed documentation of business rules and interactions while others describe the sources of content and production schedules.

A central idea of the book is that designers should not be a slave to our documentation: use it to further the creative process but don’t do it for the sake of itself. If you need to change a documentation standard to accommodate a project’s nuances, so be it.

This is one of the reasons why I wrote the book in the first place. Most design books out there deal with process and methodology, not specifically with documentation. In most of these books, documents are an afterthought and tend to be very prescriptive. These books also neglect how to use the document in the context of a project, so mine also includes a section for each deliverable on presenting the deliverable to colleagues and clients.

Dan S: One quick comment about wireframes before we move on, Dan. It’s interesting that you break up wireframes like that into your layers. I’ve always envisioned wireframes as having three components, which corresponds almost perfectly to your layered approach, although I never thought of it that way. I see wireframes as having three parts: the wireframe itself, the annotations, and the metadata about the wireframe. The metadata (when the wireframe was made, who made it, what changed since last time, issues) would be down on your third layer, I suppose.

Dan B: Perhaps my layers are not what you would expect, Dan. Identifying information is crucial in any document, and should be considered essential–in the parlance of Communicating Design, a first-layer element. Why? If you’ve ever had a stack of wireframes handed to you, you’ll know it’s important to include these bookkeeping elements so you can keep everything straight.

I don’t want to go into great detail here, so I’ll post something on CommunicatingDesign.com that digs into the three layers of wireframes.

Dan S: I totally agree about changing the document to suit the project, Dan. A foolish consistency being the hobgoblin of small minds and all. I’ve thrown all sorts of things into the wireframe: task flows, technical specifications, business requirements, mini-storyboards, screen captures from the existing website, even hand drawings.

But I have to admit, Dan, that I did pretty much what you just said with documentation in my book. “Here’s what this document is for. Here’s what this one is for, etc.” Although I offer up ways to do most of them, I certainly didn’t go into depth on each one or talk about how to present them. But then again, mine wasn’t a book about documentation, more on methods, process, and overviews.

Dan B: A follow-up question to your previous comments, Dan: you indicate that there’s a trend now to shun documentation. I also see that trend, but mostly in the design community itself. Have you had to change how you manage client expectations with respect to documentation?

Dan S: Nope. I have yet to hear a client tell me to provide less documentation. Then again, I try to only give the essentials. At Adaptive Path, we tend to avoid (or at least try to avoid) massive amounts of documentation that no one is ever going to read. If we can get away with a diagram or presentation or set of wireframes, then by god, that’s what we do. We had one strategy engagement in which the deliverable turned out to be a poster. I guarantee that that poster, which reportedly hangs on walls in various client offices, was better understood and used than any standard strategy document would have been.

Dan B: Dan, what inspired you to write your book?

Dan S: It’s pretty simple really, Dan. I taught two semesters of interaction design fundamentals at Carnegie Mellon and never found a book that I felt was appropriate, that approached the topic from in a way that resonated with me and how I worked and was taught. I was putting together chapters from Alan Cooper’s book, and another from Jesse James Garrett’s book, and other articles and blog posts from all around the web: Dan Hill, Don Norman and a host of others. I thought, “This is ridiculous.” So I wrote my own book, and included a lot of those people that I was already drawing on, either simply as inspiration or by including them in interviews.

Dan, I’m assuming you include a bunch of different documentation samples in your book. Are they all yours, or did you gather them from a number of people? If it’s the latter, were there any that really surprised you?

Dan B: Most of the samples I created especially for the book, Dan, though I did solicit some samples from friends and colleagues. The reason you won’t see more samples from other people is purely logistical. I knew it would be difficult for people to secure permission to use their work in a publication, and since I had limited time and resources, I decided to avoid the issue altogether by creating examples from
scratch.

More importantly, as part of the book, I anticipated creating a wiki just for user experience documentation, and I felt this would be a better place for people to share work samples because it’s something that doesn’t have a hard and fast deadline. Additionally, readers should have access to a broad range of examples, and no doubt the web is a better place for that kind of resource.

That said, I did get a few examples, including a site map from James Melzer, a set of wireframes from Stephen Anderson, a content inventory from Sarah Rice, and a workflow from MAYA Design. Todd Warfel sent a photo of personas posted in a meeting room. Jesse James Garrett and the good people at OmniGroup let me use a screenshot of Jesse’s visual vocabulary. Finally, Netflix let me recreate their movie page in a series of wireframes for that chapter. Nothing too surprising: the purpose of the book was to capture the basics of documentation, and it avoided getting into anything too proprietary or specialized.

When I saw your posted interviews, Dan, I had really mixed feelings. On the one hand, I was excited to see such good stuff from some of the industry’s biggest thinkers. On the other hand, I was crushed that I didn’t do anything that cool for my book! Did you find that your interviews corroborated your ideas in the book? Were there any major disagreements between what people said and the design philosophy described in Designing for Interaction? Finally, what surprised you most about the interviews?

Dan S: Dan, I have to thank Peter Merholz for suggesting that I do interviews. I got a lot of great suggestions while writing, but that was probably the best of the lot. There weren’t a lot of disagreements with the philosophy of the book from the interviewees, but then I probably stacked the deck with people I agreed with. Almost all the interviews made me change my mind about something, though. Hugh Dubberly made me realize that systems design isn’t necessarily opposed to user-centered design. Marc Rettig talking about how the seminal moment in interaction design hasn’t happened yet. Larry Tesler on what it means to be an experienced designer. Carl DiSalvo on how robots are both a product and a service. And on and on. I’m honestly flattered these people appeared in my book.

One last question, Dan: When’s the book out?

Dan B: I’m sure the interviews will be a great balance to the concepts you lay out in the book. Another point of jealousy: your supporting website is great! How do you plan, Dan, to extend the experience of the book online? Can we expect ongoing interviews?

To answer your question, Communicating Design should be out any day now. I believe it’s delayed a few days to correct a printing problem found in my advance copy. If you’ve pre-ordered it, it should be arriving in the next week or so. What about you? When can I expect my pre-ordered copy to materialize in my mailbox?

In the meantime, Dan, it’s clear from your personal blog that you need some suggestions for comics. Perhaps when you’re in Washington for UX Week, we can visit my local comic book store. Of course, if you need something to tide you over, I *highly* recommend Warren Ellis’ Nextwave from Marvel. It’s a parody of superhero comics with sharp writing, wicked art, and killer koala bears. What’s not to like?

Dan S: After the interviews came in, I was like, damn, I should do a whole book of interviews! But then I noticed that Bill Moggridge is coming out with a book later this fall that is exactly like that! So oh well.

I haven’t given much thought to how the book will expand online, but I am traveling around with a workshop based on the book. The first locations are in San Francisco and Sydney in September and probably New York in October.

The book itself, like yours, should be out any day now. It’s in warehouses, supposedly.

Great talking to you, Dan, and I look forward to reading your book and seeing you at UX Week! And I’ll have to check out that comic!

This entry was posted on Wednesday, July 19th, 2006 at 4:00 pm and is filed under Conversations, Friends of Adaptive Path, Interaction Design, Plugs. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

This post is licensed under a Attribution-Noncommercial-No Derivative Works 3.0 Unported License.