A visual vocabulary for describing information architecture and interaction design

I've had a nice exchange with Jesse James Garrett, author of an elegant article called A visual vocabulary for describing information architecture and interaction design.  and the forthcoming book The Elements of User Experience,  

Here's an excerpt from the article, followed by a little well-received axe-grinding and value-adding by me.

The article:

A visual vocabulary for describing information architecture and interaction design

version 1.1b (6 March 2002)

Jesse James Garrett
jjg@jjg.net

Table of Contents

1. Summary
2. Version history
3. Initial considerations
4. Conceptual underpinnings
5. Simple elements: pages, files, and stacks thereof
6. Creating relationships: connectors and arrows
7. All at once: concurrent sets
8. Breaking it up: continuation points
9. Commonalities: areas and iterative areas
10. Reusable components: flow areas and references
11. Basic concepts for conditional elements
12. Making choices: decision points
13. Pathfinding: conditional connectors and arrows
14. Multiple choice: conditional branches
15. Choose one or more: conditional selectors
16. One decision, many paths: clusters
17. Some restrictions may apply: conditional areas
18. Conclusion
19. Downloadable shape libraries

---

Summary

Diagrams are an essential tool for communicating information architecture and interaction design in Web development teams. This document discusses the considerations in development of such diagrams, outlines a basic symbology for diagramming information architecture and interaction design concepts, and provides guidelines for the use of these elements.

....

Initial Considerations

Some other key requirements of a visual vocabulary for information architecture and interaction design include:

• Whiteboard-compatible: The vocabulary should be simple enough that diagrams can be sketched quickly by hand. The elements of the vocabulary should be distinct enough from each other that moderately sloppy drawing cannot compromise the clarity of the diagram.
• Tool-independent: The vocabulary should be designed so that specialized software tools are not required in order to construct diagrams. The vocabulary should not favor the use of any particular software tool, but should instead enable architects to work with the tools they are most comfortable using.
• Small and self-contained: Because the diagrams are used by a diverse range of audiences with differing levels of knowledge of (or even interest in) diagramming systems used in other areas of technical development, the vocabulary should not require such knowledge or interest. The total set of elements should be kept as small as possible, maintaining a strict one-to-one correlation between concepts and symbols, so that the vocabulary can be learned and applied quickly. The concepts expressed by a diagram may be arbitrarily complex; the means of their expression should not be.

[full article at  A visual vocabulary for describing information ]

-----Original Message-----
From: Jon Schull [mailto:schull@softlock.com]
Sent: Wednesday, June 12, 2002 2:35 PM
To: jjg@jjg.net
Subject: visual vocabulary; alternatives to simple boxes and lines

Your admirable work on visual vocabularyies at http://www.jjg.net/ia/visvocab/inspired me to test some ideas of my own, as expressed in a recent note I sent to BoxesAndArrows and posted on my weblog at http://radio.weblogs.com/0104369/2002/06/05.html

 

Have you examined the assumption that boxes and arrows are appropriate to the task?  They come from an age of pens and rulers.

 

 

 

(That was the note to which Jesse replied...
There are certainly some interesting ideas here; I'm not sure how practical
such an approach would be for sketching out architectures, but I could
definitely see it having some benefit as a visualization tool..)

 

Now less radically, and consistent with your essay's "initial considerations" I'd suggest that elbow connectors unfortunately can define spurious spaces.   Curved lines with bigger arrowheads can make a real difference, as in Image 3 derived from your sample diagram.

 

There are certainly some interesting ideas here; I'm not sure how practical
such an approach would be for sketching out architectures, but I could
definitely see it having some benefit as a visualization tool. --jjg

Secondly (and admitting that this violates your (whiteboard consideration) Image 4 shows that shading can do a good job of turning visually independent parts into the intended whole (as with your continuation points), and also help differentiatiate figure and ground. 

 

Right again. I have actually been using shading (though not quite in this
way) in my own work, but as you point out, the whiteboard consideration
really rules out such techniques as part of the core system.

My expectation when I released the vocabulary was that people would adapt it
as they saw fit. The system is really intended just as a starting point;
these kinds of flourishes, as long as they enhance and do not detract from
the effectiveness of the diagrams as communication tools, are not at all
contrary to the spirit of the vocabulary--jjg.

I think the figure on the right is less busy and more illuminating because it demands less of the reader. 

...

P.S.  The shape library you included in the powerpoint file also works in Excel, whose arbitrary canvas-size and multiple tabbed windows can be very useful.

 

Good to know! I should have guessed as much.
Thanks for your thought-provoking comments. --jjg

 

© Copyright 2002 Jon Schull. Last update: 12/18/2002; 2:15:22 PM.