Summary: Information architect Joe Elmendorf presents at the 2014 IA Summit about using information models to improve your understanding of complex systems.
Joe originally presented these slides at the IA Summit in San Diego.
Modeling for Clarity – IA Summit 2014 from josepilove
A few months ago, I sat down for breakfast with my year-and-a-half-old daughter, Eden, and she pointed at and said “banana,” one of the few words she knew at the time. Foolishly, I thought she wanted to eat a banana, so I got a banana and started peeling it. To my—and apparently her—horror, she started shrieking and saying “No! No! No!” After a brief pause of bewilderment, I got another banana and handed it to her un-peeled, and she proceeded to hold it up her ear and say, “Hello? Mimi?” She didn’t have the words to tell me she wanted to call her Grandma, so she used what she did know to communicate her desire.
While her verbal skills have vastly improved over the past couple months, she is still figuring out this language thing and uses iconic things to model her desire. It’s intuitive for us humans to use symbolic representations, or models, to help us articulate meaning when we don’t yet have the right words, we’ve been doing it all of our lives.
Modeling is my favorite tool for understanding a problem. I’ve found it to be very useful, so I’m going to share with you what I’ve learned along the way. First, like a good information architect, I’d like to be clear about what I mean when I say model. What I mean is a visual model, as opposed to a statistical model. And by “visual model,” I mean, in essence, “a picture, based on reality.” And when I say “reality,” I mean, what is true about a system or situation.
Pictures are pretty cool; they’re a foundational part of how we learn and they help us keep track of what is true so that we can better understand what we’re dealing with. We learn best when we are able to combine some linguistic and some non-linguistic interaction with new information. This is why the formal contextual design process involves interviews and note-taking, as well as dedicated time to sketch out what you’ve learned on paper. We can better understand complicated workflows and business processes if we are able to learn about them linguistically—being told verbally or in writing—and then take time to work out the relational implications of what we’ve been told in a spatial, visual medium.
We can only learn something if we have a clear path to it from what we already understand, which is why asking questions is another critical part of how we learn. We are able to build out from what we already understand by asking clarifying questions in an iterative cycle until we understand the whole. But it can quickly become hard to keep track of all the pieces you have unless you have a good system for it. A model is a documentation system that allows us to record and articulate our thoughts before we’re able to use the right words. And this is really nice, especially when you don’t really know much yet about the stuff you’re trying to document. (Not that any of us find ourselves in that situation ever.)
We can see examples of pictures being used for learning and models as documentations systems manifest all over our world. We’re all familiar with that strange devilry known as IKEA. I won’t get started on the phenomenon of that store, but I will say that the instructions they put out are fantastic. IKEA instructions are a documentation system that allows for a shallow understanding of what can be fairly complex furniture systems. A wiring diagram is another example of a way we visually document a very complex electrical system. And we document it so that its complexity can be better understood, not so that it can be reduced.
Time planning and tracking seems like it’s a constant pursuit. While I cannot take credit for this original idea, I’ve adopted the use of Legos to model my time allocation for particularly complicated weeks. For this particular scenario, it was more important that know how much of my time to spend per day on a project than what times of day to spend on which project, what a traditional calendar affords.
I mentioned contextual design before and it’s a great example of a place where we are using models to help increase the clarity around a system, but my goal for all of us is to break the use of clarifying models out of this formal process and open them up for use in our everyday lives because at the heart of what we all do—UX, IxD, IA, whatever—we’re all trying to move from some state of not knowing to a state of knowing.
Top Three Reasons to Use Modeling
Now, let’s talk about where the rubber meets the road: I like to model…a lot. It gets all over the place. (Remember the calendar?) So here are the top three reasons why I incorporate this process of modeling into my workflow:
Modeling helps you ask better questions. By showing you what you already know, a model can help you see where the gaps in your knowledge are and where you need to find more clarity.
Modeling helps you measure completeness. How do you know when you know enough? I’m convinced there is always something more one can learn about anything, but from a practical stand-point, there needs to be an “end.” Again, by showing what you already understand (or even think you might understand, or have even encountered), you can identify what needs to be filled in before your initial understanding is complete and ready for validation.
Modeling helps you articulate your understanding. You can draw how this one thing relates to this other thing way before you can speak clearly about it. Additionally, when it comes time to talk to others, models are a highly discussable medium, which helps to level-set a shared understanding.
I am going to share four models I’ve been involved with creating and how each has been useful. This is a model documenting several process flows for a single department in an organization; it’s kind of a bastardized Business Process Diagram mainly because I didn’t want to worry about following those rules. Instead I was focused on creating something that could make this complex system clearer.
[See slide 20] This model helped my team know when we were done, since we were dealing with a linear process that had a clear start and a clear end we were able to use this model to make sure we understood everything in between. We talked to well over a dozen individuals over the course of three weeks, and this model helped us document our incremental understanding after each interview. It allowed us to know how the information we just learned fits with what we already knew.
[See slide 21] This is a model of a very complex medical ecosystem: we call it an info model. It shows actors, systems, and relationships. Basically, it started out as a dump of everything we knew. The colors were added later to help group related elements. This was one of the only ways to articulate and keep track of the volume of information we were learning throughout the project. In addition to helping us ask better questions, this model went a long way to help us articulate constraints of the ecosystem back to the client.
We never actually completed this model. There are some areas that are still pretty unclear, and frankly that fell out of scope of the engagement. But the stuff that did get modeled provided a lot of clarity. At the end, the client said that this model showed them something they all knew, but could never figure out how to talk about, and as a result were unable to effect change on. After having this model they were not only able to talk articulately about their world, but they were able to clearly address problems head on.
[See slide 22] This is the most tactical “back-of-the-napkin” model that I’ll be showing today. This model had a very specific purpose. We had a set of “care terms” and needed to figure out what made each unique. I knew some of them, just from life experience, but others, like ambulatory care, were unknown to me. Not really knowing where the road might lead, I just started modeling what I knew. After getting down what I knew, I was able to look at the gaps and compare the relationships: for example, why didn’t Primary Care and Urgent Care have this middle layer of grouping? Then I could seek out the right answers to fill it in. It was because Primary and Urgent Care were location-based rather than condition- or body-based (you don’t go to a different primary care for your leg and for your heart). The details aren’t as important as the effectiveness. All in all, I didn’t spend more than an hour working on this problem, and it helped us adjust the navigation to be more aligned with what is true about these care types given their context.
[See slide 23] This is what I call a 3D sitemap. I started to build this is OmniGraffle, but it hates isometric anything, so I switched to SketchUp. This was built partially to answer questions around connections and “placefulness” of content and partially to communicate those connections to the client. This is another instance where this particular form of a model came about because it was the most straightforward way to show a complex system of interconnected relationships that lend themselves more to that of a neighborhood than a traditional tree sitemap.
Modeling is an extremely powerful tool for sense-making, and my favorite part of modeling is there aren’t a lot of rules. You can start from scratch and just do whatever make sense, or you can use a standard template as a starting point and tweak it as necessary. You just work towards making something clearer, and if you’ve made something even a little clearer, you’ve succeeded. But that much freedom can make it a little difficult to start a new practice, so I’ve put together five things to get you started with modeling for clarity:
Remember: “The organization of information actually creates new information.” I alluded to this practice in the care types example model. The best way that I’ve found to start modeling is getting down what you know, even (especially!) if it’s incomplete. As you organize what you know, new information will be created and will allow you to make new insights based on these connections
This is the simplest, but also, maybe, the hardest to practice: Take nothing for granted. Too often we proceed under the assumption that people are on the same page only to meet seemingly inexplicable confusion. I started taking a modeling course this fall on Coursera. A couple of my friends recommended that I take it, and hey, I was thinking about submitting a proposal to the IA Summit about models, so I enrolled. About two classes in I realized that when he said “model,” he was not meaning the same thing as when I said “model.” He was talking about statistical modeling using software and algorithms. Not at all what I was expecting or even interested in. It’s a simple distinction that could have been made clear with a simple explanation.
There is something called the Paradox of Cartography, which states: To present a useful and truthful picture, an accurate map must tell white lies. Very rarely can you model all facets of a system with a single model. The more complexity you show, the narrower your scope needs to be, and visa versa: the more scope you include, the less complexity you can show. A great example of this is a map, a cartograph. A map of the United States needs to show far less detail than a map of San Diego, even though all of the same information about San Diego is still true with the United States map. In order to make the larger picture useful, we need to show less detail. Being able to have a narrow focus will help avoid confusion and inaccuracies. So keep the focus of your models narrow, and make a lot of them.
Dive deep into the relationships between the parts to better understand the whole. This builds on the first point around starting with what you know and is useful when you’ve exhausted your current knowledge or you’re just unsure of what you know. By exploring how the parts relate to one another, you’re testing and pushing the boundaries of your overall understanding. And like all models, if it holds water, awesome. If not, throw it out and move on.
And lastly: Ask questions. Ask questions until you figure something out, or until you’re forced to stop. There is always more to learn.