How to stop ostriching about content modeling: Documentation for the disorganized content strategist

Hooooo boy, did I ever not want to do this. I love writing, see, and before a couple of weeks ago, whenever I heard the phrase “content modeling,” I quickly excused myself to refill my drink and also run away forever. Content modeling is a skill on the opposite end of the content strategy spectrum from writing microcopy, on which my stance has been public for some time (I prefer it).

Despite my avoidance problem, I reached a point in a project where I realized I could no longer stick my head in the sand with regard to content modeling.

What’s a content model?

An extremely basic, high-level content model example for a music website by Rachel Lovinger

A content model usually looks kinda like a flowchart, decision tree, or mind map. It can be as high-level or as granular as you need it to be, which also makes it challenging to construct.

A content model wants to do 3 things:

  • document all of the different types of content you will have for a given project
  • define the elements of each content type and the relationships among them
  • take intention, stakeholder needs, and requirements from the user experience to a content management system

For me, that last point was the real kicker.

Why would a content strategist make one?

Content modeling—like the rest of content strategy—is typically in the purview of web content. A content model might loosely resemble the information architecture of your site, and it might be fairly easy to chunk out the different types of content you have (articles, newsletters, lead story element, and so forth).

On the other hand, I’m a product UX content strategist, so once again I needed to adapt the blueprint a little bit. I’m working on a project in its infancy, with designers, engineers, product folks, IA folks, folks so deep-state at Adobe that I’ve yet to understand what they do, etc. Everyone agrees that this project requires a flexible content delivery system that can be personalized to the user and their journey, so it’s time to start thinking about a content management system (CMS).

You want everyone to be on the same page about what the people who use this system will need to be successful. What will your content strategy and creation team need to view from your system and enter into it? Will your types of content lend themselves better to a CMS out of the box, an Ichabod Crane version, or a custom-made, custom-paid solution? Your content model will help influence that choice.

Additionally, it’s worth noting that at this early stage, microcopy isn’t gonna help me prove the value of content strategy, but content modeling will.

How do you do it?

True to the spirit of this series, I just made my first one, and I’m about to tell you how I fumbled through it.

  1. Face your fears. Start by recognizing the unavoidability of the situation. As we all know, I tend to run away from strategic organization and similar tasks. But alas, I wanted to keep my job and contribute in a real way to the project at a time when microcopy explorations would be a bad use of time.
  2. Give yourself a crash course on content modeling. If you already know what it is and how to do it, I don’t know why you are reading this article. Otherwise, Lynda.com has a course, and Slideshare has a couple of resources. A List Apart has several excellent articles on the subject, as does Cleve Gibbon. Finally, I’d be remiss if I didn’t mention Jeff Eaton, from whose lips I first heard that dreaded phrase a couple of years ago and whose podcast you should listen to if you are a podcast person (sorry, I am not).

After this, you should have greater familiarity with:

  • the different levels of content you should consider: elements, types, modules, and packages (you might not need all of them for your model)
  • how to prioritize different content bits
  • how an ideal CMS for your project might look
  • author instructions you’ll need to give to folks actually using your CMS
  • other stuff, perhaps very relevant to you or not relevant to you at all, it’s a big discipline, whatever

3. List out every content piece you can think of. Your goal is to go as small and as large as you possibly can in this stage, from a content piece like “verb phrase” or “headline” to one like “home screen” or “tutorial.” Enlist your team to make sure there aren’t any content bits falling through the cracks. Name and define them (loose definitions are OK; you don’t need to build a whole ’nother glossary). Visuals are great to have here so that everyone knows what you’re talking about when you say “video player.”

4. Group your content pieces. Start organizing your list. What bits go with what other bits? For the purpose of this piece, I’m defining “content types” as the smallest pieces of standalone content that can live in one view, “elements” as the bits that go into those types (text fields, images, things that can’t just pop up with no context), and “packages” as collections of content types.

So what elements are you looking at, and how might they come together to form a type? I found that, for example, the “video player” content type required a video (duh), a preview image, a headline, a subhead, tags to help it appear in search results (metadata!), and viewing stats. But a video player might live in a larger content package like a “panel,” alongside a “tutorial” (which in itself has several different content types and elements), additional header and subhead text, links, and so forth.

I did have potential packages from design to place everything into. You might be so lucky, or design might just take after your ideas instead.

5. Spare a thought for metadata. What consistent fields or attributes might items of the same content type share? For us, the “video player” might need metadata of the topic, product, level, and video duration. Metadata can play a larger or smaller role in your model, depending on who else is involved in the project, but do be mindful of its existence.

6. Map it all out. Don’t fret too much over this. You’re not asking your content model to marry you (unless it’s, like, really great, in which case please send pics). Like most other content strategy documentation, it’s supposed to change over time. I used many, many sticky notes, arranging and rearranging and drawing and writing “opt.” next to optional things. Then I drew a rough outline on an actual piece of paper (yes, I hate me, too) and then replicated it in a Google Sheet. I exported that spreadsheet as a PDF before drawing the relationship lines: For each occurrence of a content type, a line left to right signifies a one-to-one relationship whereas a fork denotes a several-to-several relationship.

I don’t like using sticky notes because I like to save trees, but I have found them helpful at this stage because you can mix and match things, group them in different ways quickly, and move them around in front of you, like some kind of weird Sharpie-toting Dr. Strange.

7. Share far and wide. Or merely with your team, whatever. They’ll probably have some feedback and disagree with you on some points, so it’s up to you whether you make changes or simply put the content hammer down. Emphasize that this is meant to be a descriptive document that lives and breathes and grows and is basically your son.

Here’s what mine looks like. Is it final? No! But yours could look like this! Or probably better.

8. Write your author instructions. I haven’t done this yet, haha! But once we get rolling on the CMS, I will denote stuff like field name, type (dropdown, text, WYSIWYG, etc.), image resolutions, and character counts.

Boom, clap, the sound of your model / the sheet goes on and on and on and on and!

So what mean stuff do you have to say about my li’l model here? I accept accolades as well. Next time I’ll try to get to frameworky stuff but I wanted to write about this before I forgot!