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 Fortune.com 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 Visio.com 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.

What You Should Know About Prototypes for User Testing

by:   |  Posted on

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity “An information architecture wireframe is NOT graphic design. I swear, it’s really not!!!”Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:

  • Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
  • As with any user test, it really helps to ask the respondent to think aloud.
  • If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
  • Use a piece of posterboard as your “screen.”
  • Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
  • Attach the folder tabs that come with hanging files to components so they are easier to grab.
  • Invite users to throw away or cross out components that they don’t think are important.
  • Number the pieces so that you can easily refer to them in your notes and keep them organized.
  • If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:

  • Scissors and tape,
  • Different sizes and varieties of sticky notes (which make great drop-down menus),
  • Markers and pens in various colors and sizes,
  • Paper clips and binder clips for keeping slips of paper organized, and
  • Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

  • Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
  • animation features provide automated interactivity,
  • Static Photoshop prototype pages shown to users on a computer screen, or
  • Same as above, but printed out in color on paper.

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

  • Testing the effectiveness of labels and icons.
  • Finding out the right balance of depth and breadth of a topical hierarchy.
  • Determining the right options to offer for narrowing a search.
  • Choosing the most important metadata elements to show on a search results screen.
  • Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.

For more information

  • Evaluating Information Architecture,” Steve Toub (2000).
  • UPA 2000 Proceedings:
    #28 – “Waving Magic Wands: Interaction Techniques to Improve Usability Testing Low-Fidelity Protoypes,” Barb Datz-Kauffold & Shawn Lawton Henry.
    #32 – “Prototyping for Usability,” Jack Hakim & Tom Spencer.
  • “Prototyping for Tiny Fingers,” Marc Rettig, Communications of the ACM, Vol.37, No.4 (April 1994).
    http://portal.acm.org/citation.cfm?id=175288 (ACM Membership required)
  • Using Paper Prototypes to Manage Risk,” User Interface Engineering.
Chris Farnum is an information architect with over four years’ experience, and is currently with Compuware Corporation. Three of those years were spent at Argus Associates working with Lou Rosenfeld and Peter Morville, the authors of Information Architecture for the World Wide Web.

Information Ecology: Bayer’s Book of Maps

by:   |  Posted on
Within the Atlas’ three hundred sixty-eight pages reside one hundred twenty full-page maps of the world supported by one thousand two hundred diagrams, graphs, charts, symbols about the planet earth. One of the purposes of information design is to realize a vivid experience of content. The “World Geo-Graphic Atlas” is a demonstration of this challenge. Edited and designed by Austrian graphic designer Herbert Bayer between 1949 and 1952, and endorsed by industrial pioneer Walter Paepcke’s Container Corporation of America (Chicago), the “World Geo-Graphic Atlas” was released in 1953. Within the Atlas’ three hundred sixty-eight pages reside “one hundred twenty full-page maps of the world supported by one thousand two hundred diagrams, graphs, charts, symbols about the planet earth.” Its debut came decades before the impact of desktop publishing on the design process and before the entry of the term “information design” into the evolving lexicon of visual communications.

An atlas is usually a book of maps. They were named for Atlas, one of the groups of gods called Titans in Greek mythology. For participating in a war against the supreme ruler Zeus, Atlas was punished by standing and supporting the sky forever. Many works of art depict Atlas supporting the Earth, not the sky, on his shoulders.1

The Flemish cartographer Gerardus Mercator first used the term “atlas” for a collection of maps in the 16th century. 2 Atlases have become saturated containers. Extensive editorial (documentation and descriptions) and graphics (cartography and photography) fill an atlas’ large pages. Such an eclectic and dense array of material is both intensive and intimidating. Such material was illuminated in the “World Geo-Graphic Atlas.” From its Preface, Bayer designed the information “in an abbreviated, simplified style with extensive use of the pictorial medium.” Bayer’s rendition of the atlas can be described by the following techniques:

  • Page presence and harmony
  • Multiplicity of views
  • Storytelling

Page presence and harmony


Each spread acts as a poster. The Atlas page size is 10.75″ x 15″. The book’s physicality is monumental. No page acts alone but in concert with another. The Atlas’ pages are complementary: A single seamless surface packed with data. The contrast of content was optimized between facing pages. Each turning of the page unfolded a spectacle. Showcasing a state is a major template. The left side is a microcosm of features, from a display of the state’s bird to a table measuring consumption of natural resources.

The right side of the spread. Click to pop up a very large version of the page (132k)

The right side is a macrocosm through the map of the state. The unified coverage achieves a “state”ment, two pages functioning as a unit of one. The left page naturally transitions into its adjacent counterpart and vice versa. This toggling between two levels of detail provides a dual survey of the land.

Bayer’s orchestration of “the pictorial medium” is lyrical in the Atlas. The grand symphonic poem of the world is broken down into digestible clusters, rhythmic in their visualization. There is a visual lilt to the layouts. The visual composition of data density naturally lends itself to musical play that amplifies the meaning of the content instead of distorting the truth.

Multiplicity of views

Graphical texture is used to illustrate the earth's atmosphere. Click to pop up a very large version of the page (104k)

The graphical texture is thick as shown, for example, on describing the earth’s atmosphere and circulation of air. Texture showing air circulation. Click to pop up a very large version of the page (106k)

The various views of data are matched by the variety of disciplinary views. That is, Bayer gathered and assembled data that crossed disciplines such as geography, sociology, history, astronomy, and geology.3 From the Atlas’ Preface, Bayer states that “There are close ties and overlappings between geology and water supply, between astronomy and glaciers, between population figures and physiographic features, between sunspots and communications.” This texture of multiple forms stemming from multiple disciplines gives each page a contextual ambiance rooted in the liberal arts and sciences. The cultural and physical properties are revealed in the manner of a tapestry whose choreography incites exploration of the subject matter. It also fosters an appreciation for the scientific fields of inquiry in learning more about our habitat through a local or international lens.


The essence of storytelling is creating a path of self-discovery.Narrative is beyond the analogy of the page being the stage. The essence of storytelling is creating a path of self-discovery. In making the story of our world and its ecology as vivid as possible, “significant detail” is presented. Bayer’s handling of the Atlas’ content is like a curator. Concrete details are arranged sensitively to engage the curiosity of the reader as navigator or meanderer. The exhibition of significant details is theatrical. But they not only entertain, they also educate.

“People and places are the twin pillars on which most nonfiction is built. Every human event happens somewhere, and the reader wants to know what that somewhere was like.”4 The writer William Zissner’s words, from his chapter on “Writing About Places” can be applied to the Atlas. Bayer’s handling of concrete detail builds a strong sense of place. The visual organization and treatment is objective but also evokes a setting – the sight and sounds – that fascinates the senses of the reader turned traveler. “The mere agglomeration of detail is no free pass to the reader’s interest. The detail must be significant.”5 Each page of the Atlas is an eloquent passage, not a superficial heap of data. The reader is presented with a passage through time, space, and culture.

Evangelizing Ecology

The Solar System. Click to pop up a larger version of this image.

The Atlas eloquently presents data of the world – its people and places – in a colorful format that is both enriching and enlightening. Bayer orchestrated a sequence that is strong from beginning to end. The Atlas does not only visually capture the landscape of the mid-twentieth century but rewinds to the beginning of planetary movements and of the planets themselves. The typical strategy is to fast forward to the present day and concentrate on the here and now, but Bayer finds relevance in what was, the origins.

A comparison between the growth of the global population to the availability of the earth's resources. Click to pop up a larger version of this image.

Regarding the future, a graphic is found at the end of the Atlas. It shows a comparison between the growth of the global population to the availability of the earth’s resources. The proportion of land to individual is becoming more disproportionate. Tapping into the power of narrative, the visual coda provides an explicit challenge: Take care of the Earth. This coda matches the preamble that expresses a collective conscience in sustaining the challenge.

Visualizing a collective conscious. Click to pop up a larger version of this image.

From the Atlas’ Foreword, Walter Paepcke states, “It is important that we know more about the geography and the conditions of life of our neighbors in the world so that we may have a better understanding of other peoples and nations.” Global empathy through cooperation and collaboration is a key to our world’s survival. In evangelizing the critical value of understanding in an ever-changing information landscape, information design is nothing short but an environmental discipline.

Photos by Ignatius Aloysius, True Ideas

For more information

1 Atlas with Earth on his shoulders.

2 Geradus Mercator coined the term “atlas” for a collection of maps.

3Bayer, Herbert (edited & designed by), World Geographic Atlas: A Composite of Man’s Environment, Chicago, Container Corporation of America, 1953, First edition.

4From On Writing Well: The Classic Guide to Writing Nonfiction, p. 116.

5From On Writing Well: The Classic Guide to Writing Nonfiction, p. 117.

Nate Burgos Nate Burgos is a designer who sustains growing design webliography “Design Feast”:http://www.designfeast.com.

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 USAirways.com 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 http://www.greenonions.com/dan/portfolio/


  • 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.

Coherence, Context, Relevance: Special deliverable #2

by:   |  Posted on

Those of you who witnessed the spectacle that was the deliverables panel at the IA Summit in Baltimore might remember my presentation about the qualities of good documentation. “When a document tells one story, it is coherent. Coherent documents are easy to understand, because every last bit of ink contributes to the overall message.”

This article will expand on that presentation and offer some practical advice on producing deliverables, whether they were visual or prose. Those information architects preparing deliverables face three basic obstacles:

• How to get started.
• How to establish the purpose.
• How to stay on track.

The three qualities of good deliverables – coherence, context and relevance – map to these challenges, more or less, with a bit of overlap.

In Zen and the Art of Motorcycle Maintenance, the narrator asks his students to describe a building. One student struggled to begin the writing assignment, and the teacher suggested that he start by describing the brick in the upper left-hand corner of the building. According to the story, the prose flew from the student’s hand once his teacher had provided a starting point. Unfortunately, preparing information architecture deliverables does not come with as easy a solution.

Instead, start the documentation process by identifying the singular story. The story might be as simple as “how users get from point A to point B,” or as complicated as “how user roles K, L, M and N interact with each other through the system.” By establishing a theme for the document, you can easily identify what details contribute to telling that story.

(Consider storytelling in other media. My father, the film professor, says that every scene in a movie should either elaborate on character or further the story. Everything else is just bad moviemaking.)

After deciding upon what story to tell, you can identify the types of information (Tufte would call them dimensions of data) that would best illustrate it. These data points include web pages, relationships between web pages, form widgets, information hierarchy, user roles, time, system topology, user tasks or any other piece of data that came out while gathering requirements. Having listed the dimensions of data, you can then identify which few will form the basis of the story; the rest are just supporting cast.

Some information architects might be tempted to put too much information in their documents. While the heart of the practice is in the details, information architects can not afford to compromise the integrity and quality of their thinking by overcompensating with inappropriate details. No doubt that information should be captured somewhere, and if it comes up, it might be a signal to rethink the deliverable’s story. (As an example, I had one creative director complain to me about an information architecture document that tried to explain the data model for the content management system of the site, distracting from the documentation of the user experience.)

When a document tells one story, it is coherent. Coherent documents are easy to understand, because every last bit of ink contributes to the overall message. Coherent documents are easier to start. Usually, you can use basic shapes to represent the major information dimension (say, web pages) and then lay additional dimensions on top. Above all, let the data do the talking (the best diagrams I have created create themselves).

Telling a story is one thing. Ensuring your client “gets it” is another. Understanding the message of the document is not enough. Your client must understand where this particular document fits into the entire project. Since information architecture is a stepping stone in the process of building an interactive system —goal-setting and requirements-gathering on one side, designing and developing on the other side— it has a relationship to what came before and what will come later. Good documentation explains these relationships.

One technique that works well is to reproduce portions of previous documentation on your deliverable. Often, a list of goals, requirements or user roles works best. Depending on how you set it up, this can address the entire context, both pre-IA and post-IA. For example, I frequently include a list of high-level business goals on the same page as the site map.

A list of goals helps remind the client where the project started. To help the client understand where the project is going, I compare the project goals to IA and subsequent phases of the project, like design and content strategy. For each goal, I indicate which project phase addresses it:

Project Phases

In this table, the black dots indicate that the output of a project phase significantly addresses the goal. Grey dots indicate that the output of a project phase only somewhat addresses the goal. While you may have to provide some explanation, this device accomplishes three things:

  1. Provides some context by reminding clients of the project goals.
  2. Sets expectations by showing what will be addressed in subsequent phases.
  3. Protects the information architecture from having to address every project issue.

The last point is important. Because information architecture is usually the first design documentation in a project, clients have high expectations for it. Showing clients that IA addresses many, but not all, project issues can diffuse these expectations.

Using a device like the one above helps set the context for the deliverable, so it doesn’t have to tell your story in a vacuum. Such a device can be expanded, however, to show why your story is important in that context, to show precisely how and why it contributes to the project. On the panel, I said that the best way to show relevance is to make the document self-referential. By way of further explanation:

Documents that tell a linear story explain the project along one dimension. Requirements documents, for example, might start with project goals, then talk about users, then list the requirements. When parts of the document refer to other parts of the document ( e.g., requirement 2.3 is related to goal 3.4; user personas Carol and Dave yield requirements 4.0 through 6.0, etc.) the story becomes more solid. Subsequent documents can build on this foundation and continue to refer to it. Through these relationships, a document justifies itself.

Perhaps the thought of a document justifying its being is a bit too existential. But many information architects spend a considerable amount of time doing this anyway. In creating relevance in a deliverable, an information architect does not have to defend his or her work.

There are a lot of things that make deliverables good: coherence, context and relevance hardly constitute a comprehensive list. But by focusing on techniques that achieve coherence, context and relevance, information architects can address the challenges of starting a document, focusing the document and explaining its value. Tight deliverables – ones that go beyond simply dotting I’s and crossing T’s – are, in the end, more valuable to clients and project teams.

In the next Special Deliverable, we will look at a topic that easily ranks in the top five Most Controversial IA Issues. While we won’t be venturing our own definition of information architecture or comparing Visio to OmniGraffle, we will look at the wireframe and it’s relationship to design.

For more information:

2002 IA Summit: Deliverables Panel Presentations

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.

Opening Pandora’s Box: Special Deliverable #1

by:   |  Posted on

Boxes. Arrows. Of all the things to identify with information architecture, this magazine chose to take its title from two shapes; shapes that are fundamental artifacts in our documentation. You could just as easily be reading “There are days when I wonder if all I’m good for is making pretty diagrams. I worry that if you take away the site maps and wireframes, that there isn’t much to an information architect.” “Thesauri and Facets,” “Annals of Controlled Vocabularies,” “Taxonomy Today,” or a hundred other clever alliterations of the various abstractions Information Architects play with. But it is through documentation using boxes, arrows and a myriad of other shapes that we represent those abstractions.

The best part of my job as an information architect is preparing deliverables. While fraught with frustrations —endless details, typos, inconsistencies —the process of documenting a system’s functionality or information structure is creative. It is creative in that we are at once designing the system and designing the documentation to represent that system.

The parallel processes of creation and documentation feed off each other. Through the documentation, we come to a better understanding of our own conception of the system. As we develop a clearer vision of the system through the documentation, we find ways to improve the system.

Good information architects do not have to be good designers, but they must be able to explain their ideas well. If your organization is anything like mine, information architecture is the first foray into the design process, the first time the client sees a solution to the problem. Requirements, objectives and even user models simply state the problem, providing a context for the solution. It is the information architect that puts a stake in the ground: the finished product will look like this!

Our deliverables, therefore, become high profile. Clients, who until this point perceived requirements gathering as merely regurgitation of what they told you, are eager to sink their teeth into something fresh. Developers are eager to start thinking about the system architecture and technical engine. Designers are some combination of eager and suspicious, depending on your organization.

All the hoopla around our deliverables can be concerning, if not downright scary. Thus, this particular box —that of Pandora —is opened. What flies out might be frightening:

Scary thought #1: Information architecture is defined by its deliverables.
There are days when I wonder if I will be making site maps, or documenting taxonomies, or arguing over wireframes for the rest of my life. There are days when I wonder if all I’m good for is making pretty diagrams. I worry that if you take away the site maps and wireframes, that there isn’t much to an information architect. Which brings us to scary thought number two.

Scary thought #2: 20% of a deliverable provides 80% of its value.
Are there particular parts of your document that get the most attention? The 80-20 rule might well apply to deliverables, where 80% of your effort goes into producing something that’s only 20% valuable. Have you ever had the experience where clients or team members virtually ignore your documentation, especially after you’ve worked really hard on it? Or maybe you’ve had clients ask you, “I paid you how much for this?” No doubt every information architect has wondered whether there is value to his or her work, especially if the bulk of the work is captured in physical deliverables.

Scary thought #3: Information architecture is a lonely occupation.
Many information architects are alone in their organizations. All but addicted to SIGIA-L for a little companionship, they mostly toil without an ally, a mentor or a collaborator. People from other disciplines provide occasional useful banter, but these information architects are starved for shoptalk. Information architecture can feel a bit like baking someone else’s cookies, churning out the same shapes every day without an opportunity to branch out.

Despite these and the other demons haunting the practice of information architecture, this particular box holds hope.

Glimmer of hope: Information systems will quickly grow more complex, and continue on that trend.

As audiences face increasingly difficult information landscapes, our outputs will become more valued, our role will become clearer and our community will grow. A world rich with information demands concise documentation. Without it, the value of the information itself diminishes. With companies spending more money on information and knowledge, they will expect the systems built around them to be useful and efficient. The role of the information architect becomes abundantly clear in this type of environment.

But for now, we are on the forefront, perhaps the pre-Golden Age of Information Architecture. And we have a lot of work ahead of us. Through this column, Boxes and Arrows will seek to elaborate on the preparation of deliverables, a crucial component in the maturation of our field. As we explore, we will no doubt encounter more scary thoughts, as well as more glimmers of hope.

In the next installment of Special Deliverables, Dan Brown reviews the concepts of Coherence, Context, and Relevance and why they matter in IA documentation.

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.

Automating Diagrams with Visio

by:   |  Posted on

We have all heard the adage, “Good, Fast, Cheap: Pick any two (you can’t have all three).” The saying might generally be true of the work we produce as designers of information-use environments. Try to test the saying against one of the deliverables we might create—a high-fidelity interface prototype, for example—and see if you can disprove it. You can produce beautiful prototypes in Illustrator, but it will cost you time and money. You can do rough prototypes quickly and cheaply by hand, but the end result won’t look as polished as the Illustrator version.

Turnaround time can be relatively quick if you push your tools to perform for you. Site maps and user flow diagrams are good candidates for automation.

My approach to producing deliverables is to falsify the truism. I do the demanding intellectual work first and then force the tools to succumb to my need to produce seemingly speedy deliverables. The illusion of speed happens because you do the hard work up front—planning, analyzing and documenting your work in doing content inventories, designing user flow, etc. When it is time to realize that work in a document, the turnaround time can be relatively quick if you push your tools to perform for you. In this article I illustrate one method for producing diagrams quickly using software.

The process overview

We probably do most of our intellectual work in preparing deliverables before ever touching a drawing program. When the elements of the information architecture and user experience are defined, we are often expected to produce a polished document to visually represent the information. We can take a semi-automated approach to produce some of these documents using software. Site maps and user flow diagrams are good candidates.

The process I propose assumes that you’ve spent grueling hours doing the work of preparing your content inventory or sketching your user flow diagrams and now want to render your boxes and arrows for presentation. The next step in the process is to take the data produced in that intellectual work and prepare it for use in a diagramming application.

I will illustrate a process that relies on text files exported from Excel and uses Visio to transform those text files into diagrams. You can also use a database management system for this process, but details about using a DBMS are out of the scope of this article.

The steps to be covered in this process

  • Identify and document your nodes
    • For site maps, identify nodes in a content inventory, hierarchically arranged
    • For flowcharts, sketch and identify shapes and connectors
  • Document nodal connections
    • Indicate how parent nodes explicitly link to child nodes
  • Prepare text file for importing to a drawing program
    • Prepare a “shapes” file in Excel or with a text editor
    • Prepare a “links” file in Excel or with a text editor
      • If using Excel, export files to comma- or tab-separated file (saved as .csv or .txt)
    • Combine shapes and links files into one text file for importing into Visio
  • Open/Import and auto-diagram
    • Open the text file in Visio
  • Modify the diagram
    • Manipulate the diagram shapes for clarity and apply any cosmetic changes

Creating site maps or content architecture diagrams

We spend a good deal of time working with content to produce documents that help clarify the scope of data contained in websites. Key to the work of information architecture is the production of documents that list the site contents hierarchically (content audits or inventories) or diagrams that depict the site structure visually (site maps). The content inventory is the starting point in defining our information architecture. Graphic designers and technical people often use these documents in system and design specifications.

Step 1: Identify and document nodes in a content inventory

The process of specifying new data or auditing existing data to be included in a site helps to clarify the next steps in organizing that data for presentation. The inventory of data is often used to produce taxonomies or categories of access points. These access points usually inform the navigation and interface design.

Inventoried content is often categorized as a hierarchy of nodes (categories and subcategories, branches and leaves). A high-level extraction of the top-level nodes, perhaps even several levels deep, might give a good idea of the site structure.

To illustrate how to prepare your text files, consider this portion of a hierarchy for a hypothetical company website.

Content hierarchy for boxywidgets site

  • 1.0 Home
  • 2.0 Corporate information
    • 2.1 What we do
    • 2.2 Who we are
  • 3.0 Our process
    • 3.1 Discovery
    • 3.2 Concept
    • 3.3 Creation
    • 3.4 Implementation
    • 3.5 Rollout
    • 3.6 Testing
  • 4.0 Our clients
    • 4.1 Case studies
      • 4.1.1 Web
      • 4.1.2 CD-ROM and kiosks
      • 4.1.3 Print
    • 4.2 Client list
  • 5.0 Contact information
    • 5.1 Locations
    • 5.2 Online inquiry form
      • 5.2.1 Inquiry form submitted
      • 5.2.2 Inquiry form error

This example shows all the available nodes in a small site. All that Visio will need is a listing of the nodes that we want to diagram.
This list is comprised of:

  1. “Shape Name”—a unique numerical idea for each node and
  2. “Shape Text”—a label for the node. If this data is coming from a more complete content audit document, you should extract only the id and label for this exercise. This is fairly simple to do in Excel if you copy the data to a new sheet and remove the unwanted columns.

Visio accepts a number of other values in the file you import. They are as follows:

Shape,”Shape Name”,”Master Name”,”Shape Text”,”ShapeX”,”ShapeY”,”Width”,”Height”,”Property”

For our task, we are interested in the “Shape Name” and “Shape Text” values. We can simply skip all of the fields following “Shape Text”, but must include blank values using empty quotes (“”) for any fields that we are skipping before the last field. In this case, we use empty quotes for “Master Name” because we’re only using boxes in this diagram. The first value in each line is always the word “Shape” to indicate to Visio that this is the definition for a shape it will draw.

If you are authoring these files in Excel, you can create the first column for the “Shape” value and auto-fill all of your rows with the value “Shape”. The second column will hold your “Shape Name” values. The third column will be a placeholder for the empty “Master Name” field. The fourth column will hold your “Shape Text” labels.

Our sample Excel file would look like this:

Excel sheet with stripped down content inventory

Excel sheet with stripped down content inventory

We can export this sheet to a text file of comma-separated values (saved as .csv) and the resulting file for the content hierarchy will look like this:

; shapes.csv
; Shape file for Boxy Widgets site
Shape,"2.0","","Corporate information"
Shape,"2.1","","What we do"
Shape,"2.2","","Who we are"
Shape,"3.0","","Our process"
Shape,"4.0","","Our clients"
Shape,"4.1","","Case studies"
Shape,"4.1.2","","CD-ROM and kiosks"
Shape,"4.2","","Client list"
Shape,"5.0","","Contact information"
Shape,"5.2","","Online inquiry form"
Shape,"5.2.1","","Inquiry form submitted"
Shape,"5.2.2","","Inquiry form error"

Any line that is preceded by a semicolon (;) is ignored as a comment. I added comments in the first two lines to indicate what this file is used for. The next file we want to create is the file that shows relationships between nodes.

Step 2: Document nodal connections

The list we created above is a hierarchical listing of nodes, so the numbers and position in the list already indicate relationships. However, Visio requires that we explicitly reiterate the relationships by indicating child-parent connections following the format below.

Link,”Link Name”,”Master Name”,”Link Text”,”From Shape (or Connector) Name”,”To Shape (or Connector) Name”

We only need the “From Shape” and “To Shape” values for this file. The first value in each line is always the word “Link” to indicate to Visio that this is how the shape identified in the “From Shape” field will link to a shape in the “To Shape” field. Our link file for the example above would look like this.

; links.csv
; Link file for Boxy Widgets site
Link,"","","","1.0","2.0" ; Link the "Home" to "Corporate information"
Link,"","","","2.0","2.1" ; Link "Corporate information" to child "What we do"

Step 3: Diagram in Visio

We now take the two text files created above and merge them into one file that we are going to save as “ex1_visio_import.csv”. Now we are ready to open the file in Visio using the steps below.

  • File > Open (open dialog window appears)
    • Files of type: Text Files (*.txt,*.csv)
    • Select file “ex1_visio_import.csv”
    • Click Open (File Converter dialog window appears)
  • Visio File Converter dialog window
    • Field Separator: ,
    • Text delimiter: ""
    • Comment character: ;
    • Click OK

The end result is a diagram that needs a good deal of clean up. You can move the boxes around and play with colors to produce a more readable diagram.

Automatically generated site map (click to enlarge)

Cleaned up site map (click to enlarge)


Of course if you don’t want to see your diagram in the hideous colors that Visio gives you to work with, you can copy the diagram and paste into Illustrator where you can make it more presentable and pleasant to look at.

Creating user flow diagrams

While I think it’s rather nifty to create site maps using Visio, I have to admit that what I really prefer to create in Visio are flowcharts.

Flowcharts can be used to help the team understand how users might interact with your system. Interactions such as registration or e-commerce transactions may best be planned using flowcharts. They are also used in diagramming system logic for applications. These documents are often developed with technical people and serve to assist technical staff and graphic designers.

The process for doing flowcharts in Visio is the same as the process shown above for site maps, except we will also be introducing values to specify which shapes to use. We also have to tell Visio which stencils to get the shapes from by specifying a template. With flowcharts, there is less need to move your shapes around once you’ve imported them into Visio. I hardly ever touch the colors and fonts. I view flowcharts as utilitarian documents that are meant to illustrate system logic, so I prefer to show them in grayscale and prefer the linear top-to-bottom presentation, connecting pages with connector symbols when necessary.

To get you started I will illustrate how to use the process shown above to diagram a very simple flowchart. Since you are now familiar with the file preparation, I’m just going to define the fields that can be included for the node and link sections and then show you the files combined in one import file.

Step 1: Document nodes in flowchart

Flowcharting does not lend itself to listing shapes in a hierarchical list the way site maps do. The best approach is probably to first draw your flowchart on paper and number the shapes in the chart. You can then take each numbered shape and add it to your text file. All that Visio really needs to create your flowchart are a few required fields:

  1. The “Shape Name”—the unique numerical id you give it
  2. The “Shape Master”—the name of the shape you want to use from the Visio template (Terminator, Processing, Decision, etc.), and
  3. the “Shape Text”—the label for the shape.

Visio will also accept a number of other values in the file you import. The order of fields should appear as follows:

Shape,”Shape Name”,”Master Name”,”Shape Text”,”ShapeX”,”ShapeY”,”Width”,”Height”

The first value in each line is always the word “Shape” to indicate to Visio that this is the definition for a shape it will draw. We can simply leave off all the values following Shape Text, but we must include blank values using empty quotes (“”) for any values that we are skipping before the last value. If we don’t want to specify shape size and position, we can just skip the last four fields. I’m going to do that for this example.

Step 2: Document nodal connections

Since you have a sketch of your flowchart it should be fairly easy for you to create a list of the links between shapes.
Visio will expect at the very least that you include:

  1. “Master Name”, the name of the connector you will use
  2. “From Shape (or Connector) Name”, the numerical idea or “Shape Name” from the shape list, 2) “To Shape (or Connector) Name”.

The first value in each line is always the word “Link” to indicate to Visio that this is how the shape identified in the “From Shape” value will link to a shape in the “To Shape” value. There are some additional fields that you can use including “Link Text”, a field for a text value that can appear over the connector lines. For our example, we’re going to skip the extra fields and indicate them with empty quotes. The order of fields should appear as follows:

Link,”Link Name”,”Master Name”,”Link Text”,”From Shape (or Connector) Name”,”To Shape (or Connector) Name”

Step 3: Diagram in Visio

Now that we know what shapes to include and how to link them, let’s look at the combined import file we would create for this simple example. We need to indicate to Visio the stencil to reference when looking for shapes identified in our “Master Name” field. So begin the first line with the keyword “Template”, followed by a comma and the name of the Visio stencil file. Stencil templates are the Visio files followed by the extension .vst. You can get the names of stencil templates and stencil files by browsing in your Visio Solutions folder (usually located in “C:Program filesVisioSolutionsFlowchart”) In this example we’ll use the flowchart template “Audit Diagram.vst”, which includes the “Audit” and the “Connectors and Callouts” stencils.

Here is the import file for our example:

; ex2_visio_import.csv
Template, "Audit Diagram.vst"

Shape,"2","I/O","Some kind of input",,,,,,,
Shape,"3","Decision","Test the input",,,,,,,
Shape,"4","Display","Display true message",,,,,,,
Shape,"5","Display","Display false message",,,,,,,

Link,,"No result",,"3","5"

We can save this file and open in Visio using the following steps:

  • File > Open (open dialog window appears)
    • Files of type: Text Files (*.txt,*.csv)
    • Select file “ex2_visio_import.csv”
    • Click Open (File Converter dialog window appears)
  • Visio File Converter dialog window
    • Field Separator: ,
    • Text delimiter: “”
    • Comment character: ;
    • Click OK
Automatically generated flowchartAutomatically generated flowchart


That’s all there is to it. You now have a simple process for generating diagrams in Visio from text files. It won’t make the intellectual work of preparing content inventories or user flow specifications much easier, but it may buy you some time when it comes to rendering that information in a drawing application.

If you work in an organization where you are expected to make modifications to your deliverables quickly, you might value this process. This process will help you make modifications a bit more quickly to those specifications you’ve spent hard hours on, so you can impress your colleagues and clients with how efficient you are.

For more information

Michael Angeles is an information specialist and site developer at Lucent Technologies, Bell Laboratories in the Information Solutions department. He maintains a weblog of information architecture news at http://www.iaslash.org.

Bringing Your Personas to Life in Real Life

by:   |  Posted on

You read about personas in “The Inmates are Running the Asylum.” You know that using them improves your interactive designs and helps get your coworkers on the same boat. You did your ethnographic research, created a useful persona set and are ready to start designing for the needs of your personas. But first you have to document and share your personas with your colleagues.

When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend.

The way you communicate the personas and present your deliverables is key to ensuring consistency of vision. Without that consistency, you’ll spend far too much time arguing with your colleagues about who your users are rather than how to meet their needs. Let’s start with a review of what we know about personas, and why they are useful. Continue reading Bringing Your Personas to Life in Real Life

Learning from the “Powers of Ten”

by:   |  Posted on

Charles and Ray Eames.

To most designers, the Eames name brings to mind rows and rows of molded plywood chairs and Herman Miller furniture of the 1950s. But the Eameses were more than just designers of furniture, they were masters of exploration and experimentation into the realm of experience.

The Eameses used many media to model experience and ideas. The model was a key tool in their design process. The model allowed them to walk through an experience and offered a way to visualize the possibilities and the layers of meaning. One of the modeling tools they used quite frequently was film.

Powers of Ten still
Powers of Ten still
Powers of Ten still
Powers of Ten still
Powers of Ten still
Powers of Ten still
© Lucia Eames
Eames Office

Stills from the final “Powers of Ten” film.
Click to enlarge.

Throughout their career, they made over 120 short films.1 They ranged in topic from the world of Franklin and Jefferson to advanced mathematical explanations to the scientific exploration of scale in the “Powers of Ten.” The exploration into film helped them explore an idea, work out the presentation and the layers of information and understand a process or theory. The Eameses often carried an idea through multiple versions in order to find the right approach to a problem.

On the Eames Office website, Lucia Dewey Eames writes:

“A film could be a model, not simply a presentation of an idea, but a way of working it out. Looking back at the way the office worked, there is a constant sense that the best way to understand a process was to carry it all the way through. For example, in the creation of the project that became the film “Powers of Ten,” first came a test known as “Truck Test,” then the production of “Rough Sketch” (8 minutes; color, 1968), which was a model of the idea of the journey in spatial scale. Only by carrying the idea all the way through could one see the right way to approach the problem. And, indeed, the final version of “Powers of Ten” (9 minutes; color, 1977) has quite a few differences. But both films are models in a more important sense: they are models of the idea of scale. Because such Eames models managed to capture the essence of the problem, they were in fact quite satisfying in their own right.”2

In an interview in ISdesigNET magazine, Charles and Ray’s grandson, Eames Demetrious says:

“There may be a tendency to assume the films are a charming footnote: Furniture designers making films. But that is not how it was, not how Charles and Ray saw it at all. For them, the films were an intrinsic part of the process.”3

“The Powers of Ten,” perhaps their most successful film, is one such model into the nature of scale. The first version, developed in 1968 for the annual meeting of the Commission on College Physics, went under the title, “A Rough Sketch for a Proposed Film Dealing with the Powers of Ten and the Relative Size of the Universe.” (8 minutes; color, 1968). In 1977, with the help of Philip Morrison, professor of physics at MIT, they updated and refined the work under the new title, “The Powers of Ten: A Film Dealing with the Relative Size of Things in the Universe and the Effect of Adding Another Zero” (9 minutes; color, 1977). The film sought to visualize the relative size relationships of elements through space and time and expose what happens when you add another zero to the equation.

“The ‘Powers of Ten’ also represents a way of thinking—of seeing the interrelatedness of all things in our universe. It is about math, science and physics, about art, music and literature. It is about how we live, how scale operates in our lives and how seeing and understanding our world from the next largest or next smallest vantage point broadens our perspective and deepens our understanding.”4
—Powers of Ten website

Series of Sketches for the Films
Chart plotting sequences of “Powers of Ten”
Storyboard sketch 1
Storyboard sketch 2
Storyboard sketch 3
Storyboard sketch 4

The film starts by showing an image of a sleeping man at one meter square (100) and gradually pulls back, moving ten times away for every ten seconds of time that passes, eventually reaching the edge of the universe (1025). The camera then zooms forward, into the sleeping man’s hand, finally reaching the inside of an atom (10-18).

Rough Sketch still
Rough Sketch still
Rough Sketch still
Rough Sketch still
© Lucia Eames
Eames Office

Stills from the “Rough Sketch.”
Click to enlarge.

The exploration of information presentation in the “Rough Sketch” and in the final “Powers of Ten,” speaks to the value of models that the Eameses used to explain their ideas about information organization and presentation. The imagery explores both size relationships and time. It explores the visual relationships of elements and developing patterns that emerge at different scales. The control panel (in the “Rough Sketch”) that is always present on the screen visualizes another six levels of information at its peak.

The combination of imagery and the control panels explores the nature of simultaneous presentation of information. The Eameses push the boundaries of what can be taken in and understood at any one time, they play with the notion of information overload and information absorption. The 1968 version (“Rough Sketch”) explores more levels of simultaneous information than the 1977 final version, in which the panel display is reduced to its most essential information and relocated for better comprehension and retention.

Sponsored by IBM, the film was one of the many efforts that the Eameses worked on to bring science, technology and art together in a way the average person could understand.

“Eames approached the problem in universal terms (to please the ten-year-old as well as the nuclear physicist) and, as in designing a chair, sought to find what was most common to their experience. Sophisticated scientific data was not the denominator (although the film had to handle such matters with complete accuracy to maintain credibility), but it was the inchoate ‘gut feeling’ of new physics which even the most jaded scientist, as Eames says ‘had never quite seen in this way before.’”5

Although more than 20 years old, the series of films offers lessons on successful presentation and explorations of layered information. The information problems explored through film, by the Eameses, are really no different than many of the problems facing information architects today. Studying the Eames’ work and their processes may yield effective processes for today’s IA. Using different media and methods in prototyping and modeling of ideas, as well as presenting layers of information in a way that is simple and elegant, the Eameses succeeded in their original goals:

“The sketch should, Eames decided, appeal to a ten-year-old as well as a physicist; it should contain a ‘gut feeling’ about dimensions in time and space as well as a sound theoretical approach to those dimensions.”6

For more information: View All End Notes