In Information Architecture, Modeling

In Parts I and II of our “Built-to-Last” series, we talked about two major concepts for creating effective deliverables in Information Architecture (IA). Part I described how to create contextually appropriate and concise models. Part II demonstrated that using contextual inquiry to get deep involvement from stakeholders would improve understanding in the future.

In this section we tackle the greatest challenge to effective document delivery: all organizations making anything that involves software are looking at a problem set with multiple layers of technology, stakeholders, and objectives. In short, all modern projects are complex projects, so it is incumbent on any deliverable to find a way to embrace and manage that complexity.

We propose that the complexity of projects will require, at some point, an integration of models. That integration will involve:

  • A clear thematic expression of concepts
  • Layers of meaning
  • Anchoring the concepts against real end-user needs

Case Study: A Multi-Theme Layer Cake

In a recent project, TUG needed to explain three major themes emerging from a strategy phase:

  • Users’ environments should align with, supplement, and enhance users’ work.
  • Workflow should be simplified for as many people as possible, leaving deep complexity for the experts.
  • Software architecture should accommodate the technical complexity that is part of the core business.

There was a pretty wide separation between the stakeholders who related to each theme, and we wanted to emphasize their interdependency. To make sure the relationships among all three themes were clear to all stakeholders, we decided to use a model integration.

The model we used to represent that integration was the service design lens, defined as “the activity of planning and organizing people, infrastructure, communication and material components of a service in order to improve its quality and the interaction between service provider and customers.”

An example of a service design model

An example of a Service Design model

While what we did isn’t an exact fit to the service design lens, the metaphor of the layers of an integrated design matched very well to the client’s needs and the themes we were trying to convey.

The Initial Models Used for Each Theme

We used a Dashboard Concept Model to show how the Users’ environment should align with, supplement, and enhance users’ work.
The Dashboard Concept Model

We used a Business Process Model to represent how Workflow should be simplified for as many people as possible, leaving deep complexity for the experts.
The Business Process Model

We used a System Architecture Model to show how Software architecture should accommodate the technical complexity that is part of the core business.
The System Architecture Model

The models supporting each theme are credible in the spirit of what we described in Part I of the series, but they speak to very different audiences in different ways.

How it All Fits Together

As we described above, we decided to integrate these ideas using a Service Design model, because people, infrastructure, and material components were all part of the story.

Our integration plan was to create a couple of credible scenarios in a storyboard. The service design model then allowed us to integrate the layers by event and then join them contiguously over time. We used an approach outlined by Kevin Cheng to create a “comic” of that scenario.

A "comic book style" storyboard

A “comic book style” storyboard

We then tied the different themes together in the broader service architecture.

Example of an Integrated Model

Example of an Integrated Model

If we drill down into a specific “column” of the model, we can see how powerful this is. Each theme is identifiable from previous introductions of the concept, but they exist in layers, allowing easy association between them.

Model Integration Close-up

This turned out to be a remarkable exercise. In one diagram, we united the concerns and the support that each group in the organization could provide to this complex, multi-layered project. The approach could be used to identify and prioritize efforts, determine difficulties, and modify aspects of functionality to support different constraints in the architecture.

It was also deeply fun and satisfying. In a world of very complicated or maddeningly glib requirements specifications, this was a meaty, accessible, powerful tool that drove the momentum of the project for the next six months.

We hope you’ve enjoyed our “Built to Last” series! If you have any questions about this blog post or other ones in the discussion, feel free to drop me a note in the comments section below.

Showing 2 comments
  • John Gakau

    Hi Daniel,
    Great set of articles on the importance and power of using disciplined and rigorous models/modeling to establish well thought out and well formed foundations that are both extensible and scalable over time and across contexts.

    Modeling has been an integral and discreet part of my process for over a decade. Models and modeling (i.e. identifying their elements, building/refining them, and pushing them up against each other) are an important step to laying a solid architectural base from which to build and support meaningful, coherent, and effective experiences/solutions for people.

    While models (and the immense dividends good ones often return) are such a critical part of the journey to deliver “built to last” experiences/solutions, they are something I think way too many have been willing to shortchange, or skip entirely, with the common pressures and desires to get to wireframes or other “real” UX deliverables.

    Despite the power and benefit of models that your series of articles call out (and that I have witnessed in my own practice), I wonder way models/modeling have not been more of a focus or discussed more among thought and practice leaders in the wider UX world. (Indi Young’s Mental Models book is the only treatment I can think of that does justice to the power of rigorous, disciplined modeling, even if its focus is narrower than the universe your articles touch on.)

    Are you seeing/experiencing the same thing? If so, do you have any thoughts about why this is? Or, if you do know of rich resources or discussions taking place related to models/modeling would you be kind enough to share?

    • Daniel O'Neil

      Hi John,

      Thanks for the thoughtful comment. So, there are a couple of different questions here. I think the first seems to be “why isn’t modeling more part of the UX space”, which I think you also answered: UX folks are often coming late to the table and are expected to provide development specifications instead of “architecture” or broader conceptual concepts.

      When that mindset exists, it’s hard to do a couple of things:
      1) ask for time to develop concepts (“strategy and structure”)
      2) create “dumb models”, as Dan Klyn calls them; that is, models that can be used to develop ideas and then be thrown away.

      This problem exists in IA too, and most folks at TUG seem to get their inspiration for modelling from other disciplines, like industrial design or building architecture.

      Dan Klyn gave an amazing presentation about ways to approach modeling and these discussions from an IA perspective. It might be a good place to start.
      Here’s the link:

      http://understandinggroup.com/2014/09/strategy-structure-presentation-uxstrat-boulder-colorado/

Recent Posts