Developing Web Site Documentation for Design and Planning: Concept Models

This chapter is from the book

Communicating Design: Developing Web Site Documentation for Design and Planning, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Communicating Design: Developing Web Site Documentation for Design and Planning, 2nd Edition

Learn More Buy

Presenting Concept Models

First things first: Ask yourself, "Do I need to share my concept model with team members or stakeholders at all?" If you're using it as a tool to get things straight for your own purposes, or with a small team, this may not be a formal deliverable: It will never see the light of the conference room. It may be more responsible to shield your stakeholders and other team members from this kind of document if it operates at a level of abstraction that would be difficult for them to comprehend without concrete examples.

If you decide that the concept model includes ideas that are essential for understanding the overall approach, think about whether you need to show the entire model. Is there an abbreviated version you can put together that boils the ideas down to just what's needed as prerequisites for the rest of the design? Alternatively, if the model yielded an insight or specific conundrum, you might assemble a separate diagram describing just the small piece.

Presenting a concept model means telling a story, putting the concept model into a context that team members and stakeholders can relate to. Your story needs to be grounded in reality, and this section describes several ways to do this.

Establish a Purpose for Meeting

The presentation should be driven by the purpose. With concept models, there are usually only two reasons why you'd present them: to prepare participants for more in-depth design discussions, or to hash out the model itself.

Preparing for design

One reason for presenting a concept model is to lay a foundation for the design, prepping the meeting participants for a more detailed discussion about the user experience. These meetings usually start out with, "I know you're eager to dig into the design, but there are some basic concepts we need to clear up before we do."

We could use our comics concept model (or a portion of it) to describe the design team's assumptions in designing the web site's interface. Those assumptions include answers to these questions:

• What are the most important categories of content?
• How do other types of content relate to those most important categories?
• What kinds of functions might users expect?

These kinds of meetings have at least one of these three key messages:

• This is a useful exercise because...: Be sure you understand how the concept model fits into the design process and where you're going with it next. Prepare a simple rationale for doing the concept model, and refer to it when the meeting loses focus.
• Some initial design principles or requirements: Pull out a few of the insights and use these as themes or talking points throughout the discussion. These insights should be positioned as design principles or guidelines: They are boundaries and constraints that help the design team focus their efforts.
• Some remaining questions about scope: Highlight the areas of the model that remain unclear, or which called into question the scope of the project. The model may have revealed dependencies that would make the established scope challenging. The model may have identified additional requirements not yet incorporated into the thought process.

Analysis of the concept model may have yielded some initial ideas about design—which content will get its own templates, what the information priorities are, a metadata model. If you're confident about your design decisions, you can use these as themes in the meeting. Otherwise, use them in the Communicate Implications section of the agenda.

Modeling together

The other reason to put a concept model in front of team members and stakeholders is to collaborate in its construction. In this case, rougher models are better because they lend themselves to feedback and discussion. It's important to come to a consensus about the underlying structure that supports a web site's user experience because it drives so many subsequent design decisions.

As described previously, concept models can help at any point in the design process. Building them collaboratively does not change this. You may come to an impasse in the design process, a clue that there's disagreement about the underlying assumptions, and use that as an opportunity to take a step back and facilitate a brainstorming meeting to flesh out the basic concepts.

In these meetings, establish three key themes:

• Our focus is the scope: That is, the purpose of the exercise is to establish the boundaries of the domain. We want to get our arms around everything that may be relevant to the design problem. We can always remove concepts later.
• Our interest is in what's missing: Participants should focus less on what's there and more on what's not there. They need to help identify concepts that may be important—even tangentially—and contribute to the overall picture of the domain.
• Abstract thinking is hard: Reassure participants that thinking about an information space in this way is not easy to do. We're thinking about the web site not just as a series of building blocks, but as a series of templates. Some templates can represent so many different things that their structures look so far removed from the actual content as to be of questionable value. This is OK, and it can be hard to wrap your head around.

The meeting structure following assumes you're preparing for design, not modeling together. If the purpose of your meeting is to present a skeletal structure for the concept model and engage participants in fleshing it out, you might skip steps 5 and 6. In these portions of the agenda, you provide details (you don't have any yet) and communicate implications (which would be premature).

Adapt the basic meeting structure

The basic meeting structure from the introduction is ideal for concept models. As you delve further, you are uncovering more details. Keep an eye on meeting participants; they may start to lose the thread if you get too abstract. In this case, you've reached the end of the useful life of this meeting. Wherever you are in your agenda, transition to soliciting feedback and defining next steps.

Refresh your memory on the timing of sharing diagrams (Table 2.2 in the Diagram Basics chapter). With concept models (perhaps more than any other diagram) timing is important because stakeholders' unfamiliarity with the models may add unnecessary challenges to the rhythm of your story.

1 Establish context

For concept models, which may occur early in the project, set the stage by explaining how this technique contributes to the design project. You can use this time in the meeting to clarify the parameters and boundaries you considered in putting the model together. Also provide a high-level description of your process—what sources you used, what it took to put the model together, and what you were attempting to capture in the model.

You can show the model, or the high-level version of it, when you conclude your context-setting introduction. This will set you up for the visual conventions, coming up next.

2 Describe visual conventions

Describe the model at a high level, first. The fact that the diagram consists of circles connected by lines may be self-evident, but it sets the stage for you to dig into the specifics.

If you've kept your model simple, limiting the range of styles for nodes and links, you may not need to say much more. If you've used a more elaborate set of styles, describe the types of contrasts those styles are meant to show.

3 Highlight major design decisions

It's now time to dig into the model. There are three broad descriptions you can offer before getting too deep into the details:

• Overall structure: Indicate the three or four main concepts that constitute the main pillars in the concept model. Describe the relationships between them, and how they form the main structure that supports everything else.

• Unifying theme: Describe the underlying story in the concept model. For example, the theme for the sample concept model is the two sides of the comics business. Models using the "value proposition" structure (see Table 4.9) have their theme stated clearly.

  Table 4.9. Three basic structures for concept models. Each has its own place, and may be a useful starting point if you have no specific ideas on how to initiate the model.

  Structure	Description	Use for...
  Hub and spoke	One concept rules them all. A central node from which everything else branches off.	Defining a single, central concept. Implying a site structure starting at a home page.
  Diad, triad, quad	A core collection of two, three, or four concepts defines the primary structure. Everything else branches off that.	Acknowledging the importance of a handful of concepts and showing how they serve as landmarks for an information space. Structuring a site around a few different "views."
  Value proposition	Three or four nodes forming a single sentence serve as a backbone for the rest of the diagram.	Stating a singular purpose, vision, or theme for the project and showing how other concepts support the theme.

• What's in and what's out: Distinguish the boundaries of the domain. This description is especially useful if you're trying to zero-in on scope, and you need to clarify that you've left some things out of the concept model on purpose.

Before moving on, this is a good opportunity to show the value of the model by describing insights that came from creating it. Some of these insights might include:

• New concepts essential to the experience: Through your research or brainstorming, you might have identified a concept that is a useful piece of information for users, or is a category that unites several other concepts together.
• New relationships between concepts: Concept models represent your priorities very clearly. Through modeling a domain, you make specific choices about what concepts to connect, and some of these links may represent a new spin on the information space.
• New perspectives on the experience: In creating the concept model, you may have stumbled upon a new idea for structuring the overall user experience. This may be a new navigation scheme or a new way to arrange the content templates.

4 Offer rationale and identify constraints

Meeting participants might still be noncommittal about the concept model, not sure why they're talking about circles and lines when (clearly!) there are bigger issues at stake. Use this portion of the meeting to reiterate the purpose of the model, how it fits into the project, and what you hope to get from the conversation.

Use this time during the conversation to describe research you did to feed the model. Indicate what sources you used to generate lists of concepts and identify potential connections between them. Such discussion may trigger ideas from participants on other places you can look to flesh out your understanding of the domain.

5 Point out details

Describing concept models in excruciating detail is useful only if you expect to get meaningful feedback at those deep layers. There's no need to hit every circle in the diagram unless you only have about a dozen concepts. Otherwise, use this time to point out a few of the detail areas:

• Novel concepts: If you've added any concepts that stakeholders might not expect to see, dig into these and be explicit about where the concept came from and why it's important.
• Insights: Assembling the concepts in this visual format may have yielded unexpected insights. Describe these areas of the concept model.
• Challenges: To transition to the next part of the agenda, you can draw participants' attention to areas of the model that imply difficult design challenges.

6 Communicate implications

For concept models, where the rubber meets the road is in how the model will lead to design. Most of this chapter is dedicated to creating the model in the context of a design project, so hopefully you'll have some ideas about what you're getting out of the model. At the very least, you should be able to describe at least one of these things:

• A better understanding of the domain: But merely saying that you understand the domain after so many hours of putting together a concept model is a bit of a letdown. Be sure you have something else to share.
• A better understanding of the target audience: Better, but why didn't you do personas?
• A prioritized list of requirements: This is good. The concept model helped you prioritize areas of the project: which parts of the site you're going to work on first. Why? The concept model told you to do it.
• A list of potential challenges: This is also good, and it shows you're thinking ahead. The concept model helped you identify relationships that will be difficult to communicate, concepts that will require lots of links, or processes that are not straightforward.
• An inventory of possible screens: This is best. The concept model yielded a set of concepts and relationships that helped identify a list of screens that you need to design for the user experience. It provided a foundation for the site's underlying structure.

When discussing concept models, you may need to jump ahead to this section: people may just want the bottom line. With concept models the conclusion is, "So how does this impact the design?" And there's no reason to save the implications for last if they represent the most important conclusions from your work.

7 Solicit feedback

You're interested in getting input on four things:

Table 4.10. A structured look at feedback helps ensure you get what you need.

8 Provide a framework for review

The next steps after a concept model discussion are all you, the design team. I can't think of an instance where I sent off a business stakeholder or developer with homework to review the model. It's an introspective tool, and we've let others in to see our thought process, maybe to validate it in real time.

But the lack of context when reviewing it "offline" would make it difficult for others to provide meaningful feedback (unlike a flow or site map or wireframes, which are more concrete).

Instead, clearly state where you're going from here.

Avoid newbie mistakes

Even the most concrete concept models can confuse participants. Unless they can draw a parallel to something in the real world, they may not understand exactly what they're looking at. And even if they do get it, they may not care.

Potential response 1: I don't get it.

Some people may just not get it, especially if the concept model dabbles in the really abstract. Models can represent categories of categories or tiny little blocks of data or information about metadata (which is information about information). They can use slight variations in visual conventions to represent different abstract ideas (arrows for navigation, arrows for transporting data, arrows for indicating semantic relationships). For people who are used to looking at spreadsheets, or the simple infographics in USA Today, these diagrams can be exhausting.

Before going into a presentation where you think you might get this response, boil the concept down into three sentences. If you're not getting anywhere with the diagram, whip out those bullet points. As you watch your meeting circling the drain, these three sentences can be a lifesaver, giving participants the essential message without belaboring the diagram.

The key here is to not make them feel dumber than they already do. To that end, you might say something like: "Why don't you take some time to digest this and give me feedback in a couple days? This model is important because it creates the overall foundation for our design work. While you're looking at it, keep the following three things in mind. (Insert your summary sentences here.)"

Potential response 2: So what?

Even if the meeting participants get it, they may not realize why it matters. You have two possible strategies in this situation: Try to show the connections between the model and the design, or simply cut the meeting short.

Cutting the meeting short is always an embarrassing and difficult tactic, but sometimes you have more to gain by avoiding conversation than forcing it. Since concept models tend to be highly abstract tools for designers to get their thoughts in order, the stakeholders may have little to gain by going through it.

Again, the key here is to not make them feel stupid. Try saying something like: "I think I've gotten everything I need. I appreciate your time. We'll take this feedback and incorporate it into the design. If you have further thoughts, let me know. Otherwise, the next time we talk we'll start to show you some of our design work."

Ending the meeting is a last-ditch tactic, and you should only use it if it's clear the stakeholders or other team members aren't interested in engaging at an abstract level.