What to Include in a Content Ecosystem Map

We’ve learned what a content ecosystem map is and why it’s necessary, so now let’s look into what the map actually needs to include.

What to Include in a Content Ecosystem Map

Editor’s note: This post is part 2 of a series on content ecosystem maps. Part 1, part 3, and part 4 are also available for your reading enjoyment.

Subscribe to the Brain Traffic newsletter!
Get more valuable content strategy articles like this one delivered right to your inbox.

Thanks for subscribing!
Important:
Please check your inbox for instructions on how to confirm your subscription.
Oops! Something went wrong while submitting the form.

If someone asks you to describe a forest, you might start with the obvious: Trees. Birds. Dirt. Worms. Look deeper, though, and you’ll find that there’s a tremendous amount of stuff that makes a forest a forest. There’s big stuff you just didn’t think of (like the sun) and little stuff you didn’t even know was there (like funguses that break down wood). Natural ecosystems depend on every component, big and small, working together in harmony.

A similar thing happens with content ecosystems. Stakeholders are usually only aware of the big picture—we’ve got a website, it runs on Drupal, there’s a social media team, we have a style guide somewhere. And while that big picture might be fine for them, a content strategist needs to be an expert on the entire content ecosystem. You need to become a content ecologist.

To map your content ecosystem, you’ll start with a list of nouns. Each noun represents a thing or concept that’s part of your content reality. This process can be a little overwhelming, so I’ve organized some categories of common components, big and small, that I often uncover in my own work as a content ecologist. Let’s go!

Channels

Sites. Channels. Endpoints. Distribution nodes. Whatever you call them, these are the places that your content “goes.” Most organizations underestimate how many channels they have—sometimes by several orders of magnitude.

Deciding what is and is not a channel is a useful exercise in and of itself. (Hint: A lot of domains and sites your org maintains are probably not channels because you’re not publishing anything to them—a vanity domain name for a marketing campaign, for instance.)

As you refine your map, you may find it useful to distinguish owned channels from public channels, internal from external channels, sites from social media, and so on. Be sure to look for the channels-within-your-channels, too, like a newsroom on the corporate site or push notifications from your mobile app.

Here’s a get-ya-thinking list of things that could be channels:

  • Branded social media accounts
  • Personal social media accounts
  • Homepage notification banner
  • App store changelog
  • Email newsletters
  • Marketing landing pages
  • Blogs on owned websites
  • Blogs on hosted platforms (e.g., Medium, WordPress)
  • In-product notification areas

Content types

If you already have a comprehensive content model in place, this will be easy. If not, ecosystem mapping will help you get your head around the content types you have.

Content types are just what they sound like: types of content that you publish. Press releases. Explainer videos. How-to articles. Product listings. You get the idea.

It’s probably best not to overthink these. Be accurate but not perfect. And don’t feel like you have to include every content type for every channel if it doesn’t add useful detail to the map. Social media updates might be sufficient, for instance, as opposed to listing out tweetsFacebook postsInstagram photos, etc. Then again, listing all of those out might be just what you need!

Technology

This is often uncharted territory for content strategists. There’s a lot to keep track of in content land, and sometimes it’s easier to just ignore the technology side of things. But even if you’re not planning on changing your tech stack, it can be very revealing to see all of the software and services that power your web presence visualized together with the teams responsible for maintaining them and the channels they make possible.

Obvious candidates include:

  • The CMS for your primary website
  • DAM or other media/image hosting tools
  • Project/production workflow management tools (e.g., GatherContent, JIRA)
  • Social media management tools (e.g., Hearsay)
  • Collaboration tools (e.g., Google Docs, Slack)

Some potentially less-obvious technology components to consider:

  • Web infrastructure services (e.g., domain registrars)
  • Web hosting (don’t forget about pre-production/testing servers)
  • Third-party media hosting solutions (e.g., Brightcove for video)
  • Form/survey/contact/newsletter/search integrations
  • Custom scripts and applications for QA/localization/internationalization teams
  • Databases
  • Code repositories
  • Pattern libraries /design frameworks

It’s not necessary to list every single technology component all the way down the stack (though your tech team may well want to do that on their own). Include what’s necessary to capture the essence of your content reality. Listing out every single WordPress plug-in, for instance, may not be a level of detail that has relevance for your content efforts.

Workflows and processes

Organizations have all kinds of processes in place to get the content work done, but many of them have not been named and clearly articulated.

One big benefit of naming your workflows, processes, and other similar procedures is having more diplomatic and effective conversations about how the work is getting done. There’s a subtle but important difference between “the account reps aren’t doing a good job” and “the client onboarding process isn’t working well for me.”

Some common categories of processes and workflows:

  • Content production workflows
  • Onboarding workflows (for clients, customers, employees)
  • Project intake processes
  • QA and editorial processes
  • RFPs, CFPs, and other types of calls for submissions
  • Weekly/quarterly/annual reviews
  • Operationalized meetings that result in decisions (such as a monthly editorial meeting)

Standards and policies

The standards, policies, rules, guidelines, values, principles, protocols, and other such stuff that govern your content reality can be mapped as the documents that contain them. Say you have a house style guide for writers, and otherwise default to the Chicago Manual of StyleXYZ Corporation house style guide and Chicago Manual of Style could both be concepts connected to, say, writing guidelines. You could then connect these guidelines to the content that they govern, or perhaps to the team that maintains them.

Some common types of standards and policies to consider mapping:

  • Visual brand standards and other visual design guidelines
  • Content principles and content strategy statements
  • Organizational vision and mission statements
  • Internal and external accessibility guidelines
  • Security and privacy policies

Sometimes our policies are published to internal and/or external audiences. This is something you can articulate in your map. Be careful not to conflate the policy itself with a web page that the policy is published on.

Products, brands, and services

Get ready for some arguments! What’s a brand? What’s a product? What’s a service? What’s a customers-can-buy-it product versus our we-treat-them-like-products product? And what do we call those things? Ack!

You might also find that there are sometimes dozens of discrete things that all share the same name—especially if you’ve got some sort of cloud-based software-as-a-service product that supports multiple platforms and devices.

When in doubt, make a list of all the stuff you use proper nouns to describe. You can hash out exactly what kind of thing it is during the mapping process.

People

Mapping people and teams helps you tell a more complete story of your content ecosystem, and helps you avoid thinking about publishing in purely technical, website-oriented ways.

The people nouns on my ecosystem maps tend to fall into one of these categories: rolesteams, and audiences.

Roles are typically internal positions and responsibilities. They could be specific job titles, like Senior Content Strategist, or project roles, like writer.

Teams are groups of people with similar interests (discrete from your audiences). They could be formal teams, like Enterprise Content Strategy or Customer Support, or informal groupings like faculty members or executive stakeholders.

Audiences are just what they sound like—groups of people, internal or external, who are interested in a particular topic or use a particular channel. How you think about and categorize your audiences can be extremely revealing. As a content strategist, I prefer the lens of audience as opposed to, say, customer or persona or market. You may still need to map all of those groups, too, but thinking about the audiences for your channels discretely from the customers for your products tends to be a more truthful map of your content reality.

What about individuals? For folks like the CEO or other high-profile folks who are part of your content ecosystem, it’s good to articulate their role as a brand differently than their role as a stakeholder. I tend to treat their stakeholder role like any other role (so for me that’s CEO instead of Kristina Halvorson), and treat their brand like any other brand/product.

Wrapping up

Seems like a lot, all laid out like that, doesn’t it? You’re wrangling content chaos, my friend, and nobody said it was going to be easy! The good news is that once you get going you’ll find some momentum, being able to map as much from instinct as from research. After all, there’s already a map of sorts in your head. Hopefully, this article will help you start putting it down on paper.

Keep in mind that these categories aren’t comprehensive. At the end of the day, you’re making a map of your content reality. Include what makes sense and leave out what doesn’t. Good luck, and remember to pack a snack!

Scott Kubie is the lead content strategist here at Brain Traffic and the author of Writing for Designers from A Book Apart. Scott has focused on the content side of digital experiences since 2009, and was the first UX content strategist at Wolfram Research. He grew up in rural Nebraska, and studied electronic media and journalism at Drake University.

Subscribe to our newsletter.

Get valuable content strategy resources and insights delivered right to your inbox.

Thanks for subscribing!
Important: Please check your inbox for instructions on how to confirm your subscription.
Oops! Something went wrong while submitting the form. Please try again.