A fundamental part of information architecture is translating rough ideas through language to a set of organized relationships, understandable to all stakeholders. Modeling information helps visualize the problem to be addressed en route to finding a solution. The process may be complex, iterative and time consuming but necessary to transition from a vague idea to a final implementation. Modeling takes place throughout a project to facilitate analysis of the problem being addressed. It helps clarify relationships and ideas without moving too quickly to specifics, like bubble diagrams of spatial relationships that evolve in phases into detailed architectural drawings. Modeling captures assumptions, even if unstated and invisible, and it can take multiple forms as it progresses to support clear navigation, logical filters and effective discovery.
organization of information
Practical Modeling: Making the Invisible Visible
by Joe Elmendorf, Andrew Hinton and Kaarin Hoff
There are many sorts of models, including physical scale models of buildings, mathematical and statistical models, which overlap in many ways (Figure 1). In a recent workshop focusing on conceptual models, information architects Joe Elmendorf, Andrew Hinton and Kaarin Hoff taught participants how to make concepts into visual objects we can manipulate, allow us to explore their relationships and let us work with parts and aspects of complex systems. There’s a misconception that conceptual work isn’t practical. But, in fact, all these approaches are practical, when used for the right purposes.
Here are some of the main points and highlights from the workshop titled Practical Modeling: Making the Invisible Visible, given at the 2015 Information Architecture Summit held in Minneapolis in April. The full presentation deck is available on Slideshare, linked at the end of this article.
Why? Because we are dealing with complex, audacious, messy problems.
Information architecture isn’t just about designing labels, links and content arrangement … and it’s not just about websites. It has to do with the way language acts as infrastructure. It addresses meanings and relationships and how together they create structures. And a lot of that language/meaning/relationships dynamic is driven by the way the organization understands and talks about itself and what it is putting into the environment. The questions needed to get at effective navigation and filters and interfaces are the same questions that get at the core of an organization. These issues are big and uncomfortable to talk about – but the organization affects the website and the website affects the organization. Stakeholders think they are going to an easy website conversation and end up discussing deep issues, like the strategic vision of the organization. Modeling can help expose all of these big issues, make it easier to talk about them and help align the team around a strategy to deliver what the business needs and the user wants.
We talk about modeling because it is the most useful tool in our toolbox to get at the WHAT.
Establishing WHAT the problem space is before discussing HOW to solve the problem saves time, money and frustration. The complex ecosystems we’re designing for these days require a strategy for understanding the whole and the relationships between all of its parts.
With so many moving parts, it is very difficult to assess when it is safe to move on to the next step of the project. We are often driven by the calendar, not by confidence. And, as we’ve all experienced, writing requirements when the site is already launched has huge financial implications. Modeling is the tool we use to measure completeness, increasing our confidence and decreasing our likelihood of going over time and over budget. By showing what you already understand (or even think you might understand), you can identify the holes that need to be filled in before your initial understanding is complete and ready for validation. This process is iterative: sometimes you have to ask questions, model, validate and repeat before reaching that completeness – but when you get to that point where you get it, you’ll know.
There is not a clear point at which the project turns from the WHAT to the HOW. It is a gradual shift in focus from one to the other. IA tends to have a macro perspective in the earlier part of a project, but it doesn’t go away as the details are sorted out. It just becomes more specific, within the larger patterns established earlier on. Modeling is not a stage in the workflow; it is useful throughout the project (Figure 2).
At no point is it only about big stuff – there are always elements of how architecture informs design even at the beginning. A quick user interface sketch on a whiteboard to help illustrate a big structural approach is just fine during analysis, for example, as a way to reflect on implications of architecture, but not to jump into design too quickly.
Here’s a hypothetical example from early on in the project (pulled from Andrew’s book, Understanding Context). It is a big, simple model that can help bring a lot of clarity to stakeholders. This has only has three circles, but it was a basic conceptual model for a major retailer to decide that all three areas of its online presence needed to be co-equal and integrated. The site is a shopping website, but stakeholder interviews showed that learning and resources were equally important as shopping. That’s a big deal! And this model allows everyone to see that that’s what we are deciding together. The aim is for alignment and no surprises when we get to structure.
At the other end of the project timeline, here is a “just-in-time” model (Figure 4) created in the midst of development, to help everyone on an agile team get centered on an essential bit of structural design and rationale – it clarified an invisible roadblock that everyone was tripping over but couldn’t articulate.
For digital design work, the ultimate goal is usually to create some kind of interface. But models can do things that the specifics of interfaces can’t. Models are a way to work through questions about relationships and ideas, without being tangled in the specifics of interaction.
Modeling a House
The physical world helps us out with a modeling example we are all familiar with – a house. Many architects use bubble diagrams – they’re not very structured, of course, but architects using them want to start without too many assumptions about structure. They’re looking for relationships and meaning before they begin to architect. These are seemingly dumb diagrams – but they’re dumb in a good way, in that they ask questions without a lot of assumptions. They’re not trying to be too smart, at least not yet.
A bubble diagram turns into something we’ve all seen, a floor plan. Now the floor plan is still a model, but it is not as conceptual. It is moving towards the very literal building it will become. If you look closely, the floor plan is still mainly just doing the work of establishing the definitions and relationships between the main functional areas of a structure. If the family for which this house was intended had seen a bubble diagram that gave equal weight to eating in the kitchen and eating in the dining room, they would not be surprised to see these two areas receiving similar square footage.
This observation also points out the value of multiple models: the bubble diagram may have shown the play between the parts, but the much more literal doors in the floor plan really alert the family to traffic flow considerations. Discussions at both stages allow the architect to know when the plan is complete enough to continue, and ensure the final product will be pleasing.
Modeling Is for Everyone
We hear a lot from folks that their work environment just can’t support modeling. We’d argue you’re too busy not to model. No matter if you work in an agile or waterfall environment, if you’re involved in the entire project or just a portion of it, modeling can help you in your work.
We realize your project plan may include no time for modeling as a phase, but you can do it as part of your other work – or as part of the collaborations and conversations you have with stakeholders and team members. Just getting up to a whiteboard and modeling the ideas being discussed in real time can provide most of the modeling you need – or serve as the start of a new, official design artifact.
Whether we know it or not, we already have various assumptions that serve as accidental, hidden models. It’s better to bring these invisible assumptions out into the open and model them explicitly, because ultimately, models become molds for making (Figure 5).
Consider the Larger System
The end products we are designing do not exist in vacuums. Larger systems are influencing, and being influenced by, these end products. But considering that while also completing the tasks on our timesheets can seem impossible. Modeling can be a quick, fun way to consider one or even three levels higher than the context your end product is fitting into. (The example model in Figure 6 was made in only 10 minutes!)
How Do You Get Started?
Start making visible what you know (Figure 8). Play with circles. Use question marks. Use arrows. Capitalize on Venn diagrams. As you organize what you know, new information will be created. You’ll see new connections and find new questions. You can create very lightweight models that don’t need to subscribe to detailed methodologies. Getting ideas, priorities or anything else relevant to your work into something visible is the first step.
A few tips:
- A model can never be the whole truth; it is telling a story.
- Use multiple models to get at different issues.
- Don’t be afraid to leave out details – concentrate on the big issues you need to understand.
Keep the parts flexible and movable as long as possible. And don’t fall into the trap of trying to make it too pretty; sometimes, pretty is dangerous. If you make your model too pretty, too perfect, you won’t want to change it and neither will anyone else. These models are objects for discovery. They are supposed to be messy and pliable, so embrace it.
Potential scenario: My company has been hired to just do Banana Republic’s sale pages. I have just been asked to join the team and have 30 minutes to prepare. I head over navigated to the site.
Looking at the header and the sale in-page navigation, it was apparent that the sale structure varies from the rest of the site. A quickly drawn model shows that women’s sizes are inconsistent across the two areas and baby only appears in sale.
You could write down these two notes and ask about them during the meeting. But what questions have you missed in your mad dash to prepare? Perhaps this model can prompt the client to share more inconsistencies and the reasons behind them.
You can try this at home with one of the hands-on activities we did in the workshop: Model your morning coffee ecosystem. How do you get coffee in the morning? What is the bigger system in which you get coffee?
Here are some of our favorite models produced by workshop attendees. (Unfortunately, we didn’t get the names of their creators when we took these snapshots, so let us know if you made any of these!)
For more on the subject:
Practical Modeling: Making the Invisible Visible presentation slides
How to Make Sense of Any Mess by Abby Covert
Complexity and Other Beasts by Elisabeth Skjelten
Understanding Context by Andrew Hinton
Joe Elmendorf, Andrew Hinton and Kaarin Hoff are information architects with The Understanding Group. They can be reached at http://understandinggroup/team/