By Joe Elmendorf

We make information architecture models to help us expose what is true about a situation in a way that eases expression, learning, and discussion, which enables clearer words on pages, conversations in meetings, and understanding in our heads. We make models because they let us better understand what is meant and get at the right kinds of conversations: the kinds of conversations that expose what something should be before getting into how it should be. We make these models because we need to make sense.

But, of course, the way information architecture tends to work is that the structures are fractal. The sensible way to structure a project also turns out to be the sensible way to structure an activity also turns out to be the sensible way to structure an artifact.

What applies to the large scale—an entire project—often can be applied all the way down to the minuscule—a single step, process, or artifact.

We can make good complex systems by figuring out what to make before figuring out how to make it. By that same principle, we can make good models by figuring out what to model before figuring out how to model it.

So how do we talk about what to model before we go about modeling?

We tend to start talking about models by the kind of model. We ask: “What kind of model should I make?”

There are so many different kinds, so many different types, so many different models with unique forms and implied outcomes. But all of these kinds of models are examples of how:

• How to create documentation of an interface for developers.

• How to document page relationships for navigation menus.

• How to show our users.

• How to show the breakdown across a lifecycle.

Their stereotypical forms tell you “how they should be,” and “how they should be” implies what the models can be used for. It’s a backwards way of getting to something useful and it can hamstring the process and outcomes.

How you do anything is how you do everything

Perhaps you see the problem; if the way to make something make sense stems from figuring out what before figuring out how, we shouldn’t be starting the modeling process with a how as expressed in a typical modeling form—we need the what to happen before the how, even with something as minuscule as a single model.

In order to talk about models without talking about the how of creating models, we need to talk about them in terms of what we intend for their use.

For the 2019 IA Conference in Orlando, I presented a poster where I introduced this concept of describing a model not based on what it will look like, but on a combination of:

1. Your intent for that model

2. What aspects of a thing the model will focus on

3. What level of abstraction your model will use.

What You Intend

Why are you bothering to create a model? What are you trying to learn? What questions do you have? What do you know, that you suspect others might not? What would happen (or continue to happen) if you didn’t make this model?

A model-maker’s intent doesn’t need to be complicated, it just needs to be stated; it can evolve over time, but having a stated intent serves as a north star. If you aren’t clear about why you want to make a model, you’re not going to be able to create a useful model.

Aspects of a Thing

All Things have many aspects about them that can (and should) be considered.

There are environmental forces that act upon the Thing. While outside of the Thing itself, they are an important, if not critical, aspect of the Thing. Stakeholder Intent, User Behavior, User Needs, and Ecosystem/Environmental aspects are all forces acting upon the Thing.

In addition to environmental forces, there are also facets and attributes of the Thing itself. These are the parts that would still be true if that Thing were in a void. The System/Concept, Structure, Interface, Interaction, and Object are all facets of a Thing which exist as different levels of granularity.

There are many different aspects of a thing that can be considered, but in order to make a clear model, only a few aspects can be considered at any one time. Which ones will this model focus on? Which aspects need to be shown together to tell the story you’re wanting to tell? What kinds of information need to be present (or absent) to facilitate the kinds of conversations you want to have?

Level of Abstraction

All models are an abstraction of something outside of themselves. If you have a whiteboard marker and you take a picture of it, the picture of the whiteboard marker is not the whiteboard marker, it’s a very low-abstraction model of what a whiteboard marker looks like.

If you took that same whiteboard marker, you could use that physical object as a model to talk about the limited human perception of time and alternative planes of reality and existence outside of our common experience of time. That whiteboard marker would become a highly-abstract model in that explanation.

Each of those models could be perfectly well suited to a particular task, depending on the task and the kinds of conversations you wanted to have. A photograph of a whiteboard marker is a good model for showing what a particular marker looks like, but it’s a bad model for showing how that marker works. A sketch of a whiteboard marker in its context might be less helpful for showing what it looks like, but more helpful for showing what it does or how it works.

Knowing what kinds of conversations you want to have or facilitate using this model (going back to what your intent was) will help inform what level of abstraction to pursue.

Bringing them together

With a clear articulation of your intent, which aspects, and level of abstraction, you can talk about a model that you haven’t yet created without talking about what it will look like. Being able to talk about what you are modeling before figuring out how to model will not only focus alignment with collaborators, but also provides a clear picture and justification of what you’re spending your time on to those who write the checks without prematurely committing to a form.

I might call the model described in this example a “User Model.” Depending on what these particular users’ needs and behaviors are like, the finished model might look like personas, or it might look more like a journey, or it might look like something different; but as the model-maker, I now have the freedom to design the form to best fit what is true about this particular information.

An Aside About the Typical Forms

I don’t want to diminish the modeling “hows” that I’ve outlined here too much. These forms are very important and should become a part of every sense-maker’s library of different ways to show relationships of information. However, they shouldn’t be the starting point. In order to make models that have a good fit with their context and fit their intended purpose we need to figure out what we’re modeling before we figure out how to model it.

What’s Next

I invite you to use this three-pronged method for describing your models before you make them. My hope is that you’ll discover how helpful an initial framing like this can be.

If you’re still not so sure about how to apply this or would like some help developing your modeling practice, sign up for one of our recurring workshops, Modeling for Clarity.