Representing Content and Data in Wireframes: Special Deliverable #10

Written by: Dan Brown
“Information architects sometimes do not repeat data but invent more of it.”Visio practically groaned as I opened the wireframes for my current project, which were in something like the twentieth revision. It was the usual story—poorly defined requirements and business rules—and my project folder was fast becoming the poster child for Feature Creep Flu. To hang all the versions of the wireframes up side-by-side would reveal something like the storyboard for Memento.

Anyway, as meticulous as the project manager and I were in going through the wireframes to ensure they looked “clean,” things are always dirtier in the cold light of day (read: during the presentation to the client). Although it went well enough, the hang-ups in this meeting were over the examples used in the wireframes, requiring additional explanations to clarify functionality. Until that moment, I had not given much thought to the kinds of sample data and content I used the in wireframes.

Typically, sample data and content in wireframes is repetitive and invented:
Sample data and content

During my presentation, a table similar to this one stopped the client in his tracks. Is it a list of the same address over and over? Given the circumstances—and that the requirements had changed so much—this was not an unreasonable question.

Information architects sometimes do not repeat data but invent more of it, so the address book above might also contain entries for Jane Doe, Homer Simpson, and Mickey Mouse. Invented data or content is essentially meaningless, representing an archetype of the kinds of information expected to appear in different areas.

Using repetitive and/or invented data, however, can confuse and mislead stakeholder in five different ways.

  • Misrepresent rules and behavior
  • Misrepresent what the user sees
  • Shift focus from the design
  • Misrepresent the data’s impact on the page layout
  • Misrepresent the scope of the fields

To illustrate all these, we’ll look at one of the most data-rich screens available on the Web: the shopping cart.
Data rich screen in a shopping cart

  1. Misrepresenting rules and behavior:
    In a word, the math in our shopping cart doesn’t add up.
  2. Misrepresenting what the user sees:
    This order has two destinations and users can click the second destination to see what’s going there. Because the dummy address is repeated, however, it does not accurately illustrate what the user will see.
  3. Shifting focus from design:
    If dummy data ends up being inaccurate (“Hey, widgets don’t come in black!”) stakeholders can be more focused on the data than on the architecture.
  4. Misrepresenting data’s impact on page layout:
    Using exclusively short examples does not accurately show the designer what he or she will have to accommodate in the page layout. Frequently this leads to some dummy data like, “ThisIsAVeryLongNameToShowWhatLongNamesLookLike.” Which is just weird.
  5. Misrepresenting field scope:
    An address field can take so many different forms (apartment numbers, international addresses, ZIP+4, etc) and no dummy data can accurately capture all the variations.

No doubt each of these problems can be solved individually: use numbers that add up, use two different dummy addresses, etc. But coming up with a comprehensive, unified strategy to represent data and content can make wireframes easier to create and present. That is, the examples selected for a wireframe should tell a single, complete story.

The Universe of Sample Data
A cursory review of some wireframes out there reveals five different kinds of sample data and content, listed here from the most concrete to the most abstract:

Actual 7220 Wisconsin Ave, Suite 300, Bethesda, MD 20814
Dummy 123 Main Street, Anytown, ST 22222
Labeled Address1-30City-30[ZIP-5]

numbers indicate field lengths

Symbolic ##### XXXXXXXXXXXXX XXXXXX, XXXXXXX, XX, #####

for dates: MM/DD/YY or something equivalant

Greek Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi.

No one kind of sample data is better than any other kind. Indeed, like most things, it depends. In this case, the type of information, the disposition of the client, and the amount of detail required would all influence how examples are displayed.

Some advantages and disadvantages to each kind of sample data:

Advantages Disadvantages
Actual Recognizable by stakeholders.
Offers most accurate depiction of what users might see.
May be difficult to get enough actual data to populate all areas.

May not address all possible variations of data.

Dummy Easy to generate examples.
Closely resembles what users might actual see.
May be confused with actual data.
May not address all possible variations of data.
Labeled Describes content of data. May be difficult to explain to stakeholders.
Different data may be represented by same variable names.
Symbolic Can show “shape” of data. Could clutter wireframe.
May be difficult to distinguish between different types of data.
Greek Easy to generate examples.
Avoids distraction from interface.
Represents prose well, but may not represent other kinds of data effectively.

With the universe of sample data codified, information architects need only a mechanism for deciding which type is best for different applications. A hard-and-fast formula is perhaps not appropriate, but I’ve devised four strategies for typical documentation problems.

Prose
Greek text is most appropriate for representing long blocks of prose. Where description of the content is necessary, I justify and dim the greek while superimposing copy direction over it.

Greek text representing long blocks of prose

Tables and Lists
Because the data in tables and lists tend to include repetition of type, using dummy data can confuse stakeholders if they take this to mean that the real content (not just the type) is repeated. Using actual data in a table may help, but comes with all the disadvantages of using actual content (finding it, ensuring it represents all variations, etc.) After some experimentation, I decided to use exclusively labeled data:

Labeled data in a table

Annotations must accompany such a table to indicate the rules for populating it.

Dates
If a Web application depends on dates, the wireframes should use actual dates and employ them consistently. The project I mentioned at the beginning of this article was a scheduling application. As the wireframes evolved over several weeks, the date examples I used in the wireframes were not applied consistently. Some screens showed sample dates from May and others from August, which made narrating the scenarios very difficult.

To approach this issue on my final round of revisions, I first listed all possible scenarios (schedule new event, change existing event, etc.) and then identified key milestones (first login, first scheduled event, subsequent login, etc.). With these dates defined up front, the wireframes told a more coherent story.

Date data present an additional problem since they can appear in several formats. Wireframes can address this problem by specifying a format on a cover sheet. Symbolic sample data is frequently useful for specifying date content. The symbol should match the format:

Sample Date Appropriate Symbol
7/26/04 M/D/YY (the single M and D specify using one digit where possible)
07/26/2004 MM/DD/YYYY
Jul 26, 2004 MMM DD, YYYY (the three Ms indicate using the three-letter month abbreviation)
July 26, 2004 MMMM DD, YYYY (the four Ms specify using the full month name)
Monday, July 26, 2004 DDDD, MMMM DD, YYYY (the four Ds BEFORE the month specify spelling out the name of the day)

Unique and Non-Unique Data
Using labeled sample data presents a challenge because a variable name can represent more than one piece of information. For example, in an address book application, [FirstName] could represent the name of the address book owner or the name of someone in the address book. There are two strategies for dealing with this situation:

  1. For data that is unique, always use actual or dummy data. In the address book example, the first name of the owner would always be rendered as “Jane,” for example. Non-unique data could then use the labeled format (e.g., [FirstName-20]) without conflicting with unique data.
  2. Using the labeled data format, visually distinguish unique and non-unique data. For example, when referring to a specific first name, the field could appear with braces instead of brackets: {FirstName-20}.

Conclusion
Sample data can make or break a wireframe, whose purpose is typically to illustrate architecture and interaction. Poorly selected sample data can end up clouding the wireframe or distracting stakeholders from its purpose. By codifying the types of sample content they employ in their deliverables, information architects can create a coherent narrative to illustrate a website’s functionality.

These days, rather than try to think of sample data, I use the labeled format almost exclusively. (Combined with Visio’s stencils, this makes keeping the wireframes up-to-date very easy.) If, later in the process, it becomes appropriate to include more concrete sample data, it’s easy enough for me to go in and change [FirstName-20] to Jane or John.

Dan Brown is not the Dan Brown who wrote The Da Vinci Code, but he wishes he were.

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, Interactive Television Today (itvt.com) and Boxes and Arrows

The Information Architecture of Email

Written by: Dan Brown

“Gmail revealed to me my email behavior — something I hadn’t previously given much thought.”

At least several times a year, I try (I really do) to set up folders to sort my email. I am an information architect, after all. Setting up folders is, according to my job description, my area of expertise. Actually, I suck at setting up folders for email.

Email is hard to sort into a strict taxonomy because:

  1. Most messages could live in more than one category.
  2. Personal and business priorities may shift several times a year, rendering email taxonomies obsolete.

Gmail is Google’s foray into the free email market, and attempts to address these inherent limitations. Typical of Google, they avoided putting out just another email service. Put aside the controversy about the privacy invasion, and Google’s email interface is remarkably innovative. (My exposure to email handlers is limited to Outlook, Outlook Express, Entourage, and various online email services. Gmail’s approach may be old news to you.)

Gmail revealed to me my email behavior — something I hadn’t previously given much thought. By making certain things easier (and others more difficult), Gmail showed me how “typical” email applications weren’t necessarily designed according to how I used them.

Messages in threads

I’ve already mentioned categorizing emails, a behavior most email programs expect users to do. Instead, Gmail bundles messages together in threads. A reply to one of your messages, therefore, does not appear as a separate message in the long queue of messages in your inbox. Instead, it simply is appended to the end of the thread. In the inbox, the thread is highlighted in bold to show that there is a new message.

By keeping all the messages together in a single thread, it’s easier to follow a conversation. More importantly, it doesn’t bog down the inbox with lots of messages with the same subject line.

Google introduced some nice interface elements in both the inbox and in the message view to make it easy for users to adapt to this unusual approach.

In the inbox, threads with new messages get promoted to the top and the total number of messages in the thread is indicated near the subject line. One of my favorite features is that the “From” field indicates the last three people to contribute to a thread. So if I’m emailing with my wife on something related to our home renovation, the From field would show “me, Sarah (7),” showing that we’ve exchanged seven messages.

gMail.gif
Screenshot of thread in the inbox

In the case of emailing with friends throughout the day, the From field might show “Nate, James, Eric (5),” showing that of the five messages exchanged, Nate, James, and Eric were the last three contributors. (It may be worthwhile to have some indicator of whether they were the ONLY contributors to a thread or if there were more.)

When displaying the thread itself, Gmail shows the messages in the order they were received, with the oldest one at the top. This may seem inconvenient, but Gmail hides all but the headers of the older emails, so the newest email is easily above the fold. The header includes the name of the person who posted the thread, a little teaser from the message, and the date it was posted. Clicking on the header of any given message reveals it without leaving the screen.

In a sense, threading messages is like putting them in folders, with each folder being a different thread. Messages, therefore, are pre-categorized, removing that burden from the user. In my case, this is an enormous relief, since I’m not much of a Message Categorizer. (There is no way, according to Gmail Help, to ungroup a message from its thread. But we’ll see shortly that it is unnecessary.)

The reply function appears at the bottom of the page, which could present problems if you’re looking at an especially long message. (The problems with unsnipped quoted messages become readily apparent.) With short messages, this doesn’t present a problem because the reply function is sufficiently above the fold and scrolling is unnecessary.

The annoyance of occasionally having to scroll to reply revealed that I’m equally likely to hold off replying to a message as I am replying to it right away. Sometimes, I’ll wait until later in the day or week to have time to reply to it. For a long message on Gmail, this means scrolling down to the bottom of the page to reach the reply function on a message I’ve already read.

Archive it and forget it

Another behavior I’m loath to admit is that I’m a packrat, and email servers and I have never gotten along because of it. At least once a week, I get scolded that I’ve used up too much space in my inbox. My Yahoo! Mail account goes weeks at a time with a warning message at the top of every page, a bright red bar shouting “98%” at me.

Gmail was designed for us packrats. Besides giving users a gigabyte of storage, Google introduced an “archive” feature with their online email. Although Gmail allows users to delete messages, it instead encourages them to archive messages. In fact, the two most prominent buttons on the inbox page are Archive and Report Spam. The interface for viewing a thread of messages adds “Back to Inbox” to this list, but nothing else. Putting an item in the trash is a task buried in a drop-down menu.

Archiving is Google’s answer to inbox management. Typical email programs expect users to manage their inboxes by removing messages to folders. Every time I need to categorize a message, however, I need to make a decision about where it goes. To paraphrase Steve Krug, “Don’t make me make a decision.” Call me lazy (you wouldn’t be the first), but I shouldn’t have to make a decision every time I get an email. It’s a lot of brain power for not a lot of value. Just because I put something somewhere doesn’t make it easier to retrieve later.

Because there are no folders, Gmail’s inbox could easily become unwieldy, but a message in Gmail exists in one of two places: inbox or archive. For those threads that are no longer active, but you want to hang onto, you can archive them. Putting a thread in the archive simply puts it in storage and removes it from the inbox. If you get another message in an archived thread, the thread appears again in the inbox.

By default, Gmail shows only the inbox, but the “All Mail” link on the left hand bar reveals every thread currently stored, even those you’ve started but to which you haven’t gotten a response.

By archiving messages, you might think they’re essentially gone. You might as well have trashed it. After all, how easy is it to find something in your attic if you haven’t put it in a labeled box? Google, however, includes a handful of powerful features (including its search engine) that renders the email attic as neat and tidy as your local library.

Searching, stars, and spam

Google’s familiar search box appears at the top of every page, though the button “I’m feeling lucky” is replaced by “Search Mail.” You can enter any search term and Gmail will return any threads that include the search terms. Clicking on any of the threads from the search results will reveal the thread. Those messages in the thread that contain the search term are expanded in the thread view, and the search term itself is highlighted in those messages.

Gmail’s search engine is, of course, fast. While a search on my wife’s name in Gmail took less than a second, a comparable search in Outlook Web Access took nearly 15 seconds. Searching on multiple terms leads to similar results. When it comes to email, I prefer searching to browsing, especially when Google is under the hood.

After explaining these basics to my friend Eric, he indicated that he was wary because he uses a lot of filters and subscribes to a lot of mailing lists that are automatically sorted into separate folders. He had a good point, so I looked at some of the other email management features offered by Gmail. Despite the lack of folders, Gmail does give users different ways of marking and categorizing messages.

The method that requires the least amount of thought is to mark the message with a star. In other email applications, this would be like setting a flag. The purpose of starring a message is to give it some priority, and making it easily findable. A white star appears next to every message, whether in the inbox or in viewing the thread. Clicking on the white star turns it yellow and adds a star to the message. A link on the left bar allows users to see all the messages they’ve starred.

For those who feel they would miss folders, Gmail offers labels, a way of categorizing messages. Labeled messages do not disappear from the inbox, unless they’ve been archived. Instead, a message’s label appears adjacent to the subject line. A list of the uesr’s labels also appears in the left bar. Clicking on one of the label names shows all the messages with that label.

Like most email applications, Gmail has filtering functionality, allowing users to apply rules to messages as they arrive. There are four actions a filter can do to a message: trash it, archive it, star it, or label it. Once users establish filtering criteria, they can select any number of these actions.

To test Gmail’s ability to deal with mailing lists, I subscribed to a new mailing list (for people who play the mandolin, a new hobby of mine) and applied a filter. New messages that arrive from coMando are labeled and automatically archived. Mailing list messages, therefore, do not clutter my inbox. At the same time, they are automatically grouped together under the correct label. Clicking on the “coMando” label on the left bar allows me to see all the mailing list messages.

I was pleased to see that when new mailing list messages arrived, the label name appeared in boldface to show that there were new messages, even though they were sent straight to my archive and not in the inbox. The number of new messages also appeared in parentheses next to the label name. The label, in other words, behaved as folders do in other email applications.

No review of new a new email application would be complete without looking at its spam-handling capabilities. Despite having Gmail for only a month, I’m already receiving spam—30 messages in the last week. Gmail’s left bar has a “spam” link to show you all the email that you’ve received that has automatically been categorized as spam. In the last several days, none of my personal email was mistakenly categorized as unsolicited mail. On the other hand, at the beginning of the week, I received three unsolicited emails in my inbox. Since then however, none has made it to my inbox.

Although it’s a little disconcerting that I’m receiving unsolicited messages while barely anyone has my new email address, Gmail’s ability to handle spam seems as good as any other email application.

Conclusions

As Gmail comes out of beta, Google may find itself with a product that users are slow to adopt. People may find the subtle change in the email paradigm more dramatic than Google anticipated. Perhaps this speaks to the dangers of bad design: a bad product can just as easily become entrenched as rejected, such that when a better one comes along, users are reluctant to adopt it.

It may be difficult to think of email applications as “bad design,” and before I started using Gmail it never occurred to me that they were. On the other hand, Google’s different approach to email has led to some stark revelations about my email behavior. At the most basic level, managing email — an activity whose necessity rates somewhere between scheduled car maintenance and eating — requires too much thinking under current models. Users may be pleased to have to “think less.”

The paradigm shift, however, will be the least of Google’s problems. With its search engine advertising practices under constant scrutiny, Google faces myriad new issues by attaching targeted advertisements to emails, potentially a gross invasion of privacy. At the same time, the advertisements for mandolin dealers and instructors that come attached to posts to the mandolin mailing list are almost as valuable as the posts themselves.

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, Interactive Television Today (itvt.com) and Boxes and Arrows

The Visual Vocabulary Three Years Later: An Interview with Jesse James Garrett

Written by: Dan Brown

Special Deliverable #9

In October 2000, Jesse James Garrett introduced a site architecture documentation standard called the Visual Vocabulary. Since then, it has become widely adopted among information architects and user experience professionals. The Visual Vocabulary is a simple set of shapes for documenting site architectures. In conceiving the vocabulary, Jesse sought to create a system that was “tool-independent“—that is, readily adaptable to any diagramming software as well as any medium (pen and paper, dry-erase, etc.). The vocabulary was also designed to be portable, fitting easily on letter-sized paper for convenient printing.

Despite the unassuming approach Jesse took in promoting the vocabulary—he posted it to his website—it has earned a reputation as a useful tool for the practicing information architect. So useful, in fact, that it has been incorporated as a template in several diagramming software packages, most notably OmniGraffle. Jesse has evolved the vocabulary over time, welcoming contributions and extensions from people all over the world. Through the work of others, the vocabulary has been translated into seven languages beyond English and is summarized in a cheat sheet.

More information about the Visual Vocabulary may be found at Jesse’s website: http://www.jjg.net/ia/visvocab.

B&A: How has the Visual Vocabulary changed in the last three years?

JJG: It hasn’t changed as much as I expected. When I released the vocabulary in 2000, it still seemed to be in flux—some of the elements were fairly new additions, and I figured it was likely that there would be more in short order. But, in retrospect, the vocabulary was actually more mature than I realized at the time.

B&A: What element or innovation of the vocabulary are you most proud of?

JJG: I think my favorite aspect of the system is the emphasis on practicality throughout its design. At that time, the mainstream school of thought held that any respectable information architect should be producing color deliverables in a professional diagramming or drawing application, and if you want to do any serious, large-scale architecture work, for God’s sake go get yourself a plotter. I saw the resources my clients tended to have, and went in the opposite direction: I wanted to enable anybody with a copy of PowerPoint and a cheap black-and-white inkjet to solve the same kinds of problems.

B&A: Why do you think no other IA documentation standards have emerged in the last three years?

JJG: I suspect that there are a lot of people out there who have cooked up their own ways to express complex (and not so complex!) architectural concepts. They just can’t publish them without making their bosses angry. So I think there are a lot of standards in use out there—they just aren’t public.

B&A: There are several other kinds of IA and UX documents—wireframes, content inventories, personas, etc.—do you think there’s room in the industry for standards for these?

JJG: I think there’s room, but there isn’t necessarily a strong need. In my work, at least, I haven’t encountered a case where I thought a deliverable could be substantially improved by the development of a universal standard.

I’m not dogmatic about the need for standards. Documentation standards only help us to the extent that they enable us to communicate complex concepts without having to invent new means of expression for each new problem. Every once in a while I get email from someone asking me to look at a diagram and tell them if it’s compliant with my system. Although I love seeing examples of what people are doing with my work, I always tell them not to worry about what I think. It doesn’t matter whether your diagrams pass the “JJG validator”—what matters is whether they successfully communicate your ideas to your colleagues.

B&A: What makes the site architecture a deliverable that “could be substantially improved by…a universal standard?”

JJG: Architecture is an abstraction—the information that has to be conveyed is largely conceptual, not concrete like the interface details you might find in a wireframe. So you don’t have the luxury of a straightforward means of representation that you can rely on to be self-evident to your audience. Additionally, the nature of architecture work—describing interrelationships among information and interaction elements—really cries out for visual representation. Having a standard visual way to express those relationships means the architect can spend less time grappling with representing the architecture and more time refining it. Plus, it gives us a common language for sharing our work with our peers, which is important and necessary to the maturation of the discipline.

B&A: Have you found any design problems the Visual Vocabulary cannot represent?

JJG: I haven’t ever encountered a system I couldn’t describe in the vocabulary. Of course, some concepts are harder to draw than others. One attribute of the vocabulary is that the complexity of the representation is proportional to the complexity of the system being described. Simple and straightforward systems have diagrams that are easy to read; systems in which a lot of variables are being juggled and conditions evaluated make for diagrams that take a good amount of attention to create and read.

B&A: What makes the site architecture such an appealing deliverable for clients?

JJG: I often refer to the architecture diagram as a “trophy deliverable”—of everything involved in a project, it’s the one most likely to be pinned up proudly on a manager’s wall. I think there are two reasons it has such a strong appeal. First of all, it’s a visual deliverable. Written documentation just doesn’t have the same visceral impact. Secondly, it’s often the only deliverable that provides a high-level view of the project. Frequently this is the one document that most comprehensively answers the question, “What exactly are we building here?”

B&A: What techniques do you use when presenting site architectures to clients?

JJG: I always take the time to walk them through the architecture. By the time I’m ready to present the architecture, I have a pretty clear idea of what parts they’re likely to approve without a second thought, what parts will require a little careful framing to get them to understand where I’m coming from, and what parts will really need the hard sell. I plan the walk-through accordingly: get them started with easy stuff everybody can agree on, then work them up to the hard questions by showing them around some areas that introduce the more difficult considerations involved in the architecture.

B&A: The last three years have seen the emergence of more complex websites. What effect has this growth had on IA and specifically IA documentation?

JJG: With the proliferation of large-scale, complex, dynamic sites, IA has moved (further, some would say) into the realm of the abstract. Instead of specifying specific links between specific pages, we’re often developing rules by which such links—or even the pages themselves—can be generated automatically. The documentation has had to adapt to that increasing abstraction. I often find myself using the vocabulary to diagram navigational relationships between abstract classes of pages, rather than specific elements with unique URLs.

B&A: Would you consider introducing a new vocabulary specifically geared toward more abstract problems?

JJG: That’s an area worth exploring, for sure. I don’t yet know where those explorations might lead.

B&A: Is there a Visual Vocabulary book in the works?

JJG: Running Adaptive Path doesn’t leave me a lot of time these days to consider writing another book. But suffice to say there’s a good reason there isn’t much detail on the vocabulary in my first book, The Elements of User Experience. I’d want to make sure I took the time to do it right.

B&A: What’s the best feedback you’ve gotten on the Visual Vocabulary?

JJG: A number of people have emailed me with alternate approaches to this or that aspect of the system. It’s great to see the ways in which people have adapted the system to their needs. Sometimes they’re a little anxious about how I might react to their tinkering, but my advice is always: “Do what works.” Take the parts that can help you do your job, don’t worry about the rest. If you have a different way of expressing the same idea that everyone on your team understands, use it.

B&A: Have you seen an example of work where the author used the vocabulary in a way you hadn’t thought of before?

JJG: There are people out there using the vocabulary to document systems many times larger and more complex than anything I had worked on when I was developing it. I had the idea in the back of my mind that the system should be modular and scalable, but I never imagined the sheer complexity of some of the systems people are now maintaining using the vocabulary.

B&A: The Visual Vocabulary has become so entrenched; its templates are shipping with diagramming products. Did you anticipate this response?

JJG: I think I was more surprised than anyone when applications started supporting the vocabulary. I didn’t know about any of these products before they were released. I literally did a double-take the first time I saw the IA stencil in OmniGraffle. It just goes to show you that things have a life of their own once you release them into the world. You never know where they’ll end up.

B&A: What’s the most requested update to the Visual Vocabulary?

JJG: The vocabulary currently treats the page as something of a black box; anything that happens within or between elements of a page can’t be represented in the system. Among people who deal with problems like pages that are dynamically assembled based on certain conditions, there’s a desire to see the vocabulary extended to address this page-level logic. It’s an interesting problem. I’m not convinced that the vocabulary is the right tool to solve it, but I’d like to take a crack at it.

B&A: Can you give an example of this kind of problem?

JJG: Page logic comes into play when you have content or design elements that change depending on conditions. If a navigational element differs based on user type, or based on some other defined condition, the Visual Vocabulary can represent that. But it’s not designed to describe other aspects of the page that might change based on conditions.

B&A: You’ve devised and distributed other tools for UX professionals—the Nine Pillars, The Elements of User Experience. Do all these tools comprise part of a larger whole, or are they meant to be used independently?

JJG: There’s a sense in which the “Nine Pillars” grew out of the Elements, although that path was not as direct as it might seem. The vocabulary developed on a separate track, following the first IA cocktail hour in San Francisco. We did a deliverables show-and-tell, and my diagrams spurred a lot of questions. I started out composing an email answering those questions, and that eventually became the full-blown description of the system I posted to my site. I wish I could say there’s a master plan at work here, but really all I’ve ever done is pursue answers to questions I found interesting.

B&A: What questions are haunting you these days?

JJG: I’m still haunted by the big question I raised in “ia/recon:” What happens at that point when the “miracle occurs,” when we turn our knowledge and intuition about people into information architectures? How can we, as individuals and as a community, develop the skills to make those conceptual leaps?

B&A: How do you think the Visual Vocabulary will change in the next three years?

JJG: I don’t expect the vocabulary itself to change all that much. I would expect it to be joined by other, similar systems for describing other facets of a user experience solution. The vocabulary was never meant to stand alone anyway—as central as architecture diagrams are to my work, I always considered the Visual Vocabulary one particularly handy tool in my toolkit. I look forward to having more!


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, Interactive Television Today (itvt.com) and Boxes and Arrows, an online magazine dedicated to information architecture. In March 2002, Dan participated in a panel discussion on the creation of information architecture deliverables at the annual IA Summit in Baltimore. He also presented a poster entitled, “Where the Wireframes Are: The Use and Abuse of Page Layouts in the Practice of Information Architecture.” Currently, Dan leads the Information Design and Content Management group within the office of e-Government for the Transportation Security Administration, a federal agency dedicated to protecting freedom of movement in the US.

Deliverables and Methods: Special Deliverable #8

Written by: Dan Brown
“User experience tasks and activities were aimed at answering these questions: Who is the user? How do they interact with the system? Does the system work?”Toward a universal methodology
When I was at the consultancy-that-shall-not-be-named, I worked with a talented group of user experience consultants as part of a multi-office initiative to establish the user experience practice. The purpose of the practice was to define standards and tools that could be employed across the firm. The standards and tools had to be flexible to accommodate the range of approaches resulting from the Frankensteinian merger of offices from around the world. At the same time, we wanted a product that could be proprietary to the firm.

In our efforts to define a methodology, we decided to boil our process down to three essential questions. User experience tasks and activities were aimed at answering these questions:

  • Who is the user?
  • How do they interact with the system?
  • Does the system work?

These questions gave us a framework that all offices could use to map their methodologies. Those offices that employed a “Discovery” phase could say that those activities mapped to the “Who is the user?” question. Offices using the Rational Unified Process could correlate those activities to these questions. We imagined that these questions could be asked in any order, in case a project called for a quick interaction design or for testing the usability of a legacy system. We imagined that the questions could be asked iteratively, to form increasingly lucid responses.

In hindsight, this approach appears too simple. Indeed, with the growth of the user experience field, I do not think our questions would have scaled to accommodate the complexity of either large systems or long-term projects. Either way, however, this approach allowed us to place our deliverables in context. Ultimately, a deliverable or document is only as valuable as the activity it supports.

To date this column has focused on how to make deliverables more effective, either through their content or through the tools to create them. For this issue, I would like to explore the relationship between deliverables and methodology. Unfortunately, this calls for a definition of IA methodology, which may challenge the definition of IA as the hardest question in our field.

To define methodology, I’ll look at activities and issues. These two components are not mutually exclusive. Activities describe what information architects do and issues are what they do it with.

The two activities of IA method
I have always thought of methodology, in these circles, as consisting of two activities: understanding the problem and solving the problem. Most “creative” methodologies are documented in this way, with a series of steps or phases leading up to a conception of the problem (creative brief, for example), followed by a series of steps or phases leading to the creation and implementation of a solution (one part of which may be a style guide).

For example, in the “old days” a design firm would be approached by a client who wanted a commerce-enabled website to sell patriotic ice cream flavors. (Alas, strange consumer goods abound in times of war.) This is a general statement of the problem. The firm would spend days or weeks (in the government, months) to elaborate on the problem: everything from the kinds of ice cream to the expected sales to the legal implications of potentially shipping ice cream across the country.

Ultimately, all this information contributes to the team’s overall understanding of the problem and sets the bar for the final product. Transitioning to problem-solving activities, the firm must make a series of decisions: the look of the homepage, the information collected at checkout, the way the website database hooks into the fulfillment vendor’s database. Each design decision is evaluated against the problem statement, and the firm must convince the client that the decisions they made effectively solve the problem. Ultimately, the distinction between understanding the problem and solving the problem comes down to the difference between What and How.

If you haven’t yet had a What and How conversation with any of your clients, it goes a little something like this:

Client: I want tabs across the top of my homepage, like my favorite site, [fill in high-profile ecommerce site here].

You: We can look at using tabs, but we first need to establish the main purpose of the site.

Client: Can the tabs be green?

You: Once we figure out the main navigation categories, we can make some decisions about how the page should look. But we can’t even figure out navigation categories until we understand the kinds of information you’d like to make available.

Client: We have a lot of information, but I only want one row of tabs.

You: [After writing down: “has lots of information.”] The issues you’re bringing up will help us describe HOW the site needs to look. We need to first understand WHAT the site needs to do. We can look at the HOW (the design of the pages) only after we establish the WHAT.

For “waterfall” methodologies–those that consist of phases occurring in a linear series–this framework meshes nicely. The first several phases are dedicated to understanding the problem, and the last several phases are dedicated to solving the problem. So-called “iterative” methodologies follow this structure as well, though they are composed of multiple conception-solution cycles. Each cycle tends to be limited in scope or time. Ultimately, having solved enough of the small problems, the iterative methodology will solve the larger problem.

The three issues of IA method
Distinguishing between these two main activities, however, is not enough. For each activity, the information architect must consider several issues. Each person may define these issues differently, but for the sake of simplicity, I’ll use business, users, and content as the primary issues information architects must address. In understanding the problem, the information architect must understand it from these three aspects.

Likewise, a solution must also address these three aspects. Any given system must have a business case, a marketing plan, and a content strategy. While information architects may be responsible only for the last of these, the aspects cannot exist independently of one another. (More often than not, IAs find themselves involved with all three.)

Where deliverables fit in
What I’ve presented is, no doubt, an oversimplification of methodology, but it provides a useful framework for considering deliverables. Any deliverable is serving one of two purposes: helping the design team understand the task, or documenting the solution itself.

In the first category of deliverables, a document may help set the context through business goals or user descriptions; or it may help put a stake in the ground with respect to scope by showing the breadth of the existing system. Documents in the second category capture the decisions made by the information architect–metadata for a content management system, structure of browse navigation, or a task flow for a checkout process.

At the same time, any given deliverable is addressing at least one of three issues: business, users, or content.

Business Users Content
Problem-Understanding
Problem-Solving

Considering deliverables in this framework leads to some interesting insights:

  • There is not necessarily a linear progression left-to-right. The three aspects are mutually exclusive but not independent of one another. Indeed, in order to come to a complete understanding of the business problem, one must also have a complete understanding of the user and content aspects of the problem.
  • There is not necessarily a linear progression up-and-down. In other words, having an understanding of the problem from the user aspect does not immediately imply that a solution from the user aspect will solve the problem.
  • Only a complete understanding of the problem, across all the issues, will lead to a complete solution. A good content solution is dependent on understanding all aspects of the problem. A single deliverable does not necessarily live in one, and only one, box. A single deliverable can capture multiple aspects across a single activity. A sitemap, for example, may indicate how different users can access the information.
  • BUT: a single deliverable should not attempt to both understand and solve the problem.

More on this last point: About a year ago, I did a concept model (a simple sitemap-like document showing the relationships between different concepts) for a client that described different “content types” for their organization. The client had never seen anything like it, nor had they attempted to define content types for the organization before. It’s easy to see how this could be part of the solution, and would fall into the second category of deliverables on the second row of the table above.

On the other hand, the deliverable did not describe how the ultimate solution would behave or look. It did not ask the client to do anything differently with their content. Its value, instead, was to help the team (both consultant and client) get their arms around the scope of content produced by the organization. Sometimes a good understanding of the problem masquerades as a solution.

Conclusion
Mapping deliverables to this methodology framework allows IAs to understand the purpose of their deliverables and clarify their role in evolving towards a solution. Admittedly the distinctions used here to describe methodology may be helpful for clients, but an oversimplification for professional information architects. On the other hand, even if your methodology includes more subtle distinctions in activities and issues, your deliverables must be geared toward getting closer to a solution. The deliverable may be the solution itself or a step in that direction. Understanding how your deliverables fit into the larger picture–by mapping them to a particular activity and issue–will make them more effective communications.

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.

IA Library Quick Reference: Special Deliverable #7

Written by: Dan Brown
“One look at my bookshelf and most innocent cube-visitors think, ‘This guy really spends a lot of money on books.’”By now you’ve acquired all the essential IA books for your bookshelf. I like having these books around because they make me feel important, and smarter than I really am. One look at my bookshelf and most innocent cube-visitors think, “This guy really spends a lot of money on books.”

A good professional book, besides making your bookshelf impressive, can:

  1. Offer a good brush-up on the basics
  2. Help put into words ideas you’ve had
  3. Suggest introductions for topics you’re not familiar with
  4. Provide alternate perspectives on topics you are familiar with
  5. Inspire

It’s this last reason that I like having these books around. Even when I’m not working on an information architecture problem, I like picking up Blueprints or Polar Bear and browsing through it. More often than not, I find something that gets my creative juices flowing.

On the other hand, it’s when I’m stuck on an IA problem that I really need these books to help me find a way out of it. And when I’m stuck on a problem, I hardly have time to kick my feet up on my desk and browse idly through. That’s where this issue’s Special Deliverable column comes in. In this column, you’ll find an overview of three IA books from a deliverables point of view. The purpose of this article is not to say whether one book is better than another, or even to comment on the overall quality of the books, but to provide a guide to what kind of deliverables information you can find in each book, and where.

The three books reviewed are:

Information Architecture: Blueprints for the Web. Christina Wodtke. New Riders, New York: 2002.

Information Architecture for the World Wide Web. Louis Rosenfeld and Peter Morville. O’Reilly and Associates, Boston: 2002.

Practical Information Architecture: A Hands-On Approach to Structuring Successful Web Sites. Eric L Reiss. Addison-Wesley, New York: 2000.

In the course of this article, I will abbreviate these references as Blueprints, Polar Bear, and Practical IA, respectively.

Author’s Disclaimer: Some of my work appears in Blueprints.

The three books represent a variety of attitudes toward deliverables, and these distinctions highlight that the product of information architecture is intangible. No book flat-out states that only “professional” or “formal” deliverables are preferable to informal ones. Of the three, however, Blueprints discusses documents that are geared toward thinking through problems and those geared toward communicating ideas to non-IAs. Practical IA offers almost no advice on the “formal” IA deliverable, but does suggest several pen-and-paper methods for thinking through ideas. In contrast, Polar Bear seems much more focused on formal documentation.

Only Polar Bear and Blueprints have full chapters dedicated to documentation. Practical IA does have a chapter entitled “Getting it down on paper,” but the intent of this chapter is not to demonstrate or explain formal deliverables.

Your preference on preparing “formal” or “client-ready” deliverables depends entirely on your working style, and the demands of your client.

Wireframes
All three books define wireframes similarly–as representations of a single screen or page–and acknowledge that they can “cross the line” between information architecture and visual design. Polar Bear has an entire section dedicated to wireframes (pp. 283-289) in its chapter on deliverables (chapter 13, pp. 270-304). Blueprints’ section on wireframes (pp. 284-289) also appears in its chapter on deliverables (chapter 9, pp. 246-290). Practical IA never goes beyond a brief definition in the glossary in the first chapter.

Blueprints dives right in and offers a crash course on building wireframes. The approach is terse, but includes several detailed examples. Blueprints also shows the final screen design that came out of the sample wireframes. For addressing the potential conflict with visual designers, Blueprints offers three suggestions. Blueprints Chapter 10 includes a case study which illustrates how a wireframe fits into the overall IA process.

Polar Bear offers a more detailed look at the definition of wireframes and spins them as architectural tools. By creating these scratch layouts, suggests Polar Bear, the IA can identify structural or navigation issues. Polar Bear also explains that wireframes can vary in fidelity, and presents low, medium, and high fidelity examples. (The examples in Blueprints, however, do a better job illustrating annotated wireframes.) Although Polar Bear does not offer any sort of troubleshooting or basic process for creating wireframes, it does list five guidelines for creating them.

None of the books go into any detail about how to use tools to create wireframes, so if you’re looking for tips on Visio, PowerPoint, or OmniGraffle, you’ll have to look elsewhere.

The table below summarizes the three books’ treatment of wireframes. For some topics, a book with an XX indicates that it is an exceptional source of information.

WIREFRAMES Blueprints
pp. 284-289
Polar Bear
pp. 283-289
Practical IA
p. 13
General Definition X XX X
Process for creating X
Examples XX X
Troubleshooting X
Tool how-to
Guidelines X
Pros and Cons X
Shown in context of IA process X (through case study) X

Site Maps
What Blueprints calls Site Maps, Polar Bear calls “blueprints,” and Practical IA calls “written outlines.” All three books offer comprehensive definition of this essential deliverable, but there are slight variations in each book. The practicing IA would do well to look at all three sources when preparing a sitemap.

Blueprints treats sitemaps (pp. 272-283) in its chapter on deliverables. While it spins sitemaps as a method for showing relationships between pages, Blueprints indicates that a sitemap can show other aspects of a website, including whether pages are static or dynamic. Blueprints discusses two main components of the sitemap: the layout and the “visual vocabulary.” For the layout, Blueprints offers four alternatives and provides simple examples of each. For visual vocabulary, Blueprints offers several typical shapes. The section on sitemaps concludes with three examples, meant to show the variation between the approaches of three information architects.

While Blueprints focuses on the layout-vocabulary distinction, Polar Bear distinguishes high-level from detailed blueprints. For high-level sitemaps (pp. 272-278), Polar Bear spells out the process for creating them, showing how the purpose of a high-level sitemap is to explain the abstract concepts that form the foundation of the information architecture. Although it does not provide a step-by-step approach, Polar Bear does walk through examples of high-level and detailed sitemaps (pp. 279-280). Since information architects face so many different scenarios, Polar Bear provides a nice array of examples. Polar Bear advocates simplicity in sitemaps (a point which I would do well to take) and offers strategies for keeping sitemaps in check.

Practical IA begins its section on “written outlines” (pp. 99-100) with: “A surprising amount can be accomplished using an ordinary word processor.” Ultimately, Practical IA advocates using an outline to begin the sitemapping process, but concludes that a diagram is preferable when presenting it.

Once again, none of the books offered any documentation on specific tools.

As controversial as wireframes are, the three books disagreed more on the purpose and implementation of sitemaps. Perhaps there is a tacit understanding in the IA community that sitemaps are “owned” by the information architect, which is why the controversy focuses on wireframes. With the community’s assumption about wireframes, however, comes the unfortunate side effect that none of the books address sitemaps’ pros or cons or typical pitfalls.

SITEMAPS Blueprints
pp. 272-283
Polar Bear
pp. 272-280
Practical IA
pp. 99-100
General Definition X X X
Process for creating X
Examples X XX X
Troubleshooting X
Tool how-to
Guidelines X
Pros and Cons X
Shown in context of IA process X (through case study) X X

Content Inventories
Each book has a different take on content inventories, although each uses them to get their arms around the domain of information. In Blueprints, a content inventory is a tool for analyzing each page of the site. On the other hand, Polar Bear uses content inventories to catalog the “chunks” as content gets migrated from one medium to your information architecture. The distinction is subtle, but does significantly alter the spin of content inventories in each section.

Blueprints calls content inventories the “single most painful job of information architecture.” (Also, a “Sisyphean task,” for those SAT word freaks.) As difficult as Blueprints’ introduction to Content Inventories makes them out to be, its advice for creating one (pp. 267-271) is pragmatic and helpful. The book describes a three-step process for creating content inventories and gives a nice example of a few rows from a content inventory spreadsheet.

Polar Bear combines its account of Content Inventories with content mapping–the process of reconciling the content inventory with an information architecture. Polar Bear’s account of content inventories is much more generous (no references to tragic Greek myths), but does not offer a process for understanding the scope and range of content. Within the context of content mapping, a content inventory is a “byproduct.”

With no specific deliverable to speak of, Practical IA nonetheless dedicates an entire chapter (pp. 31-40) to the process of cataloging content. The book offers ingenious ways of keeping track of countless pieces of information. Practical IA also explores methods for brainstorming content to flesh out the breadth and depth.

CONTENT INVENTORIES Blueprints
pp. 267-271
Polar Bear
pp. 289-293
Practical IA
pp. 31-40
General Definition X X X
Process for creating XX X
Examples X X X
Troubleshooting
Tool how-to
Guidelines X
Pros and Cons
Shown in context of IA process X

Other Highlights
From a deliverables perspective, each book has different strengths.

Blueprints includes several deliverables I had never even heard of, like Sitepath Diagramming (pp. 248-252), which is meant to show the relationship between a site’s users and its information architecture. Unlike most other documentation techniques, this approach includes users as a critical piece, which can help information architects ensure that they’ve addressed all user needs. Blueprints spins Sitepath Diagramming as a brainstorming technique, but turning it into a formal deliverable should be a fairly straightforward exercise.

Polar Bear is by far the most comprehensive, detailed account of information architecture available. Even the most advanced IAs will find something new in here. From a deliverables perspective, Polar Bear is strongest on client relationship issues. Whatever deliverable you are working on, Polar Bear offers explicit advice on how to explain and present it to clients. This book is useful for client relationships implicitly as well, by providing complete descriptions of the deliverables and their purpose in the IA process. Such language is begging to be referenced for those of us who get tongue-tied in front of clients.

The strength of Practical IA is in its simplicity. While it may not account for the depth of IA activities, it does show the breadth. It is the perfect book for lending to people new to the field. When your own deliverables become complex, Practical IA offers a common foundation for people generally unfamiliar with IA concepts.

Conclusion
If there is a single book that offers a comprehensive view of IA deliverables, complete with descriptions, samples, guidelines, and tool tips, it has not yet been written. (Given demand, we may never see such a volume on our shelves.) With these three staples in an IA’s library, however, no information architect should be lacking inspiration.

For the next column, Special Deliverables will look at the relationship between deliverables and IA methodologies.


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.