Originally published: Mar 04, 2009
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:
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:
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?"
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.
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.
UIE is excited to bring Dan's full-day seminar to the UIE Web App Summit. His session, Communicating Design: Essential Deliverables for Highly Effective Design Teams, is sure to be one of the audience favorites. You don't want to miss this hit session.
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.
Read related articles: