How much time do you spending mapping out the the content types for your new content management system (CMS)? You, the content strategist, the web manager, the content manager, the person who is responsible for governing the website. Not the CMS developer. Actually, yes, you too, CMS developer.

None
A couple hours
A little time here and there

If your answer is any of these, you probably also know the pain of either not getting what you wanted or having to redo your work. At the end of the project. When you're behind schedule. Reaching the end of your budget. And just want to be done with the whole thing and get it launched. I'm sorry!

However, if you answered "countless hours" between the strategist/manager, designer, and developer, then you are on to something. You may know the ease in which you enter content into the CMS and have it display pretty much the way it was intended. You confidently tell your client or colleagues that you're on budget and will launch on-time. You know exactly how much work you need to do because it's all laid out in front of you in a beautiful spreadsheet (or Airtable or whatever you use to document your CMS specifications and content inventory).

We've spent many hours over the last few weeks working with a client, along with their designer and CMS developer, planning how to set up the content types. And that was after the countless hours we spent creating a content model with input from the stakeholders who own the content. And an hour or so setting up draft specifications so we had something to start with. Here's why it takes so long – and how that will benefit everyone as we build the website.

A peek inside a planning meeting

This was the first time we'd worked with this team, so we started off gently: just one content type. It was also the most complicated content type. Why not start off with the hard stuff and get it out of the way? We scheduled an hour. It took us an hour and 15 minutes.

Ahead of the meeting I'd spent about 45-60 minutes creating the draft of the specs based on our knowledge of the content and samples gleaned from the existing site. I noted the field name and field type along with questions for the client (web manager) and developer.

The columns of our content type planning worksheet.

Some of the questions and discussions that we hashed out in this meeting:

How do opening hours vary? Do we need to store different hours for different dates? Days of the week? Seasons? Turns out the variety of opening hours was vast enough that we made it a rich text field. There was no reason to make it a date/time field because it was information for the user that didn't need to be sorted or filtered by time or date. What could have been super complicated became simple and flexible.
How does the location need to be displayed, sorted, and filtered? We spent a lot of time on this and ended up with a geolocation field to be used on a map as well as a location taxonomy with 3 levels, each of which has separate selection criteria. It took all 4 of us to determine this: the web manager to know how users want the information, the content strategist to ask the question in the first place, the developer to know how the CMS could handle this complexity, and the designer to think about display possibilities.
Did a set vocabulary exist for certain fields that would allow us to create a select list? In some cases yes (Season - there are only 4, but we need to select multiple) and in other cases no (Accessibility Information - it varies too much to account for each situation.)

Through these discussions, we made decisions that would affect every aspect of the project – including stakeholder buy-in.

After the meeting, we spent about 15 minutes cleaning up the sheet to make sure it made sense to everyone who looked at it later. All told, that one content type took over 2 hours to create in a spreadsheet. You might be thinking, "That's ridiculous! Why would you take all that time to do that for one content type?" Here's why...

Getting back that time and more

We cannot tell you exactly how much time this will save during the implementation of the CMS and content entry, plus in QA, content creation, design, usability, and acceptance. But we can tell you it is more than the time you spent planning. Here are some of the things that won't happen when you take the time to plan your CMS build:

Having developers go away with wireframes or a list of fields they weren't involved in creating and coming back a few weeks later with the declaration that the CMS is ready.
Having to redo fields or relationships - or even whole content types - because the developer made a wrong guess about what was meant by a comment on a list or wireframe.
Finding exceptions to what you assumed was the rule for that content type after entering several dozen or hundred pieces of content and now you've got to go back and change everything to fit the exception.

There are some additional efficiencies created by having a collaborative planning process:

Content, design, development can all be done in parallel with confidence.
Perhaps a junior developer can do the CMS set-up, increasing margin, and freeing up senior developers for custom work.
Ongoing QA and adjustments, which prevents a huge bug list at the end of the project.
The designer knows why we made certain decisions and can plan the interface accordingly.

Tools for this planning process

To be sure, we did not spend this much time on each content type. Because we'd discussed some of the finer points of the content early, we could apply decisions to similar attributes of other types. We got 5 content types done in our 4th hour-long meeting and are even finishing a couple by inline notes and brief Slack discussions. This client has about 25 content types, which we divided up over 6 meetings to limit the stress on our brains as well as our time.

Google Drive is our friend and we couldn't do this otherwise. In this instance all 5 of us are in different cities. We got on a conference call, all pulled up the Sheet and started our discussion, each of us making notes to ourselves that we'd need later. If you're new to this process, here's a template you can use to get started; modify for your particular CMS.

We are using Craft CMS for this project. But the process works for any CMS that allows for structured content. I've done it for Drupal, WordPress, and Ektron. Some CMSes even let you work directly in the CMS - Contentful (this one also lets you do visual modeling). You can also use the same structure in GatherContent if you use that for pre-CMS content production.

This is a tried and true process. Developed with a specific team many years ago, but it's transferred to many other teams since then. And this new developer partner? He said it best: "I would definitely say this approach does end up saving quite a bit of time, as people actually have to plan both the content and the types of content that are needed."

Do you have tools or tips for content type planning? Share them in the comments and let others benefit.