This chapter is from the book
This chapter is from the book
This chapter is from the book
Creating Concept Models
Diagramming concepts can lead you down pretty abstract, esoteric, and sometimes unproductive lines of thought. A little planning goes a long way, at least by making some basic decisions about purpose, audience, and content. These will give the model focus and ensure you're not spinning.
Basic Decisions for Concept Models
Sometimes I don't know the answers to the following questions when I start modeling the concepts behind a new project. It's a useful exercise for me, and I've become reasonably responsible about not getting pulled too far down the rabbit hole. That said, once the model is underway and I've got a better sense of range and scope, I also start to frame up what role the model will play on the project. Either way, as the model starts to form up, answering these questions can help give you a sense of focus.
What is the purpose?
In design, the purpose of high level conceptual thinking is to inform the entire process. At different stages of the design process, the conceptual model will serve different purposes. The chief purpose of a model is, in my mind, to answer the question, "What are we dealing with here?" It seeks to illustrate and frame the range, scope, and depth of the things we're interested in.
While the answer to that question may shift and settle over the course of the project, its boundaries generally remain intact. The answer to that question, however, contributes to all the other decisions you and your team will have to make throughout the process. At the beginning, you might use a model to comprehend a new domain. As you get underway, the decisions might be about what's in scope and what's out of scope for the project.
Even the simplest concept models can help. I created a very simple model at the start of a project to help clarify some overlapping concepts (Figure 4.11).
)
Figure 4.11 To help inspire new ways of thinking about the product, I created this concept model to better understand all the different moving parts. It's a pretty simple model, but it was enormously useful in clarifying the relationships. Note how this model completely evolved from circles-and-lines to more of an illustration.
Who is the audience?
"Well, that didn't go so well." So said my colleague Chris as we came out of a meeting where I presented a concept model to a group of business stakeholders. Boy, was he right. They just didn't get it. Unless a model is fleshed out and highly illustrated (and perhaps even if it is), you'll struggle to get any meaningful response. Table 4.6 explains why.
Table 4.6. Concept models can be difficult for people to understand.
|
Concept models... |
and people generally... |
|
Represent abstract concepts |
Like talking about concrete things |
|
Don't directly relate to aspects of the web site |
Can't picture how it affects the design |
|
Present familiar concepts in a new way |
Find that uncomfortable |
|
Introduce new concepts and structures |
Have trouble putting new ideas into context |
The section up ahead that deals with presenting concept models can give you some ideas on how to fine-tune the model depending on whether you need to show it to a client or not.
Generally speaking, I create concept models for myself. If I need to solicit input from someone else, I'll package the diagram to tell a specific story. Here are some things you can do to facilitate such a presentation:
Table 4.7. To make concept models more accessible, consider tapping into people's strengths.
|
Since people generally... |
You should... |
|
Like talking about concrete things |
Lace your model with examples |
|
Can't picture how it affects the design |
Embed implications by highlighting templates or components that emerge from the model |
|
Find new perspectives on familiar ideas uncomfortable |
Rationalize why you're shifting the perspective on otherwise familiar concepts |
|
Have trouble putting new ideas into context |
Be prepared to tell a story about one or two new concepts to help people understand why they're important |
It's a big investment, so I always double-check that I have the time and budget and ask myself, "What feedback do I want from this person? Is this the best way to get that information out of them?"
What should you include in the model?
What makes a good node? Four things should drive whether you end up including a concept in the model:
- Important to users: Through primary or secondary research, you will learn what ideas are central to the users' experience of the site.
- Important to stakeholders: Interviews and requirements-gathering with stakeholders will reveal which ideas are important to them. These ideas are central to an organization's conception of success.
- Meaningful landmark: Some concepts provide a useful way to link other ideas together. They serve as a central point or bridge two concepts.
- Offers insight: As you elaborate on your model, you may identify additional concepts that can help illuminate the underlying domain.
)
Figure 4.12 Good nodes are important to users, important to the business, provide a contextual landmark, or offer an insight.
After you have a first draft of your model, you can also try to bring "bad" nodes to the surface—concepts that don't substantially contribute to explaining the domain. One way to do this is to pull out common words, concepts that are so broad that outside the context of the model it's hard to determine what they might be talking about.
)
Figure 4.13 Common words are good opportunities to prune the model. One early version of the comics model included the concept "People," which was easy to eliminate.
The links between nodes should all strive for greatest interest and appeal. You should seek out relationships that:
- Highlight the active: Use active verbs that describe how one concept affects, influences, or otherwise changes another.
- Evoke interface actions: Assuming all the concepts will translate eventually into information on the web site, all the links could reflect the various actions users might perform. While not a necessity, the exercise lays groundwork for doing subsequent design work. If you subscribe to the idea that all interactions with data can be reduced to CRUD (create, retrieve, update, and delete), here are some verbs that relate to each of those actions:
Table 4.8. Relationships in concept models may try to highlight the same sort of connection over and over again. These nuances, however, can have a major impact on the design process. "Create" could refer to something generated or yielded passively, as a by-product, or something with much more intent, like "composes".
|
Create |
Retrieve |
Update |
Delete |
|
Generates |
Displays |
Changes |
Removes |
|
Yields |
Explains |
Affects |
Cancels |
|
Produces |
Represents |
Depends on |
Eliminates |
|
Defines |
Values |
||
|
Composes |
Appears |
How you should lay out the model?
Concept models start out messy. As you clarify the story and insights start to emerge, you may want to clean it up. The insights you learn should drive how you structure the model: They should tell you what concepts and relationships to prioritize.
My models tend to fall under one of three typical structures. These structures may be useful starting points once you've had a chance to move the concepts around the page a bit.
Note that it's rare for me to start with one of these structures right off the bat. In my initial models I do not prioritize any concepts. Only after I see how the story emerges do I zero-in on one of these approaches as appropriate for providing a framework for the model.
Tips for Crystal Clear Concept Models
It's not too hard to get some initial ideas down on paper, especially if you're familiar with the domain. But if you don't know much about it, you might get only a few nodes on paper before you get stuck. Here are some ideas for getting, you know, unstuck.
Do your research
Flesh out your understanding of the domain by reading up on it. Nothing gives you more nouns and verbs to draw upon than a few comprehensive, detailed descriptions of the business.
When I started an 18-month contract at the wireless division of the Federal Communications Commission (FCC), it was clear I knew nothing about the business. While the FCC's web site was a good starting point, I also sought out other web sites that cater to the same target audiences. This afternoon of surfing gave me enough fodder to build up a model. Ultimately, the model was never shared with others, but was a good tool for me to become comfortable with the various players and underlying business model.
User research is even better. Transcripts of interviews are rife with concepts that are important and meaningful to users.
Look under the hood
If you're stuck, pick a node and ask yourself, "What else can I say about this concept?" Unpack the concept, forcing yourself to be as specific as possible. If you need more specific questions, pretend you're interviewing a person (not a circle) who knows about the concept or the domain.
One of the jargon words used in talking about comics is "mythology," which informally refers to a character's backstory. Because many popular characters have been around for decades, and have been subject to so many interpretations, there are multiple mythologies for some characters. This idea is difficult to model.
Some questions I asked myself about the "mythologies" concept in order to arrive at a more detailed model:
- What makes one mythology different from another?
- How do storytellers deal with multiple mythologies?
- What other concepts are affected by a character's mythology?
)
Figure 4.14 Some details emerge only after forcing yourself to unpack a concept. In this early version of the comics concept model, I elaborated on the concept of a "mythology". While it didn't make it into the final model, I did keep "relevant milestones".
In elaborating on this concept, I knew there was a relationship to another key idea—a universe. In short, one way to resolve competing or conflicting backstories is to place different versions of the same character in parallel universes. (And people wonder why comics aren't more mainstream.)
It was difficult for me to think of a specific verb that created a relationship between Mythology and Universe, so instead I tried to think of concepts that "mediated" between them. This helped me flesh out this part of the diagram.
If you can't generate answers or find them through research, capture the questions in the model itself. When you get to interview an expert, these questions can guide your agenda.
Move stuff around
If you have dozens of concepts, it may be challenging to find a central focus for the diagram. The best way to elaborate on the model, focus it, and find insights in the relationships is to move the nodes around. This might seem like an oversimplification, and a very mechanical way of iterating on the model. By moving concepts around, however, you can test out new kinds of relationships, explore positioning relationships in a new way, and zero-in on gaps in the model.
Build up then tear down
Since it's difficult to picture the end state before you start a model, err on the side of too much information. Include concepts that may not be entirely relevant. Link a concept to as many others as you can. Your page will be covered with circles and lines, but starting with too much is part of the creative process, giving you more opportunities for insight. You'll have to cut things out ruthlessly when it comes time to clean up the model, but the pruning process can also lead to insights.
To reduce links, look for triangles (Figure 4.15). Three interconnected nodes can indicate that one of the relationships is redundant. Eliminate the relationship between the two less important nodes, focusing on the relationship between the important node and the ideas that support it. Alternatively, identify a chain of nodes that tells the simplest story.
)
Figure 4.15 Reducing triangles from three connections to two can help clean up the model. Looking for triangles (like these from an early version of the comics concept model) can reveal opportunities to consolidate and focus the model.
To reduce nodes, eliminate words that are so common they are merely a convenient mechanism for bridging to other concepts. In an early version of the comics concept model, I used the concept "words" to encompass the different kinds of verbiage in a comic book–dialog, narrative, thoughts, and so on. Since I was already using the concepts "scripts" and "writers," "words" felt unnecessary.
)
Figure 4.16 Redundant words make for good opportunities to simplify the model. Though writing a script is an accurate depiction of the comic authoring process, it may not be essential for planning the user experience. Of course, if one of the requirements for the project calls for allowing users to download scripts, it would be worthwhile to keep this concept in.
Level-Up Your Concept Model Skills
It can be easy to spin in circles (ha ha) with a concept model. Here are some things I watch out for:
Convergence: Everything wants to link to one concept
Though the hub-and-spoke model is a perfectly good way to represent how a central concept is the foundation for a series of interconnected concepts, the hub shouldn't be the only concept everything links to. A model with a hub and one level of spokes without much more doesn't help readers understand the rich array of relationships that drive the concept.
If you find yourself wanting to make statements about the same concept over and over again, a concept model may not be the right tool to describe the domain. Then again, you can try a couple techniques to breathe some life into the diagram:
- Take the central concept out. I know: crazy, right? When I find myself unable to express any relationship without linking to the central concept, I take the concept out and treat it as an assumption for all the other relationships. This helps me focus on the relationships between the concepts.
- Use a value proposition structure. Value proposition links three or four concepts together in a sentence, like "Concept models are diagrams that describe complex ideas." Treating this as your central theme (instead of the single concept) gives you more opportunities to explore detailed concepts.
Keep the concept in perspective
You may be tempted to define life, the universe, and everything with a concept model. Once you get the hang of noun-verb-noun, your inner 18th-century philosopher will be clamoring to be let loose on the world. Why shouldn't you be able to represent everything as interconnected circles?
Ultimately, you're trying to explain a domain. Serving only yourself, the concept model doesn't need to unearth the deepest assumptions. A model for readers will only be undermined by too much information.
There's no litmus test to see if you've gone too far, but practice shows that most of my models include no more than a couple dozen concepts.
Keep the model practical
Stay three or four steps ahead as you're constructing the model. You don't want to censor yourself to the point of eliminating every concept. But you also don't want to take your concepts down to the building blocks of life. Ask yourself these questions as your put the model together:
- Is this concept relevant to the target audience?
- How important is this concept to the business?
- Which relationships would the target audience prioritize?
- Can I imagine how these concepts will be turned into elements of the interface?
- Can I imagine some user research that would help me validate these concepts?
Answer "no" to any of these questions and you might be pushing into the realms of the impractical.
A concept model in the design process is like salt in a recipe: it sets the stage for a broader palette of flavors. Too much, and you'll overwhelm the rest of the ingredients. To remain practical, a concept model has to just provide a foundation for inspiring, informing, and establishing context in the design process.