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 ( 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 (
  • Erin Malone uses a stylized title bar for her design process timeline for AltaVista (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.

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.

Defining Feature Sets Through Prototyping

by:   |  Posted on
The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members.Over the last couple of years, a standard method for user-centered interaction design has begun to emerge. First, you gather background from the clients and stakeholders, conduct user research, and look at competitive sites. Then you build personas and scenarios, do workshops, and conduct brainstorming sessions. All of that is analyzed down into a grand vision of what should be built.

But what happens after that? Most of the literature in this area assumes that once the designer has a vision in mind, it’s time to move straight into sitemaps and wireframes and the rest of the business of functional design. But I’ve never seen it actually work that way. In my experience, there are always clients who need to approve the vision, scope that needs to be defined, and project managers who want detailed and concrete functional requirements from which to manage. If I’m not involved, they’ll do it without me, often leaving me with a scope and a set of requirements that doesn’t have much to do with the vision with which I started.

To address this issue, over the years I’ve put together a method to translate a conceptual vision into a set of concrete functional requirements, by way of what I call a Vision Prototype. The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members. Because the prototype serves as an explicit visual representation of the project’s needs, it can be easily translated into a set of functional requirements.

What is a vision?
This method assumes that a vision has already been defined in someone’s mind, using one of several user-centered interaction design techniques (see “For More Information” below). The vision doesn’t need to be extremely detailed, but it should answer these basic questions:

  • What’s the purpose of the site?
  • What are the main things the users will do with the site?
  • What’s the general conceptual structure?

Let’s look at an example of a high-level vision. Let’s say I’m building a website that allows Quinn Exhibition, an imaginary trade show company, to sell booth space online. In my—fictitious—user research, I observed that the floor plan for the exhibition was critical in everyone’s thought process in determining everything from number of booths to the position of a competitor’s booth. Typically, sales reps fax annotated floor plans to potential purchasers and buyers show them to their bosses.

Based on this data (and backed up by my fictitious competitor research, personas, scenarios, and workshops), my vision for the website is to use a visual floor plan as a key interface metaphor. Potential clients can see what booths are available and where booths are located by perusing a familiar floor plan format. They should be able to buy straight from the floor plan.

Documenting the vision
It’s not easy to jump from a vision in your head to a list of concrete functional requirements, and it’s not desirable, for a number of reasons. At the most basic level, creating formal documentation of a vision ensures that a vision does in fact exist. While this sounds obvious, it’s a problem that I’ve seen frequently, especially in more traditional software development processes. It’s easy to build a requirements document by piecing together what everyone says they want without any overarching idea of where the system as a whole is going. Needless to say, this often results in sites that are less than cohesive.

A visual representation also makes the vision tangible and understandable to clients, users, and the rest of the project team. This makes it possible to get feedback in this early phase and serves as a touch-point for the rest of the project. When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.

This is where the prototype comes in. I’ve had great success in documenting an ideal vision with a conceptual prototype which, in anywhere from four to ten linked pages, shows the high-level functionality and conceptual structure of the site. I’ve found that this type of Vision Prototype is both easy to create and easy to understand.

The prototype is built not to show the interface, the page flow, or the fields, but to represent an ideal feature set that makes the vision happen. For instance, I’ll often represent site functionality with a number of significantly labeled buttons (i.e., “Add New Location” or “Advanced Search”). These buttons serve as functionality shorthand—there’s no need to show an Advanced Search page in the prototype if the team will understand what a button labeled “Advanced Search” implies.

Because the prototype is primarily documenting an intended (or ideal) feature set, I carefully determine the right level of detail and functional feasibility. I try to represent the site functionality to just the necessary level of detail to allow an engineer to estimate the approximate time and money needed to create each feature. This means representing some specifics (especially for a more unusual feature), but certainly not every field on every page. I also go to some effort to ensure that the prototype feature set is ”blue sky” enough to be inspiring without being completely infeasible for the time and money. I generally think of the prototype as representing the feature set of the site two or three phases down the road.

The illustration shows two pages—a Floor Plan and a Booth Detail page—out of a Vision Prototype for the example website. The pages use both an interface-like structure and suggestive buttons (“Search All Available Booths,” “Split this Booth into Two”) to show the feature set. The prototype would include a few pages in addition to this: an overview or homepage, a static content template (to show that the content links are just pages of text), and perhaps the Buy Booth page itself.

When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.A prototype this early? Are you nuts?
It’s worth pausing here to acknowledge that the idea of building a prototype before even defining scope alarms many reasonable and experienced interaction designers. I’ve heard two different but related arguments as to why it’s a bad idea:

  • Argument 1: Functional requirements by definition should talk about needs and specifically avoid any consideration of design like conceptual structure or specific features. Something as tangible as a prototype should come after the definition of requirements, to ensure that all the issues and parameters are considered before jumping to a design solution.
  • Argument 2: Clients aren’t able to separate a conceptual prototype from an interface design or a live website. They’ll focus on the wrong details (like the page flow or graphic design), fixate on a particular detail that will turn out to be infeasible, or just generally misunderstand the intent of the prototype.

Both of these arguments are rooted in the same premise that it’s preferable to first work at a fairly abstract level to define the scope and needs of the project before looking at a visual representation that might start to limit the field of design possibilities or encourage people to determine how things should be implemented as opposed to solely what the system should do.

While this premise makes sense in an ideal world, I believe that it simply doesn’t work in the vast majority of project situations. Information architects are comfortable working in the realm of abstract functionality (that’s one reason why we’re hired), but clients generally are not. In the same way that we wouldn’t show a user a text list of features and expect to get good data about the usefulness of the system, we can’t expect a client to be able to adequately give feedback on a high-level description of functionality.

By creating a visual representation of the project vision early, we give up a little to get a lot. We give up tight control of precisely what the client will be thinking about at each phase of the project. This can sometimes result in early discussions about things, such as page flow or graphic design, that are unrelated to the decisions at hand (by the way, I’ve seen this type of thing get somewhat irritating on a project, but I’ve never seen it cause any lasting harm). But by giving this up we gain a huge advantage: we gain the active understanding, participation and buy-in of our clients. Ultimately, ensuring our clients can effectively understand, review, and discuss important project concepts will result in better products and fewer problematic misunderstandings down the road.

Does it have to be a prototype?
That being said, a Vision Prototype may not be appropriate for every project. I’ve found that a prototype is particularly good at representing highly complex functional sites. For this type of site, it can represent a lot of complexity in a format that makes it easy to review and understand. In addition, prototypes are familiar to the many companies who already use them as a standard to get buy-in on a project.

For smaller projects, however, I’ve found that it’s difficult to build a conceptual prototype without detailing every field, simply because there’s not that much to say about the site vision. A prototype also may not effectively handle the structural issues of a content intensive site. For this type of site, the prototype can be replaced by anything that’s tangible, non-technical, and fairly comprehensive—perhaps a content map, a comprehensive set of scenarios, or a page flow (when there’s not a lot of complexity in the page flow itself).

Verifying and getting buy-in on the vision
One of the main reasons to create a Vision Prototype is to allow the rest of the project team and the client to understand, review, and provide feedback on the vision. Because the prototype makes the ideas under discussion visible and concrete, it’s common for new needs or concerns to come up at this point—even in areas that might have been completely covered in previous conversations. It’s simply hard for many people to think abstractly about the same things that are made obvious by the prototype.

User focus groups can also be useful at this point. A successful vision will generally get a “Of course, how else would you do it?” response, with some suggestions for minor additional features. Confusion, lots of questions, or lots of suggestions for major new features are all signs that the vision does not correspond with the users’ expectations and model of the system, and needs to be reconsidered.

At this point we resolve any issues, and ensure that the whole team is happy with the prototype before moving forward. In this way, the prototype becomes the documentation of the entire team’s vision.

Creating a functional requirements document
Because the Vision Prototype contains a comprehensive look at ideal functionality, iterated and approved, it is itself a representation of the functional requirements. In order to translate these ideas into a more traditional document, one can simply systematically write down the functionality shown on each page. It’s also important to think through any administrative or tangential features (user administration, for instance).

For instance, looking at the Quinn Exhibition prototype, I can pull the following functional requirements (among others) from the Floor Plan page:

  • The position of each booth is displayed on a visual floor plan.
  • All hall infrastructure is displayed on the floor plan.
  • The status of a booth (occupied or available) is displayed on the floor plan.
  • Booth details, such as the size and the occupant, can be easily seen on or linked to the floor plan.
  • The user can search for a booth based on key booth criteria.
  • An administrator can define the hall infrastructure and initial booth layout for an exhibition.

Note that there’s a great deal of work left to do to completely define the functionality. What criteria can be used to perform a booth search? How does the administrator define the original floor plan? The point of this functional requirements document is not to completely design the site or define all business rules, but to establish the functionality to the point that the site can be estimated.

I put each requirement on a separate line in an Excel spreadsheet, and prioritize each based on my user research findings and client priorities. I generally use Core, High, Medium, and Low. Core requirements are ones that the site wouldn’t make any sense without—in the example site, for instance, “The position of each booth is displayed on a visual floor plan” is a core requirement. The technical team also assigns a complexity (High, Medium, and Low) to each requirement.

The actual writing of requirements takes a little practice to ensure they’re at a useful level of detail and are relatively unambiguous.

Defining scope
The last step in defining a feature set is determining what set of the functional requirements can be implemented in the next phase. I start by working with the development team to determine approximately how much time and money will be left over after achieving just the “Core” priority features. If the time and money can’t accommodate even the “Core” requirements then there’s a problem, and we need to revisit the vision. This is why it’s important not to make the original vision too ”blue sky.”

We then spend several hours as a team going through the rest of the requirements and creating a draft scope. Features are quickly reviewed and separated in to those that should obviously be included (such as High Priority/Low Complexity requirements) and those that obviously shouldn’t (Low Priority/High Complexity). Most of the discussion is around the High Priority/High Complexity and Medium Priority/Medium Complexity features and determining what can be included to create the best mix of basic functionality and strategic features. Determining a scope is more of an art than a science, as the features tend to be dependent on each other in complicated ways. Once there is a draft scope, a more detailed estimate can be made. Often there is too much for our schedule and budget and we have to go back to determine what else can be removed.

Unless the client is very detail-oriented and very close to the team, I’ve found it nearly impossible to involve them directly in the creation of the draft scope. There’s simply too much detail and too many time and money sensitivities. Once we’re internally comfortable with the scope, we can summarize it and present it. While the client almost always has changes, it’s fairly straightforward to iterate the scope because the team internally understands the trade-offs and complexities.

All the previous steps set up a framework in which to consider the issues, generally making the actual definition of scope fairly straightforward. The development and iteration of the Vision Prototype allows the whole team—both the internal team and the client—to solidify a team vision and working relationship. Scope definition, which can often be a painful process of wrangling over favorite features, is made much more straightforward by the imposition of a common vision.

Laura S. Quinn is a technology strategy and information architecture consultant for both corporate and nonprofit clients. Her company, Alder Consulting, specializes in helping nonprofits build powerful internet and database systems with the resources they have (learn more about Alder Consulting at In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.

Understanding PowerPoint: Special Deliverable #5

by:   |  Posted on
“Friends don’t let friends use PowerPoint.”
—Thomas A Stewart, Fortune Magazine, February 2001
PowerPoint: the software we love to hate. Has there been any other software since the dawn of the personal computer that has earned so much criticism? What is it about PowerPoint that has

(Yikes! Bullets! PowerPoint has me in its clutches!)

Sure, we’ve all experienced frustrations with Microsoft Word. (Case in point: When I cut-and-pasted the above quote from into my document, Word insisted on preserving its web formatting. Why?) As irritating as Word and other applications can be, only PowerPoint has a bona fide counterculture.

As part of this counterculture, people have written articles and books on the art of the presentation, the history of PowerPoint, and how the application will be the undoing of the business community (Greed, shmeed!). Of course, these are topics of interest relevant to all.

The purpose of this column is to explore the art of deliverables for information architects. (Keep this in mind as you post your comments.) The question at hand is not, “Does PowerPoint suck?” The answer to that, as we all know, is yes. The question is, in fact, “For information architects, does PowerPoint suck?” Or, more to the point, “Even though PowerPoint sucks, should I use it for my deliverables?”

To be fair, much of the criticism of PowerPoint is directed at the features that allow authors to create complete presentations with almost no effort. Ignoring the design templates and the AutoContent wizard, however, PowerPoint still has some obvious shortcomings. These limitations do not make PowerPoint useless. Instead, by recognizing PowerPoint’s boundaries, we can use it more appropriately.

For information architects, there are at least two ways to apply PowerPoint in your day-to-day activities. For each application, I’ll describe the reasons for using PowerPoint in lieu of some other program, and its potential shortcomings.

PowerPoint for short reports
I’ve recently made the switch from consultant to client, and the consultants I have been working with love PowerPoint. I think Microsoft must sponsor new employee orientation at major consulting firms because since starting my new job in June, I have seen more decks than on a good night in Atlantic City.

Even when I was a consultant, I noticed a proliferation of the use of PowerPoint among people with advanced business degrees. When I was thinking about doing graduate work, I was told that in pursuing an M.B.A. I would get two things: a network of business contacts and a crash course in PowerPoint.

Most of these PowerPoint presentations contain many, many words. The slides are dense with text. Seeing fifty slides with the copy all crammed in like that is just disturbing. When I see those presentations, I wonder why the author did not just make a document in Word.

PowerPoint is a fine tool for preparing reports if you never intend to project or present them, but there should be a reason for using slides instead of pages.

A couple years ago, I wrote a usability evaluation for a Spanish telecom’s website. After some deliberation, I decided to use PowerPoint instead of Word to prepare the report. I had two primary reasons.

First, knowing that the report would have to be translated for a Spanish-speaking audience in a relatively short period of time, I used PowerPoint to help me keep my ideas concise. As I was writing the report, I selected words very carefully to ensure that the translation would be easy. (I knew enough Spanish to evaluate the site and to know whether the report’s translation would be straightforward, but not enough to do it myself.) In doing so, I had to express my ideas succinctly and efficiently.

Ultimately, PowerPoint forces you to be a better writer. People who prepare decks with lots and lots of text do not see the opportunity to find fewer words to say the same thing. Only by selecting your words carefully and eliminating redundant thoughts can you create effective reports in PowerPoint.

(Ironically, the report was never translated. The client knew enough English, I suppose, to make sense out of my carefully crafted prose.)

The second reason for using PowerPoint in this case was the integration of images. I used screenshots to illustrate the usability critique. PowerPoint, for all its faults, allows users to create layouts with no mess or fuss. Making it easy to paste a screenshot and plop in call-outs is why PowerPoint was invented. The business plan from 1984 for the original PowerPoint contains the passage, “Allows the content-originator to control the presentation” (quoted in the aforementioned New Yorker article).

Microsoft Word, by comparison, allows you to integrate images and add call-outs, but trying to do either can be an exercise in complete frustration. Inserting screenshots into Word is like popping pimples: it is messy and painful, and does not necessarily lead to satisfying results.

Unfortunately, while PowerPoint encourages us to be better writers and lowers the learning curve for including illustrations, it does come with a lot of baggage. The resulting usability report for the Spanish telecom was more than 1,300K. PowerPoint does not optimize file size and therefore can be unwieldy to transport.

Ultimately, the key to creating reports in PowerPoint is to keep them short. My usability evaluation came out to 43 slides—perhaps 10-15 too many. In retrospect, I might have developed two files: a Word document for the bulk of the report and a PowerPoint deck for the supporting illustrations.

PowerPoint for simple website documentation
Whatever PowerPoint’s original intended use, the program has grown and sprouted mutant extremities. Like most applications Microsoft gets its paws on, the basic requirements of PowerPoint stayed the same, but they have been interpreted so broadly that the application has tried to become all things to all people. At its heart, PowerPoint still gives users the ability to put text and graphics on “slides,” but it mutated when Microsoft added functionality to give users more power in manipulating the text and images.

It is in these mutant extremities that information architects might find tools for creating website documentation like site maps or flow diagrams, using the assorted built-in shapes and connectors for example. The decision to use PowerPoint instead of some other application to create a site map should be driven by two things: scope and cost.

If you want to use PowerPoint to diagram a website, you must ask yourself: How much do I want to say? What is the scope of my diagram?

Scope refers to the number of different kinds of information you present in a document. In creating a new diagram, perhaps the most important design decision is determining the number of data points (or “dimensions”) you would like to represent. In our business, a diagram can represent a variety of dimensions: web pages, the relationships among them, the user path through them, the supported user segments or business goals, the requirements satisfied, content types, etc. Every one of our diagrams represents one or more of these dimensions.

Scope also refers to the amount of data covered in each dimension. For example, a diagram can document ten webpages or ten thousand. In creating a diagram, you must identify how much you’re saying within each dimension.

Edward Tufte, author of “The Visual Display of Quantitative Information” and other books on visualizing information, refers to the breadth of data points and the scope of data within each point represented in a diagram as the diagram’s “resolution.” Like the resolution of your computer display, it is a measure of how much information is fit into a given space. Tufte criticizes PowerPoint because it is inherently a low-resolution medium—you can only address so much data using it.

Tufte is, no doubt, correct. Norvig’s representation of the “Gettysburg Address” in PowerPoint shows how it can strip ideas expressed in prose of their power. Equally ridiculous (and illustrative) would be a representation of Minard’s famous “Napolean’s March” in PowerPoint: clip art soldiers and thermometers come to mind.

Perhaps you find yourself in a situation where you simply need to represent one or two dimensions: a high-level conceptual view of the content types supported by a content management system, or the basic facets of a thesaurus. If your data set is small, PowerPoint can be good enough for producing a diagram to illustrate it.

Cost drives the decision to use PowerPoint as much as the scope of the work you’re doing. Cost is determined by several factors, not the least of which is commitment. PowerPoint is ideal for small gigs: doing a bit of low-profile pro bono work or your friend’s wedding website, or working with colleagues on a low-budget side project.

In cases when you cannot commit a lot of time to develop full-fledged, professional-looking documentation, PowerPoint can serve as a low-cost production vehicle. (Jesse James Garrett offers a PowerPoint version of his visual vocabulary, a nice standard for producing website documentation.)

Cost is also driven by portability: how easy is the final product to distribute? While PowerPoint compromises portability in terms of file size, the program does afford widespread support. People are more likely to have PowerPoint installed on their machine than Visio. Adobe Acrobat Reader also enjoys a large install base, but its electronic collaboration capabilities are limited to comments. Users cannot directly manipulate the content in a PDF file unless they have the full version of Acrobat. (One feature I’ve found myself wishing for in PowerPoint is Word’s “Track Changes” function, which allows users to pass a document around and keep track of who made which edits.)

But, the intent of this article is to identify the factors to consider when choosing a tool, not to recommend one over another. PowerPoint is a low-cost tool that affords rapid development time and seamless delivery, but it can only support documentation with a limited scope.

A Fourth Use—Making a Deck of Cards
PowerPoint may have its faults, but there’s no better way to make a deck of cards quickly. Here’s a trick I’ve used for years to prepare for card-sorting exercises.

Open Microsoft Word. Yeah, you’ll have to use both evil applications.

In the View menu, select Outline.

Type the list of terms into your outline. Be sure that each term is assigned the Heading 1 style. If you’d like to include other elements on your cards (a term’s definition, for example) add them as sub-items under the term. Those sub-items will be assigned styles Heading2, Heading3, and so, depending on their position in the hierarchy. Ultimately, each Heading 1 term will appear as a card, and any associated lower-level headings will appear as items on that card. Do not use any other styles for items on the cards. Microsoft Word can only export Heading styles to PowerPoint.

Now for the tricky part: Once you’re done with your term list, from the File menu, go to Send To and select Microsoft PowerPoint from the sub-menu.

The system does the rest! PowerPoint will open a new presentation file and place each of your terms on a separate slide*. If you want to adjust the layout of the cards, select Master > Slide Master from the View menu. You can move the main heading text field into the center of the page, increase the font size, etc. Changes to the Master Slide will be reflected on all the cards. To turn them into cards, print several slides on a page. Nine slides to a page works best, though sixteen works well, too.

Now all that’s left is to track down the paper cutter in the Marketing department!

* Note: The Send To feature is limited to about 200 terms. If you need more cards, simply cut-and-paste your Word outline into your PowerPoint outline.

PowerPoint for presentations
For simple reports and website documentation, PowerPoint can be a useful tool. Ultimately, however, it was designed for presentations, and as an information architect, at some point in your career, you will find yourself doing a presentation—to sell your business, to educate clients, or to deliver the conclusions of your work.

The title of this article, “Understanding PowerPoint,” is an homage to Scott McCloud, who graced us with his book “Understanding Comics”. PowerPoint is neither as misunderstood nor as interesting as McCloud’s medium, but he makes several points that can be applied to the dreaded application.

McCloud describes comics as a dance between imagery and words, integrated movement in which “words and pictures go hand in hand to convey an idea that neither could convey alone” (p. 155). Like comics, presentations have two components: what is spoken and what is projected on the screen. (You could even say it has a third: the “leave behind,” which many presentation gurus insist should be a separate piece from the other two.)

Seth Godin, in his piece “Really Bad PowerPoint,” suggests that people using the application should keep the projected portion of their presentations at the emotional level and the spoken portion at the intellectual. Use PowerPoint, he suggests, to project images that touch your audience and state facts in the spoken part.

Godin’s advice may be valuable for beginning presenters, but for more experienced users, I prefer McCloud’s dance metaphor. Writes McCloud, “the more is said with words, the more the pictures can be freed to go exploring…” (p. 155). And later, “When pictures carry the weight of clarity in a scene, they free words to explore a wider area” (p. 157). The key word here is clarity.

Of course, with presentations, we’re not talking about scenes. But we are trying to tell a story—we would like to carry our audience from a common beginning (“Once upon a time…”) to a believable conclusion (“…and they lived happily ever after.”). Like it or not, PowerPoint is designed to be a storytelling medium, and your presentations should have a beginning, a middle, and an end, like any good story.

The vehicle we use to carry our audience must be a satisfying combination of two channels: spoken word and projected image, audio and visual. The words the audience hears must support the images it sees. The images it sees must illustrate the words it hears.

Comics, because they are an art form, have the liberty to “explore,” as McCloud would have it. But a presentation is a means to an end (usually either selling or educating) and the opportunities to explore are limited. That should not stop a presentation from being a complete story, though, using spoken words and projected images to transmit a message deeper and more complex than either medium could do on its own.


powerpoint.gifThe two main factors you must consider when selecting a tool are the complexity of the data set and the cost. Regarding the data set, consider how many variables you are trying to represent, and the range of values in each variable. For the overall cost, consider the burdens of production and distribution. Having established a simple data set and a low cost, you might consider PowerPoint for your documentation needs, with the understanding that using it may have some implications, such as a large file size and the need for succinct writing.

You’ll find many ways to use PowerPoint effectively in your work as an information architect. PowerPoint is a hybrid: it does many things moderately well. Because it is a single program that allows you to combine simple layouts with diagrams and prose, it is both an ideal tool and ripe for misuse. Tool selection is a design decision like any other—have good reasons for your decision and know the limits of the tool you choose.

Tip o’ the 10-gallon to Mike Lee, leading the IA pack in Baltimore, for inspiration and reading suggestions.

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.

Three Visio Tips: Special Deliverables #4

by:   |  Posted on
“Whether you love it or hate it, if you are an information architect you will probably find yourself using Visio at some point in your career.“No column on information architecture deliverables would be complete without at least some mention of tools. Occasionally I will use this space to provide helpful suggestions on using some of the tools adopted by information architects. In this case, I’ll offer three tips on using Visio, Microsoft’s diagramming application. (Michael Angeles has already written an excellent article on Visio automation.)

Whether you love it or hate it, if you are an information architect you will probably find yourself using Visio at some point in your career. When that time comes, these three tips on styles, backgrounds and the F4 key will be indispensable.

Styles and Formats
Visio, while offering a lot of flexibility in applying styles to shapes, does not do much to help users understand the distinction between Style and Format. While they are inextricably related, they refer to different things. To help you distinguish, consider this table:

  Fill Pattern  
  Fill Color 1  
  Fill Color 2  
  Line Pattern  
  Line End  
  Line Start  
  Line Weight  

Each of these attributes describes one aspect of the “style” of a Visio shape.

Thus, for the above shape, I could fill in the table like this:

  Font Arial
  Size 12pt
  Style Bold
  Color White
  Fill Pattern Checkerboard
  Fill Color 1 White
  Fill Color 2 Black
  Line Pattern Dotted
  Line End None
  Line Start None
  Line Weight 4pt
  Corners Square
  Color Red

All of the information in the table constitutes the shape’s “style.” “Format,” on the other hand, refers to the attributes of the text, fill or line components of the shape (i.e., the right column of the table). Format will always be qualified with one of these components of a shape. You could never talk about a “shape’s format.” You could, however, talk about a shape’s line format, a shape’s fill format or a shape’s text format.

The relationship between Style and Format now becomes straightforward: a shape’s style is the sum of its text, fill and line formatting. This becomes important when you select a shape’s style from the Style menu. In doing so, you affect the format of the text, line and fill of the shape. (Actually, you can define a style with one, two or all three of these formats specified, but the default styles in Visio include all three.)

A confusing aspect of the Style feature is that Visio offers a style menu for each of these shape components. I can select a shape and then select a style from the Text Style menu. When a style selected from the Text Style menu includes formatting for fill and line, you might get this prompt:

Text Style menu

Visio is asking whether you want to style the shape with the fill and line formatting as well as the text formatting. It’s asking, in other words, if you’d like to apply the formatting to all the attributes defined by the selected style, or just to the text.

Backgrounds and Text Fields
By creating a background, you can carry common elements through several pages in a single Visio document. Visio allows you to define many backgrounds, and you can assign any one background to any foreground page.

To create a background, select “Page…” from the Insert menu. You’ll be presented with the page properties dialog box:

Page properties dialog

Be sure to select “Background” under Type and give your background a meaningful name. In Visio, backgrounds are pages in the document. They do not get printed, however, like regular pages.

When you click OK, you’ll see a blank Visio page. For the purpose of this tutorial, we’ll use the background to put my name in the lower right-hand corner of every page in the document.

Background text

Now, to put the background to use, create another page with Insert > Page… This time, however, the page type should be ”Foreground.” Be sure to give this page a meaningful name as well, since we’ll be using it later. To apply our background to the page, select its name from the Background menu.

Background menu

Now, when you click OK, you’ll see a new page with my name at the bottom.

Page with name at the bottom

Backgrounds can be particularly powerful in combination with Text Fields. A text field is a variable space in a text area that Visio automatically fills in depending on the type of field you specified. For example, you could use a Date text field to automatically fill in the date.

When a text field appears on a background, it will draw its information from the foreground page assigned to it. This is particularly useful if you’d like the page name or page number to appear on every page.

To do this, create a text area on a background page. In the text area, insert a text field for “page name.” Then, any foreground page with that background assigned to it will show the page name. Here are the particulars:

Return to the background page you created by clicking on the tab in the lower left corner of the Visio window. Create a new text area on the page. While the cursor is blinking in the new text area, select “Field…” from the Insert menu. (If the cursor isn’t blinking in the text area, you will not be able to select “Field…” from the Insert menu.) You will be presented with the Text Field selection dialog box.

Visio offers an enormous selection of text fields to choose from. To stick with the example, we’ll use the page name. That field is categorized under “Page Info.”

Note how Visio gives you the opportunity to format the text field. This is particularly relevant to date and time fields.

Now the page name appears. Because we’re still editing the background, you’ll see the name of the background page. Switching to the page we created previously, however, shows that the text field automatically changes depending on the page.

Relevant and meaningful page names

You can see why it is important to give pages relevant and meaningful names. By combining backgrounds and text fields, it is easy to create professional-looking deliverables while minimizing the chance of sloppy mistakes through typos or missing information.

I love F4. I discovered this little trick reading an article on before it was merged into Microsoft’s site. The F4 key is Visio’s keyboard shortcut for the “Repeat” command found in the “Edit” menu.

Edit Menu

Now, I know what you’re thinking. In many Windows applications, this command is represented by the shortcut Ctrl-Y. In many applications, Ctrl-Y is a shortcut for the “Redo” command, an undo for the “Undo” command. In other words, if you undo something and change your mind, you can hit Ctrl-Y and it will take your work back to the state prior to the Undo command.

Visio’s F4 is different. In fact, if you do an Undo, the menu command changes to Redo and the keyboard shortcut becomes Ctrl-Y.

Edit Menu

Hitting F4 means, “Repeat the last command I issued.” One use of the Repeat command is to apply formatting to several shapes at once. To do this:

  1. Select a shape.
  2. Change the format of the shape (for example, line weight).
  3. Select other shapes, holding Ctrl to select more than one.
  4. Press F4.

You’ll see the shapes you selected adopt the same formatting. This feature is limited in that the Repeat command repeats only the most recent command given. Try this experiment:

  1. Select a shape.
  2. Change the line weight of the shape.
  3. Change the color of the line.
  4. Select other shapes, holding Ctrl to select more than one.
  5. Press F4.

Instead of adopting both the new weight and color of the line, the other shapes will only adopt the new color.

Visio offers a number of other techniques for applying the same style across many shapes (styles, layers and the Format Painter tool, among others) and F4 is not necessarily the best choice in all situations. The real value in F4 is its ability to repeat a duplication action.

After duplicating a shape, pressing F4 will create another duplication of the shape in the exact same relative position. The best way to describe this is to show it.

I can create a square and duplicate it by holding the Ctrl key and dragging the square to a new position. The top left corner of the duplicate is one-eighth of an inch lower and to the right of the bottom right corner of the original.

Duplicate in relative position

Now, by pressing F4, I can create a second duplicate whose relative position matches that of the first duplicate.

Second duplicate in relative position

If I press F4 again, a third duplicate appears, also in the same relative position.

Third duplicate in same relative position
And so on.

And so on

This technique is useful for positioning objects consistently across a drawing, and for creating grids of objects. To create the grid below, I selected a column of text boxes, duplicated them with Ctrl-drag, and then pressed F4 to make each additional column.

Duplicated text

Regardless of which party you fall into – Visio naysayer or Visio supporter – these tricks can help make your experience with the application more efficient. Visio is filled with tricks like these, but these three are among my favorites and the ones I use most often to get the job done. I hope you’ll use the discussion area for this article to post your own Visio tricks.

In the next column, we’ll compare the standards available for creating information architecture documentation, and help you decide which standard is right for you. (If you have suggestions for standards I should look at, please drop me a line!)

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.

Where the Wireframes Are: Special Deliverable #3

by:   |  Posted on
“The page description diagram is a tool to allow designers and information architects to stay comfortably within their own realms without compromising communication.”In 1998, I was working for USWeb/CKS, perhaps the largest Internet consulting firm at the time. Information architecture was new to the organization, and I was the only one in the Washington, D.C. office who had the chutzpah to call himself an IA. At that point, we hired a new creative director, and together he and I formalized the user experience group in our office. As part of that process, and based on our own bad experiences, he told me that I needed to find a way to take design out of information architecture.

He was referring, of course, to wireframes, though at the time we called them page schematics. We’d been burned too many times, and it started creating a rift between the visual designers and me. A wireframe, as you probably know, describes the contents of a web page by illustrating a mock layout. Usually wireframes are rendered in some kind of drawing program, like Visio or Illustrator, but can also appear as bitmaps or even HTML.

It would have been easy for me to resent the directive. After all, I’m an IA, that’s what we do! But I could see the value in his suggestion, particularly since I’d experienced conflict on projects where I’d trod a bit too heavily on designers’ toes.

The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure.

We tried using wireframes as a strictly internal tool: no client viewing allowed. But as much as a wireframe helped designers visualize the functionality and interaction of the site, it cramped their style. Designers who stuck close to the wireframes did not exercise their creativity, and all our sites started to look the same.

These are the two main risks associated with wireframes: client expectations and designer innovation. (There are others. See below.) While strategies exist to mitigate these risks, they are not 100% avoidable. When the creative director asked me to “take design out of IA,” I had to make a choice:

I could pursue risk mitigation strategies, learning how to set client expectations better and work with designers to avoid compromising their creativity.


I could develop a different approach to documenting information architecture, one that would avoid these issues completely. Devising a way to communicate issues that sit squarely in my court means no more conflict with designers over client expectations or layout. Such an approach would also force clients (and designers for that matter) to talk about content, priorities, and functionality —the issues we needed to address in early stages of the project.

The first option felt desperate, as if I were the little boy trying to plug the dam with no end in sight to the number of leaks. (In college, I took a class in social ethics. The professor, Gary Comstock, once said that if people are fighting over pie, make a bigger pie.)

It was on the redesign of in 1999 that I decided to try a different approach. After building a site map, which described the relationships between the web pages, I created the first “page description diagram” —a bigger pie, as it were.

In a page description diagram, the content areas of the page are described in prose, as in a functional specification. The content area descriptions are arranged on the page in priority order. Typically, I will define the horizontal axis of the diagram as the page priority. Thus, content areas described on the left side of the page are higher priority than those on the right side of the page.

Page Description Diagram Mock-Up

Page Description Diagram Mock-Up with Component Layouts. Click to open a high fidelity PDF of diagram.

With this approach, the diagram represented the two main issues: priority and content. I found that I could include layouts of individual content areas to show, for example, how the “check flight status” form might look. These mini-layouts helped our client visualize the interactivity, but did not lock the designer into any particular approach. Our conversations with the client focused on the nature of the content and functionality and the relative priority of the page contents.

On this particular project, the art director appreciated the approach. He found he could focus more on creating a synergy between the brand and the functionality, rather than being forced into wrapping colors around a predetermined layout. At the risk of speculating on his thoughts too much, I wonder if he had to spend less effort than he would have with a wireframe, which predisposed him to a particular layout.

The page description diagram, by demonstrating priorities and providing a context for the content and functionality, gives visual designers the information they need to create an effective layout. On any given web page, a piece of information can have more or less visual weight depending on the use of color, contrast, typography, and position. But these are the tools of a visual designer, the fundamentals of graphic design, and no business of the information architect.

If a project requires an information architect, the scale of information must be vast. Without a person who understands the nature of the information, other people on the team would spend their valuable time trying to get their heads around it, preventing them from focusing on their own tasks. Information architects who have to worry about layout are distracted from their tasks: defining functionality, content, and structure.

Ultimately, designers are paid because they are good at thinking about visual relationships. Presumably, an information architect focuses on relationships among information, categories, and content, not among shapes, color, and contrast. The page description diagram is a tool to allow designers and information architects to stay comfortably within their own realms without compromising communication.

(This idea, of course, reopens the “defining the damn thing” discussion. Perhaps some definitions of information architecture include page layout, but as a creative director who must consider the interests of both architects and designers, I need to draw a discrete line between the two.)

Whenever I show a page description diagram to designers, they love it. It provides more information without compromising their processes. Information architects, on the other hand, have mixed responses. Some latch onto the concept, eager for some relief from common project problems. Others do not see value in the approach, perhaps because they have not faced the same issues, or perhaps because they have associated their craft with wireframes, they cannot conceive of one without the other.

Page description diagrams do not have to replace wireframes. Indeed, if we are to grow as a craft, we must find additional means for communicating information architecture ideas. Just as laptop computers and desktop computers do similar things but are used in different situations, wireframes and page description diagrams can also peacefully coexist as useful information architecture tools.

The Pros and Cons of Wireframes

These lists originally appeared on the poster I presented at the ASIS&T 2002 IA Summit in Baltimore, “Where the Wireframes Are: The Use and Abuse of Page Layouts in the Practice of Information Architecture.” You can find the poster at


  • demonstrates a site concept quickly, allowing clients to react to content placement and rendering
  • can provide guidance to visual designers with respect to information priorities
  • allows for usability testing early in the project lifecycle
  • can elaborate on a singular vision for the site
  • can facilitate collaboration between design team and information architects
  • is easy for clients to understand


  • hinders creativity and innovation by imposing (real or imagined) limits on design team
  • distracts client from tasks at hand: evaluating page priorities, understanding information relationships
  • is not necessarily HTML-ready if not developed to scale
  • is not necessarily HTML-ready if developed without “chrome”
  • does not provide accurate usability testing results
  • relies on other documentation to provide a complete picture
  • does not consider color, typography, and other brand identity elements
  • requires time to wrestle with layout details, which might change in final design anyway
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. Dan has taught classes at Duke, Georgetown, and American Universities and has written articles for the CHI Bulletin and Interactive Television Today.