This chapter is from the book
This chapter is from the book
This chapter is from the book
Applying Concept Models
Though potentially highly disposable, concept models can also have a long shelf-life to help drive ongoing design activities.
Providing Context for Other Deliverables
Once the model is complete, I'll stick it at the front of other deliverables. They provide a nice visual for stuff that usually comes at the beginning of the document: what is the problem we're trying to solve, what principles drove our design decisions, what is the relationship between the site's audience and content, what is the scope of our design project.
This is only meaningful if the concept model actually provided specific inspiration for the remainder of the document. Perhaps the model helped you identify what screens to build or seeded the idea for the site's navigation strategy. If this is the case, the model can help tell that story as well. Besides the diagram itself, you might include some narrative text or at least three to four conclusions ("key take-aways") drawn from the model.
On subsequent pages of the document, the model can provide more specific context. You can miniaturize the diagram, scale back the color, and use deeper saturation to highlight the relevant area of the model for each wireframe or persona or what-have-you.
From Model to Screens
If point A is the concept model, what's point B? Where do you go from here? Ultimately, concept models should frame a domain such that you have a good handle on the range and depth of information the web site needs to accommodate. If you're having trouble making that leap, from model to screen design, here are a few ideas to get you started:
Concepts as screens
Any node in the model might be a good starting point for designing screens. Pick one and decide how the web site should represent that concept.
Remember that nodes represent abstract concepts, generalizations across swaths of information. The "issue" concept in our comic book model can represent one of many different examples of a single issue of a series. Therefore, the screen we design to represent "issue" is a template or container: It has spaces in it to display information about a specific instance of the concept.
Some nodes adjacent to the concept you picked relate to it in some way. Your screen should show how users might navigate to that kind of information. How do users, for example, get from a single issue to a page about the whole series? How do users get from a single issue of a series to a page about related series? How do users get from a single issue to everything authored by the issue's writer? Or everything in the series authored by the issue's writer?
)
Figure 4.17 Identifying the insights gleaned from a concept model is one way to establish a set of design requirements. In this case, the page from the document also acknowledges what's missing from the model.
)
Figure 4.18 Questions about navigation, embedded in the concept model itself, provide a powerful way to (a) highlight the relevance of the model and (b) provide a mechanism for focusing discussions.
Concepts as metadata
Some nodes are descriptive, providing details about the concept. Issues have numbers. They are a chapter in a story arc. They might have a summary of the plot. All of these are potentially useful pieces of information, but not enough to serve as navigation mechanisms (they don't bridge to other concepts). Nor are they substantive enough to yield pages in and of themselves. Yet the concept model helps us see that they need to be represented on the main screen somehow.
Models to inspire structures
In the previous examples, we've considered the concept model to be the basis for the site's underlying architecture: Each of the major concepts translates to a template; the links between the concepts correspond to links between the templates. Site designs, however, may not be translated so literally from a concept model.
)
Figure 4.19 Some concepts make good metadata elements. In this version of the model, candidate metadata elements have been marked with a little tag icon.
For a recent project, I created a concept model that helped me look at the domain in a new way. Instead of designing a site structure driven by content type, I suggested designing templates based on lifecycle. To be specific, everything that passed through the system, regardless of its format or content, went through a similar lifecycle. The target audience wasn't concerned as much about format or content as they were about where something stood in the lifecycle: that was the factor that changed the decisions they made.
Can we do this for the comic book model? Does it suggest any other ways for structuring the information in a meaningful way? The model reveals some potentially useful structures and contrasts:
- Reading vs. collecting: These two activities are more than just use cases; they represent different relationships to comics. What's worth exploring is whether they can be served by the same web site and where the web site should be split to accommodate these two distinctions. Does an "issue" page template need separate tabs to display two different kinds of metadata? Do readers and collectors browse for comics differently?
- Character timelines: Working through the concept model helped me establish a clearer picture of the relationships between a character, its "mythology," the ongoing story lines, and the continuity between all of them. This is a situation unique to comics, especially mainstream comics. A single character can appear in multiple books at the same time. Most readers care about which story line represents the "canonical" history of their favorite character. Could we design an interface that focuses on character history and show the relationships between those timelines and the published issues?
Relationships as interactions
Finally, you could look at the relationships between concepts for inspiration on interactions. Verbs in the model may directly translate to actions users can take on the site. They might inspire functions or features you hadn't considered. They might shed light on the requirements.
These four techniques are hardly mutually exclusive. Picking one as the means for driving design does not mean the others won't offer equally useful inspiration.