Introducing Concept Models
A concept model follows the format of a few other diagrams in this book—shapes connected by lines. In this case, the shapes (sometimes called nodes) represent concepts. The lines represent the relationships between the concepts. Both site maps and flowcharts belong to the same family, but concept models are, in a sense, a superset. They don't prescribe a particular type of relationship or presume a particular type of node. Table 4.2 differentiates between concept models and site maps around some fundamental characteristics.
Table 4.2. Contrasting concept models and site maps. How do concept models differ from site maps? Let me count the ways...four. There are four ways.
Site Maps |
Concept Models |
Represent hierarchical structures |
Represent all kinds of relationships |
Have a clear beginning, but no clear ending |
May have neither a clear beginning nor ending |
Illustrate how content categories relate to each other |
Tell a story about the site's underlying concepts (which may or may not be content categories) |
Presume that nodes represent particular pages or templates |
Make much broader assumptions about what nodes represent |
The one constraint on concept models is that the nodes are nouns and the connections are verbs. Each node-link-node combination can read as a sentence, as in:
- Concept Models Are Diagrams.
It's not much of a constraint; the format offers much flexibility, which cuts both ways. Sometimes it can be hard to determine what to include in the model and what to leave out.
How Concept Models Help: A Short Preview
Concept models fill a void between requirements and design, between stating the problem and solving the problem. Designers must internalize the design problem. Somewhere between "getting into the user's shoes," recognizing technical constraints. and understanding the business context there is a need for a unified vision of the product. A concept model establishes a consolidated, holistic view of what the thing is, what it does, and who it helps.
Concepts in the model translate to different parts of the site. A concept model can help determine your strategy for establishing templates, components, modules, navigation, metadata, and the underlying structure of a content management system. It can provide insight into the range of interactions users will need to perform. Short, right?
Figure 4.1 A concept model to explain concept models. I thought you might like the recursion.
A rose by any other name
Someone once asked me how concept models are different from affinity diagrams. Affinity diagramming is an exercise to help a group of people identify similarities across a broad set of qualitative information, like observations during user research. Affinity diagramming is like any other grouping and prioritization activity—meant to consolidate a range of information and identify patterns. Beyer and Holtzblatt use affinity diagramming to consolidate observations from their user research technique, contextual inquiry, and identify new insights about the target audience.
Which sounds a lot like concept modeling.
Affinity diagrams don't follow the exact format I describe here, which is based more on Novak's concept mapping work (see sidebar on History of Concept Models). Beyer and Holtzblatt put a strong emphasis on consolidation through categorization and grouping, whereas my concept models don't necessarily revolve around a hierarchy.
Concept modeling is not unique to web design, nor is that the only name for this activity. Explicitly connecting ideas through visualization is a technique that comes in many flavors. I can only urge you to find the flavor you like best, or, like Ben and Jerry, invent one that suits your taste... er... style and approach.
Figure 4.2 Concept models establish frameworks that give the design team a vocabulary for talking about a domain. This model about comics clarifies some of the more obscure concepts and describes the key relationships.
Challenges
Because it's an artifact to facilitate your thought process, the challenges with concept models—more than any other artifact—have to do with getting out of your own head:
- Analysis paralysis: There's nothing more absorbing than fiddling with a model. Whether you go back and forth on the diagram's layout or engage in an endless internal debate on the right structure, you can lose sight of its purpose. Ultimately, you don't need to get everything "right," you need to get it "right enough." Take your deliberations far enough to help you move to the next step. Have a good sense of the range of templates you'll need? Then stop messing with the line weight on your connections and move on!
- Practicality: Even if you bookend your thought process effectively, you might create a document that doesn't effortlessly take you into the next stage of the design process. Any good artifact must further your thinking, whether in understanding the problem better or creating a meaningful design to address the problem. Concept models are inherently fussy and force you to dwell in abstract concepts. The result can easily be an output with no obvious next step. Knowing when to stop (see "analysis paralysis") is key, but knowing what's going to offer the most utility is also important.
- Perspective: Like other artifacts, concept models depict a slice of reality, telling a story about how things are or ought to be. Unlike a flowchart, for example, a concept model has no clear protagonist, no obvious perspective. Put another way, two people creating a flowchart of the same process will come closer to each other than two people creating a concept model of a set of ideas. As self-indulgent as concept models can be, your models can be more successful if you incorporate multiple perspectives—or at least acknowledge that there may be several different ways of looking at the world. Perspectives can influence which concepts you incorporate and how you describe the relationships between them.
The previous challenges may rest on one central challenge: Concept models are, out of necessity, an abstraction. They don't talk about things, they talk about kinds of things. They don't represent the physical manifestation of any content or interface element. Their elements don't necessarily directly translate to parts of the interface. They remain at the highest possible levels of content, not digging into the dirty details of what goes where.
I've almost convinced myself to stop doing these things. Potential lack of practicality? Risks to the project plan? Abstract thinking? That can't be fun for anyone. And yet, I find myself turning to modeling project after project. As a tool for design, they help me start to shape structures, if only in the most basic way. As a tool for understanding, they help me gain insights into a particular domain to get the lay of the land and to give myself a starting point for design. Drawing pictures, even quick ones to lay some groundwork, yields more fruitful design work than simply starting with screens.