Summary: How do we use models to make IA deliverables that are "built to last"? Daniel O'Neil covers two major concepts: audience and context selection.

The most important goal of any deliverable is to convey understanding. In many contexts, good models can do a lot of this work. The challenge is not creating models; we live in a world with models aplenty. Yet they are so often not used well, or don’t have the impact we desired.

At TUG we think that good model selection has two major components:

1) A model must be appropriate to the audience.
2) A model must be conceptually concise.

Matching the Model to Your Audience’s Context

Model selection depends on getting to the core questions that any given stakeholder is going to ask throughout the life of a project.

We find that executive stakeholders, for example, are interested in meaning or value. Most requirements analysts and software developers, in contrast, are very interested in the temporal or sequential aspects of a system, whereas data and system architects will be most interested in the relational organization of a system. User Experience team members will be concerned with all three but do tend to lean toward positional designs like wireframes or screen design specs.

In our experience, these stakeholder needs for information fall into four major contexts:

• Temporal/sequential

• Semantic (meaning/value)

• Relational

• Positional

Figuring out which context is important, and whom it serves, is critical to getting acceptance of a deliverable.

Model Concision

Models tend to break down to a single context from the four described above. For example, Unified Modeling Language (or UML, an industry standard for software requirements) firmly relies on single-context diagrams for almost all models.

UML Sequence Diagram

Most traditional IA diagrams, most notably sitemaps (relational) or wireframes (positional), are also single-context.

Stanford University Site Map

Why are models so often single-context? Well, we think they have emerged as standards because they’re ones that actually work. With very rare exceptions, any model can succeed in explaining *one* context well, and possibly two, but will almost certainly fail to do all three at the same time.

Tying It All Together

Consider, for example, two different “deliverables”: The first is the evolution of the map structure for the Tokyo Subway, the other from the 1955 Proposal for the Eisenhower Highway System.

Two things are noteworthy about the Japanese model. First, it is a exploration of relational data, but not positional data (i.e., the geographic locations of each station).

Relational Model of Tokyo Subway

The map is a dramatic simplification of the original subway map that tries to include both wayfinding and location in space.

Positional Model of the Tokyo Subway

The success of the first map shows that subway goers, as an audience, are more concerned about which station they want to reach, not its location in space.

In contrast, the Eisenhower highway system model contains largely positional data; that is, a description of WHERE the highways proposed are going to be in the continental United States. Given the important broad consensus needed to develop this system, having all the stakeholders be able to grasp the model in terms of the geographic regions involved was critical for its understanding.

Positional Model, Interstate Highway System

Note that both maps include a hint of additional information in another context. For the Japanese subway map, it is positional through the location of the Imperial Palace, a key landmark in Tokyo. For the highway system, it is semantic information in the title of the map—“National System of Interstate and Defense Highways”—and in the metropolitan areas circled as “served”. The “defense” title is critically important for understanding why the highways terminate in unpopulated locales like Northern Maine, whereas the circles give core stakeholders a nod that their cities will be considered when the highway is built.

These are not casual decisions; in both of these examples, the architect had a very strong idea about what the image was going to serve, and an awareness of the limits of any design. Mapping stakeholder needs to important contexts for any given model will give them durability and support, as well as making them easier to defend and explain.

So think about your contexts, and your audience! In future blog posts we’ll talk about how the discovery process can be used to imbue final deliverables with more support and understanding, and how to link diverse contexts into single, larger meta-models.