jjg.net

information architecture=20 =BB

Looking for more? My book The Elements of User = Experience=20 puts information architecture and interaction design in context for = beginners=20 and experts alike. You can now o= rder the=20 book from Amazon.com.

A visual vocabulary
for describing information architecture and=20 interaction design

version 1.1b (6 March 2002)

Jesse James Garrett
(contact)

Translations of this document are available:

Chinese (thanks = to Arky Tan)=20
Japanese = (thanks to=20 Atsushi Hasegawa)=20
Russian = (thanks=20 to Philipp Chudinov)=20
Spanish (thanks = to Javier Velasco)=20
Italian (thanks = to Laura Caprio and = Beatrice=20 Ghiglione)=20
French = (thanks to=20 Francois Lamotte)=20
German = (thanks to=20 Marcus Brinckhoff)=20
Portuguese=20 (thanks to Livia Labate and = Laura Cretton=20 Lessa)

Summary

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

Version history

1.1b (6 Mar 2002)=20: Information on=20 built-in support in OmnGraffle 2.0=20; New shape = library=20 for iGrafx Flowcharter=20
1.1a (17 Sep 2001)=20: New shape = libraries=20 for Macromedia FreeHand=20; Posted cheat = sheet and=20 PDF shape template=20
1.1 (31 Jan 2001)=20: Added the filestack=20 element=20; Added the conditional=20 selector element=20; Modified the arrow=20 element to allow multiple arrowheads=20; Modified the cluster=20 element's behavior so that it now appears only downstream from a = conditional=20 branch or selector=20; Modified the conditional=20 branch element's behavior to allow for a null result=20; Numerous improvements to the shape libraries=20; New shape = library=20 for Adobe InDesign=20
1.0 (17 Oct 2000)=20: Initial release

Initial considerations

A visual vocabulary is a set of symbols used to describe something = (usually a=20 system, structure, or process). The vocabulary described here may be = used by an=20 information architect or interaction designer to describe, at a high = level, the=20 structure and/or flow of the user experience of a Web site.

These descriptions, or diagrams, are used by five primary audiences: =

Project sponsors and managers use them to obtain = a=20 general sense of the scope and form of the project.=20
Content producers use them to derive content=20 requirements.=20
Visual and interface designers use them to derive = a count=20 of how many unique page designs must be produced, and to obtain an = initial=20 sense of the navigational and interface requirements for these = designs.=20
Technologists use them to derive functional = requirements.=20
Information architects and interaction designers = use them=20 to develop detailed navigational and interface requirements for each = page.=20

Every one of these audiences (with the exception of sponsors) needs a = great=20 deal of detail to do their jobs. The trouble is that the detail each = audience=20 requires differs vastly from the detail required by others, and the bulk = of this=20 detail is irrelevant to the needs of other audiences.

The sensible approach is to limit the detail in the diagram to that = which can=20 be usefully applied by all audiences. The diagram thereby serves as a = touchstone=20 document for the development of more detailed documents specific to the = needs of=20 each audience.

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

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

Conceptual underpinnings

Information architecture and interaction design are two sides of the = same=20 coin. (See "The Elements = of User=20 Experience" for definitions of these terms as they are used here.) = Diagrams=20 of contemporary sites inevitably involve both sides. But for each, the=20 objectives of the diagram are slightly different.

In both cases, the diagram focuses on what we call=20 macrostructure, providing just enough detail to enable = team=20 members to get the "big picture". The task of the architect is to = determine the=20 appropriate level of detail to meet this objective. The specific = page-level=20 detail, or microstructure, is detailed in other = documents that=20 the architect may not be primarily responsible for developing.

When describing information architecture, the diagram should = emphasize=20 conceptual structure and organization of content. Note that conceptual = structure=20 is not the same as navigational structure. The objective of the = information=20 architecture diagram is not to provide a full-blown navigational = specification;=20 this level of detail is best kept in other documents, where it is less = likely to=20 confuse and distract.

When describing interaction design, the diagram should emphasize how = the user=20 flows through defined tasks, and what the discrete steps are within = these tasks.=20 As with navigation, details of interface should not appear in the = diagram -- if=20 you find yourself drawing buttons and fields, you're probably loading = the=20 diagram down with excess detail.

This vocabulary is based on a simple conceptual model encompassing = both=20 information architecture and interaction design:

The system presents the user with paths.=20
The user moves along these paths through actions. =
These actions then cause the system to generate = results.=20

Simple elements: pages, files, and stacks = thereof

The basic unit of user experience on the Web is, of course, the=20 page, which we represent as a simple rectangle. Note = that the=20 page is a unit of presentation, not (necessarily) a unit of=20 implementation -- one page in your diagram may correspond to multiple = HTML files=20 (as in a frameset interface) or multiple units of code (as in a = server-side=20 include or database-driven implementation).

In addition to pages, there are also files, parcels = of data=20 without navigational properties. Files are delivered to the user for use = outside=20 a Web browser environment (such as audio or video files, stand-alone = documents=20 like PDFs, or executables). For these, we use our old friend the = dog-eared=20 document icon.

3D"illustration =20
Figure 1a: [left] The page and the = file=20
Figure 1b: [right] The pagestack and the=20 filestack

Use a pagestack to indicate a group of functionally=20 identical pages whose navigational properties are immaterial to the=20 macrostructure of the site. Similarly, a filestack = represents a=20 group of files that receive identical navigational treatment and can be=20 classified as a single entity (such as a collection of downloadable = games or a=20 library of PDF instruction manuals).

We use labels on pages and files to identify them. = These=20 don't need to correlate to actual designations such as HTML = <TITLE>=20 elements or filenames, but they do need to be unique for each page or = file in=20 the diagram. Unique numeric identifiers and type designations also = provide a=20 good way to keep track of all the pages and files in your diagram.

Creating relationships: connectors and = arrows

Relationships between elements are depicted with simple lines or=20 connectors. These conceptual relationships will = inevitably=20 translate into navigational relationships -- but not all navigational=20 relationships will appear in the diagram.

In the case of information architecture, these relationships are = commonly=20 reflected through a hierarchical organization of pages into trees. = However, this=20 is by no means required or even (in some cases) recommended.

3D"illustration =20
Figure 2a: [left] A simple tree = structure=20
Figure 2b: [right] The same structure as = in 2a,=20 diagrammed differently

When diagramming interaction design, our connectors also need to = convey=20 directionality to indicate how the user will move = through the=20 system toward completion of a particular task. Turning our connectors = into=20 arrows will do the trick nicely. We use the terms=20 downstream and upstream to refer to = the=20 position of elements relative to this forward movement.

Note that these arrows are not like the arrows indicating a one-way = street,=20 but rather like the arrows indicating the way to the food court in the = mall. The=20 user is not prohibited from moving in the opposite direction; the arrow = merely=20 indicates the direction in which the user is likely to want to go.

3D"illustration =20
Figure 3a: [top left] Arrow = indicates=20 downstream movement toward task completion
Figure = 3b:=20 [bottom left] Crossbar indicates upstream movement is not = permitted=20
Figure 3c: [right] Multiple arrowheads = clarify=20 directionality

If for some reason we want to prohibit this upstream movement (such = as in=20 cases where some irreversible action like deleting a record has taken = place), we=20 use a crossbar (just a short perpendicular line) on the = opposite end of the arrow to indicate this.

In some cases, it may be necessary to place an additional arrowhead = near the=20 upstream page to clarify the directionality of the flow in a more = complex=20 architecture. (A practical note: Many diagramming applications do not = allow the=20 user to string arrows together in this fashion. To work around this, the = shape libraries = include a=20 "gluedot" element, an invisible element consisting of a single = connection point.=20 Use this element to connect arrows together.)

Connectors and arrows can also be labeled, but the use of these = should be=20 limited to cases in which the action taken by the user needs to be = clarified. If=20 the labels become long and unwieldy and start to clutter the diagram, = point the=20 reader toward a footnote or appendix entry.

In the examples given throughout this document, footnote or = appendix=20 references will appear as a number and letter combination in=20 parentheses. Numbers refer to the diagram page on which the reference = appears;=20 letters refer to the specific note. For example, the first note on page = 3 of a=20 diagram would be referenced as (3a), the second (3b), and so forth.

3D"illustration =20
Figure 4a: [left] A superfluous = label=20
Figure 4b: [middle] A useful label=20
Figure 4c: [right] A footnote or appendix=20 reference

All at once: concurrent sets

A concurrent set (represented by the half-circle) is = used in=20 cases where a user action generates multiple, simultaneous results (such = as=20 spawning a pop-up window at the same time a page is loaded in the main = window,=20 or displaying a page while a file is being downloaded).

3D"illustration =20
Figure 5: A concurrent set

Like arrows, concurrent sets are directional. Upstream elements = connect to=20 the curved side; downstream elements connect to the flat side.

Breaking it up: continuation points

Information architects often find themselves yearning for ever-larger = sheets=20 of paper on which to diagram their work. But even if large-format output = devices=20 such as plotters were widely available, some architectures are simply = too=20 complex to capture in a single, all-encompassing diagram.

To allow us to separate our diagrams into easily digestible sections, = we use=20 continuation points (square brackets) to bridge the = gaps=20 between pages.

3D"illustration =20
Figure 6a: [left] A "continue to" = point=20 refers the reader to another diagram
Figure 6b:=20 [right] A "continue from" point, picking up where 6a left off=20

A single continuation point may list one or more sources or = destinations as=20 needed. The orientation of the brackets (horizontal or vertical) carries = no=20 particular meaning; the choice of orientation is a matter of the = architect's=20 aesthetic judgment.

Commonalities: areas and iterative areas

The area element (a rounded-corner rectangle) is = used to=20 identify a group of pages that share one or more common attributes (such = as=20 appearing in a pop-up window, or having some unique design treatment). = Use=20 labels to identify these attributes or (as with connectors), refer to = notes=20 elsewhere in the document if you have a lot to say.

3D"illustration =20
Figure 7: An example use of an area to = represent a=20 pop-up window

Many architectures involve repeating the same basic structure as it = is=20 applied to a number of functionally identical information elements. For = example,=20 you may have a product catalog in which each product has a number of = pages=20 associated with it. You could draw an instance of this structure for = each=20 product, but why waste your time? Just use an iterative = area --=20 a stack of rounded-corner rectangles -- instead.

3D"illustration =20
Figure 8: An example use of an iterative = area to=20 represent a repeated structure in a product catalog

Note that connectors and arrows don't actually point to the areas = themselves.=20 The area elements serve only to enclose the pages. Areas should be = applied=20 carefully -- it's very easy to get caught up capturing all kinds of = details with=20 area elements that don't manifest in the user experience (such as which = pages=20 are hosted on which servers) or otherwise interfere with the diagram's = overall=20 objective of communicating the macrostructure.

Reusable components: flow areas and = references

Some interaction designs require a sequence of steps (like a login = procedure,=20 for instance) to appear repeatedly in different contexts throughout the = design.=20 Often these sequences are merely a component of one or more larger tasks = the=20 user is trying to accomplish. (This is analogous to the concept of a = subroutine=20 in computer programming.)

Such a reusable sequence is called a flow, and it is = represented in the diagram through two elements: the flow = area,=20 which encloses the flow itself; and the flow reference, = which=20 serves as a sort of "placeholder" for the flow in every context in which = it is=20 repeated. Both elements have the same basic shape, a rectangle with the = corners=20 clipped off (or, if you prefer, a distorted octagon).

3D"illustration =20
Figure 9a: [left] A flow reference = serves=20 as both a "continue to" point and a "continue from" point =
Figure=20 9b: [right] The flow area referenced in 9a =

Flow areas also require the use of two special types of continuation points:=20 entry points and exit points. These = are placed=20 outside the flow area, while continuation points within the flow area = indicate=20 that the flow spans multiple diagrams.

Flow references themselves function very much like continuation = points. The=20 objective of both types of elements is the same: to allow the architect = to break=20 up the diagram across pages. The difference is that a flow reference can = serve=20 in both the "continue to" and "continue from" capacities, while a = continuation=20 point can only be one or the other. If you don't need an element to play = both=20 roles, you probably don't need to use a flow.

Basic concepts for conditional = elements

With increasing frequency, information architectures and interaction = designs=20 are reshaped dynamically by the system as the user moves through the = site. This=20 reshaping is accomplished by means of conditional = logic, and=20 the remaining elements of this vocabulary are specific to conditional = logic=20 structures. Here's a basic conceptual model for application of = conditional=20 elements:

The system keeps track of one or more attributes. = These=20 attributes may be particular to:=20
- the user (such as user type)=20
- the session (such as login status)=20
- the content being accessed (such as subject matter)=20
- or they may exist "in the world" (such as the time or date). =
Attributes have values ("3 p.m." is one possible = value=20 for "time of day").=20
The association of an attribute with a particular value is called = a=20 condition.=20
Conditions are evaluated by the system to = determine if=20 they are true.

In a static architecture, every path is presented to every user under = every=20 circumstance, and each path always leads to the same result. In a = dynamic=20 architecture, the system decides which paths or results are presented to = the=20 user based upon evaluating one or more conditions.

To minimize clutter in our diagrams, these conditions are typically = described=20 in a footnote or appendix entry accompanying the diagram.

Making choices: decision points

When one user action may generate one of a number of results, the = system must=20 make a decision about which result is to be presented. (Perhaps the most = common=20 example of this is error handling on form submission.) We call this a=20 decision point, and as in traditional flow charts, it = is=20 represented by a diamond.

3D"illustration =20
Figure 10: An example use of a decision = point in a=20 login sequence

Note that arrows must be used in conjunction with decision = points to=20 clarify whether associated elements are upstream or downstream from the = decision=20 point.

Pathfinding: conditional connectors and = arrows

A conditional connector (represented by a dashed = line) is=20 used when a path may or may not be presented to the user depending upon = whether=20 one or more conditions are met.

3D"illustration =20
Figure 11a: [left] A conditional = connector=20
Figure 11b: [right] A conditional arrow=20

For example, there may be a page containing sensitive information = that only=20 company employees should have access to. The condition in this case = would be the=20 user type (employee); if the condition is met, the path is made = available. If=20 not, no path exists.

Multiple choice: conditional branches

When the system must select one path among a number of mutually = exclusive=20 options to be presented to the user, we use a conditional=20 branch (triangle). Upstream elements connect to one point of = the=20 triangle; downstream elements connect to the opposite side.

3D"illustration =20
Figure 12: A conditional branch

The example shown in figure 12 looks a lot like the decision point = example=20 above in figure = 10, but=20 the behavior described here is quite different. In the decision point = example,=20 only one path (or navigational element) was presented to the user; where = that=20 path took the user was dependent upon certain conditions.

In figure 12, the system is making a similar decision, but it happens = before the user action. The conditional branch indicates that = the=20 system is deciding which path will be presented to the user. The paths = from page=20 A to pages B, C, and D are mutually exclusive; for example, if a path to = B=20 exists, paths to C and D do not.

As with conditional=20 connectors and arrows, a conditional branch may provide the user = with no=20 path at all (a null result). The difference here is = that with a=20 conditional branch a null result may not be permitted at all; and if it = is=20 permitted, it is one of three or more possible results. Indicate whether = the=20 branch permits a null result in your footnote or appendix entry.

Choose one or more: conditional = selectors

The conditional selector element (represented by a=20 trapezoid) functions much like the conditional branch, = with one=20 important difference: with the selector, the various downstream paths = are=20 not mutually exclusive. any number of the paths that fulfill = the=20 condition(s) may be presented to the user.

3D"illustration =20
Figure 13: A conditional selector =

The most common application of the conditional selector is in results = generated by a search engine. In this case, the search results page = would appear=20 upstream from the selector; the condition is the search criteria input = by the=20 user; the downstream paths would lead to the content pages indexed by = the search=20 engine. As with a conditional branch, a conditional selector may = generate a null=20 result -- in fact, this is far more common with a selector than with a = branch.=20

One decision, many paths: clusters

Some conditional structures require that the system present more than = one=20 path based upon certain conditions. We associate these paths together in = the=20 structure with a cluster (represented by a circle). The = cluster=20 can appear downstream from either a conditional branch or a conditional=20 selector.

3D"illustration =20
Figure 14: A cluster downstream from a = branch=20

The structure illustrated in Figure 14 functions pretty much like a = normal=20 conditional branch, but for one condition we are presenting more than = one path=20 to the user. So if the attribute being evaluated has value x, = the user=20 sees a path to page B; but if the attribute has value y, the = user sees=20 paths to both page C and page D.

Some restrictions may apply: conditional = areas

When one or more conditions applies to a group of pages, those pages = are=20 enclosed within a conditional area -- a rounded-corner=20 rectangle like a standard area, but with the dashed-line treatment of a=20 conditional connector.

3D"illustration =20
Figure 15: An example use of a conditional = area=20 where a secure connection is required

Conditional areas are applied most commonly in situations involving = access=20 permissions, such as when a valid login or encrypted (SSL) connection is = required. Unlike the other=20 types of areas, conditional areas are associated with a result, = which is=20 generated in the event that the condition(s) are not fulfilled.

Conclusion

If you'd like to see how the whole system comes together, here's a sample = diagram=20 of the information architecture and interaction design of MetaFilter. (I wasn't involved = in the=20 development of this site; this diagram was simply reverse-engineered = from it.)=20

Eric Turner's qui= ck=20 reference guide is an easy one-page description of all the elements. = And=20 Scott Larson created t= his handy=20 cheatsheet for quick reference to the various conditional elements. = And for=20 those interested in creating their own shape libraries for use with an=20 application other than the ones below, here's a PDF of all = the=20 shapes (thanks to Ross Olson for the suggestion).

This vocabulary necessarily represents only a first step. As = information=20 architecture and interaction design for the Web continue to evolve, = situations=20 will inevitably arise that this vocabulary does not address. Your feedback and recommendations = for the next=20 revision of this vocabulary are welcome.

Downloadable shape libraries

OmniGraffle for Mac OS X is the first application to = ship=20 with built-in support for the visual vocabulary. OmniGraffle is = currently pre-installed = on all=20 Apple Power Macs and PowerBooks. It can also be downloaded from=20 the Omni site.

PocketDraw 2.0 for the PocketPC includes a built-in = visual=20 vocabulary palette for the information architect on the go. You can see = examples=20 at the PocketDraw site or on = Mi= ke Lee's=20 weblog.

Other shape libraries available:

St= encil=20 file for Visio 2000=20
Stenc= il file=20 for Visio 5=20
Stenc= il file=20 for Visio 4=20
PowerPoi= nt=20 file=20
Libra= ry file=20 for Adobe InDesign 2.x (thanks Andrew Robinson)=20
Library= =20 file for Adobe InDesign 1.x=20
Library= =20 file for FreeHand 10 (thanks Andrew Crow)=20
Library = file for FreeHand 9 (thanks Andrew Crow)=20
Illust= rator=20 EPS file=20
Library = file for iGrafx Flowcharter 2000 (thanks Andrew Robinson)=20
Library = file for OpenOffice (thanks Nelson Rodriguez-Pe=F1a)=20
Collecti= on of=20 EPS files containing one element per file, suitable for import = into other=20 applications (1.1 MB)=20
Two different SVG libraries: [1] = (1.9=20 MB) [2]= =20 (52 KB; thanks to Marcus Brinkhoff)

=A9 2000-2002 Jesse James Garrett
This document: = http://www.jjg.net/ia/visvocab/<= /A>=20
More IA resources: http://www.jjg.net/ia/

jjg.net

A visual vocabulary for describing information architecture and=20 interaction design

Table of Contents

A visual vocabulary
for describing information architecture and=20 interaction design