Six Tips for Improving Your Design Documentation

by:   |  Posted on
“Writing effective design documentation (like design itself) is really all about making sure you serve the needs of your audience.”If you are a designer or product planner, you probably create documents of some kind to capture your design decisions and solutions. Documentation is a crucial component of successful product planning and implementation, so it’s important that it communicates as effectively as possible. Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.

(Note: I refer to “the document” throughout this article, which implies a bound stack of paper, but a printed volume is just one—and not always the best—way to present design documentation and specifications, as Brian Krause points out in his article, “Getting Creative With Specs: Usable Software Specifications.” While many of the following tips are described in the context of printed documents, most of them can be applied to design documentation in any format.)

1. Know your audience
Writing effective design documentation (like design itself) is really all about making sure you serve the needs of your audience. So before you begin writing, it’s worth finding out who your audience is and what, exactly, it needs.

Most important is to know who your primary audience is. Is it programmers, project managers, executives, designers, marketing people? It can be difficult to satisfy every reader in a single document, so, if possible, pick just one target group of people and write for them. If you must serve everyone in a single document, organize it so that each audience can read just the section that applies to them, and not be bothered with the other stuff.

Next, ask yourself—or, better yet, ask your readers—what they want to get out of your document. What will satisfy their goals? Do they need something to help them make a decision? Do they want to better understand who the users are? Do they need to know exactly how the interface behaves and looks? The answers to questions like these should inform the structure, tone, and emphasis of your documentation.

Also important is the culture of your audience. You must be aware of the ways in which your audience uses documentation, and when. What language does your audience speak—technical, marketing, design? What other kinds of documents do they use, and how? Does a paper document make sense, or would a presentation be more appropriate? You want your document to integrate into your audience’s culture, not disrupt it (unless, of course, the intent of your document is to shake things up).

Once you know who your audience is and what they need, you’re ready to start writing. As you go, regularly double-check yourself to make sure you are still on track to deliver your audience what they need.

2. Tell a story
A major goal of design documentation, especially in the early stages of a project, is to educate its readers about the value of the design itself (rather than the specifics of it), and convince them that the product is worth building and producing. One effective way to help people learn and understand these concepts is to present them as narratives: Instead of thinking of your document as simply a well-organized collection of specifications, descriptions, illustrations, and diagrams, try telling a story. Your design document doesn’t have to read like a novel, but incorporating some novel-like elements into your work can often be surprisingly valuable.

Using characters
All novels have a main character, and your design document should, too. If you used personas during the design process, you’re set. Since personas represent the goals and needs of the people who use the design, they are a natural choice for the main characters of your documentation. They even have names, backgrounds, preferences, ambitions, and goals, just like people in a book. Throughout your document, refer to your personas by name, and refer to them often. If you are describing how a product might fit into a market, write a story about how Alison benefits from using the product in her life. If you’re explaining a complex behavior of the product interface, cast it in terms of Daniel’s actions and reactions.

Even if you don’t use personas, per se, it’s a good idea to have some representation of the user in your documentation (more than just bland, generic “the user”). Something as simple as a sketchy description or outline of the target user’s characteristics, coupled with a name, can be quite compelling.

Using scenes
Two excellent ways of presenting the narrative of the design are scenarios and walk-throughs.

Scenarios are like short stories: they communicate a persona’s situation, and describe her motivations, expectations, and goals, without getting into the details of the design. Scenarios are especially useful in the early stages of a project, when conveying the value and purpose of the product is key. Here’s an example passage from a scenario:

Jane’s brother’s birthday is coming up soon and, after much consideration, she has decided to buy him the Ansel Adams retrospective book he keeps talking about. It’s not cheap, though, and she’d like to find the best price. She decides to check ShopAround.com because she’s had good luck with the site before, so she opens her browser and types in the URL. When the page loads, she’s pleasantly surprised to find that it remembers who she is and has even stored the items she was thinking about purchasing the last time she visited the site. Jane clicks in the “ShopAround for:” field and types “ansel adams”…

Notice that this scenario doesn’t specify what the ShopAround site looks like, or what content is featured on the home page. Instead, it focuses on what’s important to Jane: that it remembers her and what she was shopping for last time. It also only describes Jane’s interactions with the page that are pertinent to her goals—namely, finding the book she wants to buy.

Walk-throughs, on the other hand, are good lower-level communication tools. They are basically step-by-step procedures that explain how the persona does something with the product, each action she takes, and each response she gets from the system. Walk-throughs are great for explaining interface behaviors. Both scenarios and walk-throughs work best when accompanied by illustrations or screenshots of the design. The text part of a walk-through might look something like this:

   USER INPUT
      1. Jane types URL into browser Address field and presses Enter

   SYSTEM RESPONSE
      2. Display ShopAround homepage
      3. Display user name in the Sign In module
      4. Display user’s most recent items in Shopping Cart module

   USER INPUT
      5. Jane types “ansel adams” in ShopAround field

   SYSTEM RESPONSE
      6. Query for search string
      7. Load page with search results

Be careful when using a narrative-based document structure, though. It’s not appropriate in all situations. For example, some design documents are used as reference guides for developers; those documents must present information clearly and concisely, and in a way that makes it easy for programmers to find what they need. Here, story-telling might get in the way. One approach is to use narrative to provide an overview of each element of the design, then use a more straight-forward format, like bullets or numbered lists, to convey the nitty-gritty details of each element. Again, always be aware of the needs of your audience, and structure your document so it best meets those needs.

3. Describe the rationale and implications of the design
When you’re documenting a design, it can be tempting to just explain how the product works and show what it looks like. But for many in your audience, that’s not enough. They also want to know the “why?” behind the design. They may wonder why a particular feature was (or was not) included, or why a certain interface element looks or behaves the way it does. While you don’t want to overload your document with too much exposition, providing a bit of rationale where appropriate is another way to get your audience to embrace the design.

The best way to support a design decision or solution is to frame it in terms of how it serves the needs of your users (here again, personas are useful if you have them). Explain how each decision will help your users satisfy their goals and how it will make their experience more powerful or pleasant. Most of the time, using this approach will answer your audience’s “why?” questions even before they ask them.

While providing rationale for your decisions answers your audience’s questions, it can also be a great way of showing that you’ve considered the needs of your development organization. Describing the design in terms of the business requirements it satisfies can help put the minds of product managers and executives at ease. Similarly, using design principles to back up unusual or unique interface behaviors can reassure programmers that what they code is sensible. There’s a benefit for you, too: providing reasonable arguments for design decisions gives you authority. It demonstrates that you know what you’re talking about, which means fewer “well, I think it should be this way” discussions with developers.

Additionally, it can often be valuable to include discussions of the implications of the design. If the design requires certain changes or additions to the technical architecture of the product—such as the need for additional server-side functionality or streaming Internet connectivity—address them up front, so engineers can make fully-informed decisions about how to implement the design.

4. Stick to a grid
Something that is often overlooked is the design of the document itself. Chances are, you’ve come across few examples of development documents that, while full of excellent content, are almost impossible to read because of their haphazard layout. Making the format of your document visually clear and consistent from page to page is just as important as getting the content right.

Effective documents rely on a fixed grid of page elements. Flip through the pages of any book on your bookshelf, or any above-average news website—notice how the bodies of text all line up, and that the header, footer, and margins are the same on each page. That’s the grid. It’s not there only for aesthetic reasons. Having a clean, organized layout means your readers don’t need to do as much work to find things on the page or to make sense of the content they see. A grid also lets you focus on what you’re writing, instead of trying to figure out where to put things on the page.

Applications like Adobe FrameMaker, InDesign, or QuarkXPress make it fairly easy to establish a consistent page layout grid, and many of them offer sample templates to get you started.

Document Grid
Well-planned page layout grids maintain “white space” in the margins and between page elements. This lets your pages “breathe.” Don’t cram things together just for the sake of getting them all on one page.

5. Use the present tense, active voice
If you are producing design documentation, the product is what you write, and the tone of your writing should reflect that. Compare these two sentences:

   The user is provided with a screen for entering data.

Versus:

   The user enters data in a screen.

The first sentence is written in passive voice. It’s wordy, and somewhat awkward. The second sentence is in active voice. It is strong, definite, and clear. Using active voice makes your writing bolder, more direct, and more concise. In your documentation, write as though the product already exists, and you are simply explaining it to a colleague (“the product does this…,” as opposed to “the product would do this…”). When you write with conviction, your confidence and belief in the design is carried through to the reader, and helps make the design more persuasive to your audience.

6. Get a partner
No major book or article is published without an editor. Your design documentation should be no different. Find somebody who can review drafts of your document periodically, before you hand it off to the developers. Ideally, your editor should be a teammate—someone who is already familiar with the design and the project—but a colleague or a trusted member of the development team will work, too.

You and your editor should ask: Is the design described correctly? Will the developers “get” it? Is the organization clear? Are all the key points covered? Have the important technical and development implications been addressed? And so on. Check in with your editor regularly, not just at the end before your document goes to the printer or the web. It’s much easier to deal with holes in your content or problems with your organization scheme if you catch them in early drafts.

As you go through the editing process, keep in mind your ultimate goal: to get the best design produced and out the door. Don’t get too attached to your prose—no word, sentence, or paragraph is precious, and if reworking what you’ve written serves the greater good, do it.

These tips are just a few of the things that go into crafting a great design document (there are many more), but following any one or all of them will help you better serve the needs of your audience. And if your audience of developers and business people is happy, it’s a good bet the users of your product will be happy too. Write on!

Ryan Olshavsky has over five years of experience in interaction design and design documentation. He is currently an Interaction Designer at Yahoo! Inc., a small Internet company. Previously, he worked as a design consultant at Cooper.

Visible Narratives: Understanding Visual Organization

by:   |  Posted on
“Visual designers working on the web need an understanding of the medium in which they work, so many have taken to code. Many have entered the usability lab. ”Art vs. engineering. Aesthetics vs. usability. Usability experts are from Mars, graphic designers are from Venus . The debate between design (of the visual sort) and design (of the technical sort) remains ongoing. A website, however, can’t take sides: it needs both to be successful.

“Interactive design [is] a seamless blend of graphic arts, technology, and psychology.”—Brad Wieners Wired, 2002

So, why the debate? Perhaps the dividing line sits in our minds: left brain (logical) vs. right brain (intuitive). Or, if we take a less deterministic view: few engineers have taken the time to study art and few artists have spent time programming or conducting usability tests. But times are changing. Visual designers working on the web need an understanding of the medium in which they work, so many have taken to code. Many have entered the usability lab.

But what about the other side? Are developers and human factors professionals immersed in literature on gestalt and color theory? They certainly have the tools for it—programming environments make it very easy to throw around images, colors, and fonts (of all shapes and sizes). But with power comes responsibility. And in this case, the need to understand how visual information communicates with your audience.

“We find that people quickly evaluate a site by visual design alone.” —Stanford Guidelines for Web Credibility, 2002

Visual communication can be thought of as two intertwined parts: personality, or look and feel, and visual organization. The personality of a presentation is what provides the emotional impact —your instinctual response to what you see. Creating an appropriate personality requires the use of colors, type treatments, images, shapes, patterns, and more, to “say” the right thing to your audience. This article, however, focuses on the other side of the visual communication coin: visual organization.

How we see: visual relationships
Whenever we attempt to make sense of information visually, we first observe similarities and differences in what we are seeing. These relationships allow us to not only distinguish objects but to give them meaning. For example, a difference in color implies two distinct objects (or different parts of the same object), a difference in scale suggests one object is further from us than the other, a difference in texture (one is more blurry) enforces this idea, and so on. Once we have an understanding of the relationships between elements, we can piece together the whole story and understand what we are seeing.

This process is accelerated by our ability to group information visually. When we observe one blade of grass, nearby objects that share a similar color, shape, size, and position are grouped together and given meaning: a lawn. We don’t have to compare each blade to the others.

The principles of perception give us valuable insight into how we visually group information. For example, objects near each other are grouped (proximity), as are objects that share many visual characteristics (similarity).


Fig 1: Principles of perception: proximity, similarity, continuance, and closure.

But understanding the psychological manner in which we group visual information is not enough if we want to be able to communicate a specific message. In order to do that, we need to know how to use visual relationships to our advantage—we need to know what makes things different.

Though lots of variations are possible, we can group distinct visual characteristics into five general categories: color, texture, shape, direction, and size. Introducing variations in one or all of these categories creates visual contrast. The more contrast between two objects, the more likely they will be perceived as distinct and unrelated.


Fig 2: Visual differences between objects.

Telling a story: visual hierarchy
“Designers can create normalcy out of chaos; they can clearly communicate ideas through the organizing and manipulating of words and pictures.”—Jeffery Veen, The Art and Science of Web Design

Now that we understand the basic ways to visually distinguish objects, we can look at the big picture: using visual relationships to tell a coherent story. Elements within a “visual narrative” are arranged in an easily understood order of importance. A center of attention attracts the viewer’s attention, and each subsequent focal point adds to the story. This logical ordering is known as a visual hierarchy.

To build effective visual hierarchies, we use visual relationships to add more or less visual weight to page elements and thereby establish a pattern of movement through the layout. Visual weight can be measured by the degree to which a page element demands our attention or keeps our interest. Large red type, for example, contrasts with a white background much more than a light gray dot. As a result, the visual weight of the red type grabs our attention first, though it might not keep our attention as long as a detailed image.


Fig 3: Three objects with differing visual weights created by variations in color, shape, and texture.

Visually dominant elements (those with the heaviest visual weight) get noticed the most. They are the center of interest in a layout and they determine where the story begins. The hierarchy of subsequent elements guides our eyes through the rest of the composition, giving us pieces of the story as we go. The relative position of each element in the hierarchy provides valuable information about its importance to the big picture.

Fig 4: The heaviest (most visually dominant) elements in this circus poster are the images of the performers and the title. They communicate the big picture: the circus is in town. The lightest (least visually dominant) elements in the hierarchy are the ticket prices and features. If the hierarchy were reversed, few people would know the circus was in town. Instead they would be confused as they passed posters seemingly promoting “$5.50.”

A balanced hierarchy provides not only a clear path for recognizing and understanding information, it also helps unify the disparate elements within a page layout into a cohesive whole. This creates a sense of order and balance. Without visual hierarchy, page elements compete for attention, and as a result, none of them win. In all hierarchies, only certain elements should be on top; the rest need to follow suit. The appropriate position of each element in the hierarchy depends on the message you are trying to communicate.


Fig 5: In a layout with an effective visual hierarchy, the distinct visual weight of each element guides viewers through the page in an informative and appropriate manner.

Putting it to use
Any given web page is composed of many distinct elements. Navigation menus (possibly several layers deep), contact information, search boxes, site identifiers, and shopping carts are just a few. The visual organization of a web page can communicate valuable information about the similarities and differences between elements and their relative importance. Once your audience understands the significance of your page elements, they can apply that knowledge to the rest of the site.


Fig 6: If all the elements in a page layout are given equal visual weight, making sense of the page is difficult. Meaning is created through the differences and similarities among elements and their place in the page’s visual hierarchy.

Generally, the hierarchy of a web page is based on distinctions between the content, navigation, and supporting information on a page. Within each of these sections further distinctions can also be made. A general web page hierarchy (from highest to lowest importance) may look like the following:

Content

  • Page title
  • Subsection title
  • Embedded links
  • Supplementary information (captions, etc.)

Navigation

  • Location indicator
  • Top-level navigation options
  • Sub-navigation options
  • Trace route (breadcrumbs)

Supporting elements

  • Site identifier
  • Site-wide utilities (shopping cart, site map, etc.)
  • Footer information (privacy policy, contact info, etc.)


Fig 7: The visual hierarchy of a generic web page.

Of course, there are many situations where deviating from this formula is advised (on navigation pages, home pages, etc.). The content, audience, and goals of each page should determine its exact hierarchy. Nonetheless, the visual representation of each element on a web page should always be:

  • Appropriate for and indicative of the element’s function
  • Applied consistently throughout the site
  • Positioned properly in the page’s visual hierarchy (in a manner reflective of its relative importance)

Visual hierarchy, however, does more than simply explain page elements. It guides users through the site’s content and interactions. Armed with an understanding of each element’s place in a hierarchy, we can emphasize important elements (such as content or interaction points), and subdue other elements (supporting information).


Fig 8: In this online form, visual hierarchy guides the user through the necessary steps to place an order. It also emphasizes (with color, positioning, and scale) the first step (“Ordering from…”) and the last step (the “Sign-In” button). Simultaneously, the supporting information is subdued (it has little visual weight) and does not interfere with the main interaction sequence.

Similarly, visual hierarchy can provide users with a sense of where they are within a website, to direct their attention (to special offers, for example), to suggest distinct choices, to explain new elements, and more. However, effective visual communication does not “speak” loudly. It quietly educates and guides the audience through the interface.

Given the massive number of web pages and applications, users often rely on visual cues (especially initially) to assess web interfaces. Therefore, a well thought-out visual organization can greatly enhance usability by grouping information into meaningful page elements and sequences. Such a system relies on an understanding of how people use visual relationships to distinguish objects and what those relationships reveal to viewers (through visual weight and hierarchy). But visual organization is only half of visual communication. The rest, personality (or look and feel), is another story…

Luke Wroblewski is a Senior Interface Designer at the National Center for Supercomputing Applications (NCSA), birthplace of the first widely distributed graphical Web browser, NCSA Mosaic. At NCSA, he has designed interface solutions for Hewlett-Packard, IBM, and Kellogg’s, and co-developed the Open Portal Interface Environment (OPIE).

Three Lessons From Tufte: Special Deliverable #6

by:   |  Posted on
“Information itself cannot inherently be misleading or difficult to understand, but its visual representation or interpretation can be.”Spend any time as an information architect and you’re bound to run into the name Edward Tufte (that’s TUF—tee). Tufte taught information visualization and statistical analysis at Yale University, but he is perhaps best known for authoring and publishing a triumvirate of books: “The Visual Display of Quantitative Information”, “Envisioning Information”, and “Visual Explanations”.

Because his books focus primarily on producing graphics for paper and on the representation of information, not the structuring of information, many information architects wonder about the value of Tufte’s writing for their work. One of Tufte’s principles, for example, is the data-ink ratio, a means for measuring the value of a graphic by comparing the ink used to the data represented.

Tufte measures the amount of ink used to represent data against the total amount of ink used in the drawing. If data-ink is high, the author has done a good job using “their ink to convey measured quantities” (Display 93). With a low ratio, the graphic has less of what Tufte calls “non-erasable” ink.

Information architects who focus on classification and structuring information might have no use for this principle. Those who stray into the realms of interface design might consider a digital equivalent: the data-pixel ratio, comparing the pixels used for representing the interactive parts of the interface with the total number of pixels used. While perhaps easier to count pixels than ink, such an approach does not take into account the subtleties of interaction, usability, and the need for branded interface elements.

Tufte’s work, however, can be applied to documentation successfully. This article considers three of his principles as they relate to information architecture documentation.

Principle 1: Authorship
Tufte spends fifteen pages in “Visual Explanations” talking about the Challenger disaster in the mid-1980s. In short, the scientists at NASA had an opportunity to stop the launch of the ill-fated space shuttle. Tufte surmises that if they had presented the data better, the scientists might have been able to convince the decision makers not to push the button. Although he spends considerable time in the details of the presentation, Tufte first notes that the title slide did not include the names of the authors.

In my work as a consultant, I noticed that “consulting culture” discouraged individual ownership. Perhaps consulting culture prefers to emphasize the team-oriented nature of its work. Perhaps it comes from the explicit clauses in the employment agreements assigning ownership of intellectual property to the consulting firm.

Regardless of the reason, it’s a habit that must change because, as Tufte says about the slides in the Challenger presentation, “authorship indicates responsibility, both to the immediate audience and for the long-term record.” Without any indication of accountability, a document “might well provoke some doubts about the evidence to come” (Explanations 40).

Examples of including author names on documentation:

  • Sean Patrick Coon’s documentation for the EyeWeb system (http://www.apperceptive.com/portfolio/eyeweb.html) includes his name on the flow for the kiosk, but not the site flow or the search schematic.
  • Jesse James Garrett puts his name on the Yahoo! Mail diagram (PDF) he did for Boxes and Arrows (http://www.boxesandarrows.com/archives/images/031102_YahooMail/jjg_ymail_poster.pdf).
  • Erin Malone uses a stylized title bar for her design process timeline for AltaVista (PDF) (http://www.emdezine.com/designwritings/files/AV_ExperienceDesignFlow.PDF)

Principle 2: Smallest effective difference
One of my favorite Tufte principles is the smallest effective difference, which says, “Make all visual distinctions as subtle as possible, but still clear and effective” (Explanations 73). The intent of this strategy is to discourage authors from creating a greater visual distinction than the data implies.

There are many different ways to apply the smallest effective difference, and the approach you select depends on the distinction you’re trying to make. In our documentation, we deal with different kinds of relationships. Here are some ideas for the information architect’s standard deliverables.

The flow chart: My now infamous approach to creating site maps, the “bubble” (PDF) diagram, relies on the smallest effective difference for the connections between nodes. The beauty of avoiding the standard org chart approach to site mapping is that it frees the information architect from the boundaries of the rectangle. By using circles, the relationships can illustrate themselves by taking advantage of the distances between them.

In creating the connectors between the nodes, in showing the relationships, I often want to show directionality or hierarchy. Because of the “non-traditional” layout, however, the diagram needed to allow users to follow the relationships whether they started at a node or not. In other words, if her gaze started at the middle of a connector, the user should not have to trace the line to either end to understand the nature of the relationship. Arrowheads would force users to do just this. Taking Tufte’s principle to an extreme, the arrowhead is not the smallest effective difference between the beginning of the line and the end of the line.

Flowchart showing tapered lines to imply directionalityBy tapering the line, starting thicker and ending thinner, every point on the line could imply directionality. Overall the diagram becomes more subtle, without arrowheads cluttering the drawing.

Because the flow chart or site map is all about showing relationships, there are many ways to apply the principle of the smallest effective difference: the different kinds of nodes, the different kinds of relationships between nodes. Other information architecture deliverables are not so fortunate.

The user profile: The principle of the smallest effective difference can apply to writing as well. In the case of the user profile, authors should focus on what makes each type of user different. In explaining smallest effective difference, Tufte says, “Muting … secondary elements will often reduce visual clutter – and thus help to clarify the primary information” (Explanations 74). With a user profile the “secondary elements” are those that do not contribute to the information architect’s understanding of the user’s information needs.

If an aspect of the user type neither contributes to the information architect’s understanding of that type’s needs nor distinguishes its needs from any other group, perhaps it should be “muted.” While eliminating this kind of information from the profile entirely could lead to flat, inhuman depictions of the audience, finding a way to de-emphasize it could make the document more effective.

The wireframe: In a representation of a web page, the relationships are necessarily implied by the layout. The author need not distinguish between two pieces of information because the position on the page implies that relationship. Perhaps where smallest effective difference comes into play for the wireframe is to suggest that information architects do not “over design” the screens.

With smallest effective difference, however, it is possible to go too far. When a diagram does not have a lot of data, creating subtleties where none necessarily exist could make your diagram hard on the eyes.

Principle 3: Layering
“Confusion and clutter are failures of design, not attributes of information” (Envisioning 53). In a way, this sentence—which begins the chapter in Envisioning Information on Layering and Separation—captures the essence of Tufte’s work (and reminds me of the statement made by my dog’s trainer, “There are no bad dogs, only bad owners.”). Information itself cannot inherently be misleading or difficult to understand, but its visual representation or interpretation can be.

By layering information, authors have an enormous opportunity to eliminate confusion. Misapplication of information layers, however, runs the risk of causing further confusion. Says Tufte, “For every excellent performance, a hundred clunky spectacles arise” (Envisioning 53). What makes layering so challenging is that through layers, authors often create “non-information patterns and texture.” If authors do not effectively separate the layers, they can combine to create nonsense or chartjunk [see note below], further obscuring the message.

Layering is important to information architects because information architecture does not live in a vacuum.

To help information architects apply layering, let’s first explore two reasons why people get confused with our documentation.

Context: Information architecture, while a craft in and of itself, belongs as part of a greater process. By taking a project’s information architecture out of context, clients might experience a variety of misunderstandings that really center on a misunderstanding of how the decisions were made. There are a handful of ways to set the context of an information architecture:

  • Business strategy
  • User needs
  • Functional requirements

Implications: Perhaps this is less about confusion and more about misinformation. How many information architects have experienced the dreaded meeting months after the IA documentation was approved where clients explode because the visual designs are not what was expected? No doubt the good consultant sets expectations, but good documentation can help in this matter by showing the visual design, maintenance, or operational implications of key IA decisions.

Through layers, then, information architects have the opportunity to build a more complex story—to include other elements to the data set. With additional plots, however, comes the potential for added confusion. Although there are several techniques for creating a layered diagram—color, value, contrast&#151jthese will only contribute to misunderstanding if not applied consistently. Each layer must include only one kind of data; and conversely, every data of a particular kind must appear on the same layer.

What happens if the author removes a layer from his or her diagram? Visually, if the author has done her job well, the diagram itself will look like it isn’t missing anything. On the other hand, the person looking at the diagram will get an incomplete story.

Conclusion
Ultimately, the presentation of an information architecture depends on the people using it. Tufte’s principles must be applied in ways that are appropriate and relevant. Layering business strategy context within a diagram for the visual design team, for example, may not be useful. Illustrating the various relationships inherent in the content types of a content management system through the use of Tufte’s smallest effective difference may be more relevant to the engineering team than the client.

Tufte begins his first book with a treatise on “graphical excellence,” which lists nine basic principles from “show the data” to “encourage the eye to compare different pieces of data.” Perhaps this is where information architects find themselves furthest from Tufte’s teachings: his principles do not take the motivation of the user into account. What drives Tufte’s drawings is the data alone. Indeed, for information architects, the deliverable’s audience must guide its design as much as the data does.

*Note:* Tufte’s term for visual elements that obscure data under the pretense of contributing to it. A heavy grid on a line graph is perhaps the best example.
Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank.