Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Design

  • Print
  • + Share This
This chapter is from the book

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.



    Use for...

    Hub and spoke hupandspoke.jpg

    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 diadtriadquad.jpg

    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 valueproposition.jpg

    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.


Am I missing any concepts?

Do any concepts have more or less prominence than I was expecting?


Am I missing any important connections between concepts?

Are there connections between concepts that are redundant or unnecessary?


Did I get the overall story right?

Is this a good characterization of the domain?

Do I agree with the overall story of the concept model?


Do I perceive any other challenges?

Does the list of templates align with my expectations?

Does the sense of scale align with my expectations?

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.

  • + Share This
  • 🔖 Save To Your Account

Peachpit Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Peachpit and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Peachpit products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive:

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020