In Which a Concept Model Makes Me Giddy
About a decade ago, my site maps–a design artifact that describes the structure of a web site–started evolving. They changed from org chart-like boxes and right-angle connectors to networks of circles with straight-line connectors. For some reason, this format really resonated with my clients and colleagues. As I was on the look-out for similar diagrams, I stumbled upon mind maps. In short, a mind map is a means for explaining a set of ideas by showing the relationships between them. It is a group of nouns connected by verbs.
I made one in 2008 as an example for a poster on concept models for the IA Summit:
It’s not the best concept model in the world, but it did allow me to demonstrate the idea and a few techniques. (Notice, for example, that some concepts are acting as backdrops for other concepts, and that some concepts are repeated to show different kinds of relationships. Notice also that in this case the concepts are linked to form long sentences. This is appropriate for models with a small number of concepts but could easily become confusing on larger models.)
I’m making a concept model for a project right now and I’m really excited about it. The model covers a broad domain, but with a pretty specific agenda: It describes the role of social networking technologies and practices in the enterprise. Why am I doing this? This particular project is a strategy project, and the model is meant to help the project team develop our ideas further, then communicate them effectively to the client. It’s meant to help our clients get past their narrow focus and see the bigger picture.
That’s fine for strategists, but how does this help designers? Concept models fits into the design process in a few different ways:
- Concept models can describe the structure of a system. In short, it specifies part of the design–perhaps a map of the overall experience or a description of how users might navigate through a particular area of the site. It might describe different templates and how different kinds of content relate to those templates. The advantage of a concept model over a site map is mostly one of format: Circles connected by lines free us from describing only "belonging"/hierarchical relationships.
- Concept models can frame the design problem. The flip side to concept models as design specification is using a concept model to describe the design problem. While requirements generally do not lend themselves to visualizations, the simplicity of concept models makes them ideal for expressing what the system or web site must do.
- Concept models can help designers understand the domain. This is a crucial step, sometimes missing from formal processes and methodologies. Our expertise is design, not necessarily the inner workings of the Federal Communications Commission’s wireless spectrum auctioning business (just to pick an arbitrary example). While a concept model can help frame the design problem, describing particular aspects of the domain and how our product will support them, it can also describe the broader landscape. In this instance, the concept model is purely a learning tool, a way for designers to become more comfortable with the overall context of the design problem and final product.
So, the model I’m working on now mostly serves to help us frame the design problem–that is, show how the product will serve the needs of the organization. Unfortunately, because it’s for a client, I can’t share the model with you. But I can tell you why it’s making me giddy:
- It highlights aspects of the design problem that are otherwise buried.
- It shifts the conversation from technology to impact on the organization.
- It draws connections between concepts that seem otherwise distant.
- It uses labels for the connections like "reveal", "conceal", "limit", "enable": real active verbs that convey something more than belonging.
- It allows me to eliminate ideas that are not essential to the overall story.
- It encourages me to place loosely connected ideas into context.
Highlight Buried Aspects
Concept models can bring to light aspects of the domain that are overshadowed by other concepts. Ideas that dominate the conversation may do so because they’re the most fun to talk about or because the team culture is biased to think that those concepts are most important. By building a concept model and forcing yourself to expose key relationships, you might find that a particular "minor" concept is connected to many other key concepts. The number of connections can reveal relative importance.
In the case of my social technologies model, I realized that the purpose of these technologies is to overcome obstacles that are inherent in most corporate cultures. The focus on obstacles helped me articulate not only what those obstacles are, but how they impact business.
By casting social technologies in terms of corporate obstacles, I could speak directly to how aspects of social technologies address them. For a client whose internal customers were so focused on the technologies themselves ("let’s talk about tagging") it’s very appealing to talk about real benefits. Such a discussion allows them to set a strategy and prioritize.
Borrowing a technique from Bryce Glass’ now canonical Flickr user model , I like using a single sentence expressing the "value proposition" as the model’s backbone. In my social technologies model the sentence was this: Social Networking helps Employees overcome Obstacles. What bothered me about this sentence was that it framed the domain in a negative way: Everything centered on those obstacles. I had another core idea, that social networking depends on some virtual environment which in turn rests on some technical platform. As I played with the model, I realized I could show the connection between the virtual environment and the obstacles.
It is extremely challenging to escape taxonomical relationships–that is, relationships that describe belonging. Our drive is to categorize, put things in buckets. Forcing your brain to think about the concepts in a different way can be illuminating. Instead of asking yourself "where does this belong" you can ask yourself, "what does this do?"
Eliminate Non-Essential Ideas
The client brought a lot of baggage to the table–nothing you wouldn’t expect, the usual stuff when corporate cultures try to assimilate new ideas. These ideas were important for parts of the strategy, to show stakeholders we heard what they said. But as part of the model, they were–to misuse a Tufte term–chart junk. The concepts were balloons that didn’t fit nicely into the picture because they weren’t germane to the themes. To pick on tagging again, this was something that came up time and time again–a small feature of a set of social networking tools. Tagging is important, but at our stage of the project, with the story we were trying to tell, it was a concept that was not essential.
You might argue that if important concepts don’t fit into the picture, there’s something wrong with the picture. That may be true: A concept model can help surface that. As you gather concepts together and establish that backbone, if you find yourself with a big pile of concepts that just don’t connect in, you might not have the right theme.
Collections of Ideas in Context
Many of the ideas described here came from a report by Jennifer Bohmbach, who was collaborating with me on the project. Her report contained some key themes — flexibility, sharing, feedback — aspects of social media that are easy to say but not easy to imagine. Those of us in the business take them for granted because we see them in action, if not in our own projects than elsewhere online. The model I put together based on her report didn’t add anything new (JB is nothing if not comprehensive) but it did help frame some of these underlying themes.
Concept models aren’t for everyone. When I show fellow designers these artifacts, I sometimes get "You show that to clients?" Like any deliverable, there’s a time and a place for concept models. If you’re anything like me, however, you think visually. Even if your models don’t see the light of day, a good model can help you get a better grip on the problem, or lay some groundwork for your designs.
Share your thoughts
Have you thought about your design in a framework-style of systems?
What frameworks have you outlined? Share your thoughts on this topic
with us at the UIE Brain Sparks blog.