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!