Why to create a content model before redesigning your nonprofit’s website
Recently, my team at IREX worked with colleagues to create a content strategy and redesign our website. During the redesign, one of the most important steps was drafting a content model.
The content model that you see above helped us save countless hours during and after the redesign. Months later, we’re still using our content model to improve results for the organization and our users.
Content models aren’t as intuitive or widely understood as sitemaps, wireframes, or design comps. But I’d argue that they’re even more important for helping organizations build the right thing. I’d like to share a bit about our process to encourage other nonprofits to embrace content modeling, too.
Our challenge: How could we tailor information to users’ needs while saving staff time and funding?
Before creating a content model, we learned about our users and defined our objectives. We decided which groups of users to prioritize, and we thought about how to meet their needs in a way that would advance our organization’s mission.
Through a few rounds of quick, inexpensive user research, we learned that each of our priority user groups wanted to view similar types of content about IREX in order to achieve their own objectives. We called these content types success stories, insights, resources, news, people, and projects. We designed each content type to meet a distinct user need.
However, we also confirmed through the research that a typical user didn’t want to see all of our success stories, insights, resources, news, people, and projects. Instead, individual users were more interested in quickly viewing a subset of content that corresponded to professional areas of interest. Here are a few examples:
Some users were primarily interested in our work within a particular project or country.
Other users needed to consider our work within larger geographic regions, such as Asia, the Middle East & North Africa, or Europe & Eurasia.
Different users cared about different issues, such as global education, media development, youth development, or technology for development.
Some users needed information about our work within several regions, countries, and issues.
Users often knew us for only a single issue or region, even though we were active in other issues and regions that mattered to those same users.
In other words, our users wanted to view collections of content that were tailored to their individual needs, and they needed to discover related content that matched their interests.
That posed a challenge for us. Our organization works on 8 main issues in 5 regions of the world. We have about 50 active projects, and we wanted to emphasize our work in 12 featured countries. Let’s say that we set up a page for each one:
8 issues + 5 regions + 50 projects + 12 featured countries = 75 web pages
In that case, a single piece of content would often need to appear on multiple pages. For example, a success story about training teachers to improve their students’ computer skills in Tunisia would need to appear on 1 region page (“Middle East & North Africa”), 1 country page (“Tunisia”), 2 issue pages (“Education” and “Technology”), and 1 project page.
That would mean manually adding the success story to 5 pages. It would also mean eventually removing it from all 5 pages, for a total of 10 manual changes. Multiply that by the number of pieces that we manage in a year and the number of manual changes would quickly become unmanageable.
We knew that we couldn’t spare the staff time to manually keep dozens of content collections up to date. And given our budget and our industry, we knew that it wasn’t feasible to set up an Amazon-style recommendation system that would automatically recommend content to users based on their individual profiles. We needed a low-cast way to tailor collections of content to users’ needs while saving staff time.
Content models to the rescue
We solved this problem by creating a content model. The content model helped us do the following things:
Decide as a team which types of content needed to automatically appear on which pages and how long the content should remain there.
Identify what metadata to build into the content management system for each content type in order to enable automation.
Establish simple, testable business rules for the automated components.
Determine which types of content our editors should be able to manually add and remove (to allow for greater editorial control, reduce the cost of building and maintaining the site, or both).
Find ways to simplify the system to reduce the workload and costs for designers, developers, and editors, during and after the build.
Build in an iterative way by identifying which pieces of the system were essential for the first release, which pieces could wait until subsequent releases, and what architecture would facilitate future releases.
In The Language of Content Strategy, Cleve Gibbon writes that a content model is “a formal representation of structured content as a collection of content types and their interrelationships.” Creating a content model, he continues, “provides a shared vocabulary for content that communicates its essential structure and meaning, making it easier to execute a content strategy.”
In other words, by documenting how different types of content relate to each other, teams can reach a shared understanding of how to design and engineer a website so it uses and reuses content in a strategic way. This reduces ambiguity, which helps front-end designers and back-end developers to design and build the right things.
In our content model, for example, we specified that a single success story could appear on region pages, country pages, issue pages, and project pages:
The success story would only appear on those pages under certain conditions. For example, a success story about a project in Tunisia would appear on the “Middle East & North Africa” region page but not on the “Asia” region page. Newer stories would appear before older stories, and editors could override the automation if necessary to manually select content that better aligns with our editorial calendar.
These decisions about the content model had implications for stakeholders and team members:
Senior managers within various business units needed to agree that the organization should create success stories and that subject-matter experts would help to write and review drafts of success stories.
As the content strategist, I needed to consult with business units and conduct user research to define success story as a content type. (I used this template for creating content types.) I also needed to document the rules for displaying success stories on corresponding pages. For example, how many stories should we display? Should we display the most popular, the most recent, or something else? Should they automatically appear, or should they only appear after an editor has manually selected or approved them? Do users want or need a way to view older stories as well? Under what conditions should we archive stories? Should the archiving process be manual, automated, or something in between?
The front-end designer needed to include placeholders for success stories in the wireframes and design comps for region, country, issue, and project pages. The design needed to reflect the decisions that the team made about the desired user experience and author experience.
The back-end developer needed to set up the content management system so the success story template included metadata fields for region, country, issue, and project. The developer needed to program the business logic into the CMS so it would display the right collection of success stories on various pages.
The project manager needed to confirm whether the team could actually build this functionality, given the available timeframe and budget, without incurring too much technical debt or UX debt.
Content creators needed to agree about what makes a success story different from an insights piece, a resource, or a newsroom piece. Content creators also needed to commit to providing region, country, issue, and project metadata for each success story—otherwise, the system wouldn’t work.
Creating a content model prompts teams to address these types of questions in a systematic way for each content type. This helps teams think through problems early in the process and avoid last-minute delays.
The above diagram is a high-level content model that shows content types and how they relate to each other for a particular website. Teams can also use spreadsheets to document more details. Here’s an example for the success story content type:
In this excerpt of a content model, the success story content type in the content management system would have fields for each attribute. For example, each success story would have a title, an author, a posted date, a system date, a photo, body text, and other attributes. Meanwhile, the attribute type column specifies what type of content the CMS should accept for each content-entry field. For example, title, author, and body should be text fields while posted date and system date should be date fields.
Content model spreadsheets can include many additional columns to communicate requirements, display rules, business rules, editorial rules, personalization rules, output channels, and more. See the Content Strategy Alliance’s templates and Meghan Casey’s Content Strategy Toolkit for examples. From a content strategist’s perspective, content model diagrams tend to be more helpful for communicating with less technical team members and stakeholders while detailed spreadsheets tend to be more helpful for communicating with developers about nitty-gritty details.
Do I really need to create a content model?
Maybe not, if you’re building a simple brochure website that calls for only a few static pages. But if you’re creating a moderately complex site—one that involves tagging, sorting, filtering, personalizing, reusing, or hiding content based on business rules or users’ input—then it’s likely that creating a content model would help.
Teams often skip the step of creating a content model and go straight to designing the interface. This “shortcut” is tempting because it avoids internal politics and difficult questions, such as Do users really need all of these content types? What is the purpose of each one? What sets them apart from each other? Who will create the content? How exactly will the content behave online? Are we creating the site based on evidence or assumptions? How will we know if the content is achieving our objectives?
Attractive visual designs can temporarily disguise the fact that an organization hasn’t learned about its users, set clear priorities, or decided which types of content to create, what those content types should achieve, and how the content should appear. But when teams don’t address these issues, the problems inevitably become apparent shortly after launch, when employees can’t agree on what to publish and users can’t find what they need. It’s usually much better to address these issues early in the process. The rest of the project will go more smoothly if you do.
Learn more about content models
For detailed guidance about creating a content model, I recommend Cleve Gibbon’s Content Modeling Series, which describes the elements of a content model, the process of creating a content model, conventions for designing content model diagrams, and terminology for content modeling.
For more information about content modeling and examples of content models for different types of websites, I recommend the following resources:
Rachel Lovinger’s “Content Modelling: A Master Skill,” which includes an example of a content model for a music website.
Mike Atherton and Carrie Hane’s “Designing Future-Friendly Content: Modeling Structure for Every User Interface”, which gives the example of a domain model and content model for a conference.
Jeff Eaton’s slides from his Confab Intensive 2016 workshop “Recoupling: Bridging Structured Content and Design,” for examples of content models from NPR, MSNBC, NBC Universal, The Guardian, Angie’s List, a cross-channel recipe book, and an exhibit at the University of Oklahoma Libraries.
Sara Wachter-Boettcher’s Content Everywhere: Strategy and Structure for Future-Ready Content, which includes two content models (figures 3.2 and 3.3) for recipe websites.
Karen McGrane’s Content Strategy for Mobile, which includes a content model for a radio show.
Ann Rockley and Charles Cooper’s classic Managing Enterprise Content: A Unified Content Strategy, which provides an extended example of how to design and implement a content model across an entire organization’s online and offline channels.
The opinions expressed on this blog are my own and do not express the views or opinions of my employer.