Fractal Documents Tell Infinite Stories: An Interview with Dan Brown
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
With web design still only in its teenage years, Dan Brown thinks it’s a wonderful time to be a designer. He says designers at this time have a chance to experiment with crazy ideas, new methods and techniques. A major area of experimentation is in the documentation designers produce as part of the creative process. Whether making wireframes to communicate the structure of individual pages, flow charts to describe interactions, or personas to summarize user research, each deliverable tells a story all its own.
In his book, Communicating Design: Developing Web Site Documentation for Design and Planning, Dan maps out not only how to create deliverables such as site maps and flowcharts, but also how to use and apply them. He also writes about design briefs, usability plans and reports—what makes them worthwhile and how to put them together.
Miraz Jordan: Dan, you've been working in information architecture and user experience design for more than 15 years now. What drew you to that field? Do you see it as a single field, or are they separate?
Dan Brown: To paint with a broad brush, information architecture belongs to user experience design. It deals with designing structures that work with other aspects of a user’s experience. These structures help people make sense of that experience, but is no more essential than thinking about texture or time or tone.
The industry’s terms for itself are in constant flux: we modify “design” with all kinds of qualifiers, like user experience or interaction or service. I call myself an information architect, however, because I believe my strength is making sense of complicated collections of information and designing structures that will be most meaningful to people who want to use the information.
Miraz: Can you explain in just a sentence or two what user experience is? How would you describe it to people new to making websites or to business people wanting to get a website?
Dan: There are people who think about this far more than I do, and could probably provide a more succinct definition. A story might be a better way of illustrating.
An envelope arrives bearing the return address of your health insurance company. (This is perhaps most meaningful for we Americans who have the distinct honor in the developed world of finding ourselves enmeshed in tragic bureaucracy.) The envelope contains an “explanation of benefits,” a statement describing what the health insurance company paid out for a recent doctor’s visit. This claim, of course, has been rejected.
Emblazoned with a URL, the document implies an opportunity to communicate with the insurance company through the web. Possible uses of the web site run through your head: Maybe I could clear this up online? Could I chat with a service representative? Can I resubmit my claim or get a sense of why it was rejected? Will this be like the last time I went online to deal with insurance? Or like that time with my bank?
As a web designer, my job is to help set and meet those expectations. Web user experience begins when it occurs to someone to go online for some reason or another and ends... well... never.
Web sites leave a lasting impression, and that becomes wrapped into the user’s next session. To the extent that I can have some influence over it, that makes me a designer.
Miraz: Is this what you're talking about when you say that documentation tells a story—what any one designer does both reflects and shapes the ongoing experiences users have with the web?
Dan: In telling you that story, I was trying to describe user experience, but yes, stories are also effective devices for explaining design ideas. What’s even more effective is telling those stories with a combination of words and pictures. Good user experience documentation balances words and pictures to explain how a design works. It puts the design in the context of a story to clarify the design further.
I love stories because the mind craves them. Instructional and abstract prose doesn’t connect with people the way a story does. Designers who convey their concepts through stories will generally get better feedback and discussion on their design.
Miraz: Do you have any favorite 'tricks' for creating design documentation, any handy shortcuts people can use? Or do shortcuts just cut across the principles behind user experience?
Dan: While I’m all in favor of a fast track to great design, shortcuts don’t make for better products. User experience design is a broad set of methods, so there’s no one-size-fits-all set of tricks.
If readers are interested in how they can incorporate user-centered design principles without a major investment, they should look at Undercover User Experience Design, a new book by Cennydd Bowles and James Box, which came out on the same day as my book.
Miraz: How do you think the user experience field has advanced or changed since you started out? What are the current challenges in user experience and how are they different from 15 years ago?
Dan: There are some pretty obvious contextual changes: new devices for accessing the web, expanded capabilities of web browsers, increased demand for well-designed web sites, greater integration of the internet into day-to-day business and personal matters.
These factors keep the pressure on designers to find new ways to solve the same old problems, and use tried-and-true approaches to new challenges.
The web design community is in its teenage years, overflowing with internal conflict and desperate attempts to show maturity.
That sounds harsh, but it’s a wonderful time to be a designer. Imagine being an engineer when cars first became mass produced or when video cassette recorders became mainstream. In those instances, like in web design today, those engineers had an entire industry in front of them, waiting for people to step up and establish a direction.
We’re experimenting with new methods and techniques, we’re seeing lots of crazy ideas (plants that Tweet! social networking around virtual farms!), and we’re seeing culture being shaped by the very things we’re designing.
Miraz: In your book Communicating Design: Developing Web Site Documentation for Design and Planning you write about communication tools such as personas, site maps, and usability reports. What was the original spark for writing this particular book?
Dan: At a conference for information architects in 2002, I presented a poster called “Where the Wireframes Are,” about an alternative approach to documenting the content and structure of web pages. Wireframes—schematics of web pages—were in their infancy back then, and the design community was fraught with controversy about the best way to use them in the design process. The poster was well-received and led to my writing a regular column in the information architecture journal called Boxes and Arrows.
In the dozen or so articles I wrote for the column, I addressed various aspects of preparing documentation.
Even after I stopped writing the column, my interest in documentation persisted. When New Riders approached me about a book, my first instinct was to write about a software application that some web designers use to create wireframes, flows, and other artifacts. Reluctant to do a software book given the relatively short shelf life, New Riders asked me if I had any other ideas and I pitched Communicating Design.
Documentation combines two interests: the structural aspect of designing for the web and communicating complicated ideas through pictures. In my philosophy classes at university, I was the guy always drawing comics about Plato.
Miraz: The first edition was published in 2006, and with the second edition you've added new material. You mention in the preface that your thinking on how to prepare and talk about design documentation has changed in the last five years. Can you elaborate on that?
Dan: Changed? I said that? Really? Changed. Huh... Changed may be too strong a word. Some ideas evolved, becoming, in a sense, more formal: I was able to articulate them because, with more experience and in discussions with my colleagues, they became clearer.
The structure of the second edition reflects part of that thinking.
Distinguishing between the diagrams created by designers and the documents that hold, contextualize, and narrate those diagrams is something I’ve done unconsciously all along. It became formal through my collaboration with Nathan (my partner at EightShapes), who brought this distinction to a practical and technical level.
Nathan separated the artwork (the diagrams) from the document: they exist as separate files. This affords numerous technical and logistical advantages, but it’s interesting on a conceptual level, too, which may be the crux of the book.
Documents are fractal; they contain infinite stories. The building blocks of a document—the diagrams and narrative and structure—represent stories in and of themselves, but also tell one or more bigger stories when united.
That’s for the construction of documentation. Storytelling invades the use of documentation, too.
While the first edition offered some tips on how to present deliverables, the second edition dug deeper, offering a common framework for relating the theme and details to people. It took the notion that documents are conversation pieces and formalized it, showing people how to have a meaningful conversation around an artifact.
Miraz: So, how does something like a site map tell a story?
Dan: Site maps themselves may not tell a story. How much narrative can you really imply in conveying the structure of a web site’s navigation? But as a backdrop, site maps work very well. With a site map you can show how a site’s structure caters to specific user needs or addresses particular situations. You can take a different perspective, showing how the site’s navigation will evolve or change from the current view.
When my son realized that most movies have scary parts, he wanted to know why. Fear is a simple mechanism for building tension, and tension is what drives a story. In web design, the tension is far more straightforward than in a Hollywood production, but it is driven by the same ingredients: change, disagreement, striving for success.
Miraz: I noticed that in your book you remind readers that documentation is only a tool. I gained the impression that sometimes people focus on perfecting their wireframes and site maps rather than getting on with creating the website itself. What's your impression of how people currently use design documentation?
Dan: While it would be hard for me to generalize about how people use design documentation, what I do see is a trend among designers to get closer to the end product.
For a while there was a backlash against formal documentation. Many people interpreted modern software engineering methodology as eschewing documentation altogether. This isn’t right. Effective design means taking steps before writing production code, whether that means prototyping in HTML, creating an elaborate set of annotated wireframes or exchanging a handful of sketches.
Miraz: What do you see as the challenges for user experience over the next decade?
Dan: What we call user experience today faces three kinds of pressure.
User experience may be construed as either too broad or too narrow. In some circles, user experience is synonymous with “everything perceived by the target audience” and in others it is confined to the design of interactive products. Regardless of your view, user experience lacks a simple definition. Designers will forever question where it fits relative to other kinds of design, but such navel-gazing reveals the shifting internal boundaries. What are the components of user experience design? Will distinct fields we take for granted today (information architecture, interaction design, content strategy, interface design, ad nauseam) remain relevant tomorrow? Will we see further fragmentation or an effort to consolidate?
The most recent conception of user experience confines itself to a handful of design techniques, and for the most part follows a user-centered philosophy. This is by no means the only way to design something. New design techniques will emerge and the field will need to reconcile how various methods work together to accomplish objectives. A lack of focus on pragmatic issues will move design out of the hands of people who feel most passionately about it and into the hands of people who can accomplish more, faster.
So, a challenge of definition and a challenge of approach. The third challenge is one of perception.
I see more and more references to “user experience” outside the confines of our little community. The echo chamber perhaps has an opening in one wall and the message is starting to emerge: the design of a product entails more than how it looks. People who hadn’t ever thought about user experience before now understand why it’s important. People who had understood its importance now can discuss methodology and process.
In short, we’re collectively moving along the learning curve. Can designers successfully harness that energy? Can we incorporate more stakeholders into the creative process? Trends show that design will become wider spread, more incorporated into business, and discussed by a broader group of people. (It’s no accident that Harvard Business Review and Business Week have experimented with designers writing for them.)
The challenge facing the design community: determining our role in that growth.
Miraz: That's a very hopeful message to take away. Thanks Dan for sharing your thoughts.
Dan: You are very welcome.
Dan Brown has been designing web sites for 15 years. He speaks and writes about all aspects of user experience, especially information architecture. In 2006, together with Nathan Curtis (Modular Web Design, New Riders, 2009), Dan co-founded EightShapes, a user experience consultancy based in Washington, D.C.