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.
By 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—jthese 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.
On Authorship:
It is important to know “who did that” – and it’s a much bigger issue than simply “denial of the author’s rights”.
It is extremely important for makers to know about other makers – and for users to know who made the things they use.
Dust or Magic by Bob Hughes
Signing our work creates a connection between the developer and the user.
The user can see who created the software and how to get in touch with that person.
Software Craftmanship by Pete McBreen
On Data:
I have been grappling with data presentation for years, and have definitely found that subtle effects which “encourage the eye” are much better than the bold-mania approach where data is forced on the user like that power tool in driller-killer.
My latest attempts at data presentation can be found at usabilityviews.com (there is a BAA page)