Most of my projects involve building content models, and I have a deep and abiding love for the process. I like teasing out the patterns and relationships in a big mess of content, then creating a structure that marries development, design, and business needs. I find it very satisfying, like putting together perfect rows in Tetris.
I’ve worked on plenty of projects that have issues that warrant the creation of a content model: a client wants more efficient governance workflows, or to reuse pieces of content across channels, or they’re building a responsive site and need a cleaner separation of content and display code. They’ve learned, or been told, that the answer to the mess they’re in lies in a content model. The problem is that a content model isn’t actually an end game. It’s not a solution unto itself.
A content model is an organizational tool. Expecting it to solve problems merely by existing is a bit like setting up a new filing cabinet in your office and being surprised when you come back a week later to a desk still covered in piles of receipts.
My projects run more smoothly when my stakeholders understand the bigger picture of what’s involved in converting to a new content model, and I’ve started to talk about content modeling as having four phases:
1. Auditing existing content and building the initial models
This is what most of us picture when we think of content modeling. A structural audit is how I learn the shapes and patterns in the content, and I translate that understanding into diagrams and spreadsheets detailing content sections, fields, and relationships.
2. Stress-testing the models
I do two kinds of stress-testing, and both are kind of tedious and extremely important. The first kind involves literally sitting around a table with subject matter experts—representing the needs of the content, business, development, and design teams—and walking through each model. Field by field, section by section, we discuss issues and adjust the model to better meet everyone’s needs. It’s a little arduous, and absolutely necessary. Bring snacks.
The second kind of stress-testing is a sample migration of roughly 10 percent of existing content to fit in the new models. The models are built based on a representative subset of real content, but a broader migration pilot project always reveals new issues that need to be addressed. A pilot migration also gives us solid statistics we can use to estimate time and energy needs for the full migration.
In a recent project, we had assumed we’d be able to glean the content of a teaser field from the current site, but through the migration test we recognized the need for a copywriter to rewrite most of that information. That same migration pilot also helped us identify which sections could be migrated quickly by any team member, and which sections needed slow, careful attention from a subject matter expert.
I think it’s important that this migration pilot is conducted by the team who will be creating and editing content moving forward. This gives them a head start in building their own intrinsic understanding of the content structure, and their insights about places the structure is falling short or is overbuilt are invaluable.
3. CMS implementation
I generally build CMS-agnostic models, meaning that I create fields and relationships in service of the content, without regard to how difficult those choices will be to implement in any particular CMS. Bully for me, but once a CMS is chosen, we’re all boarding the express train to Compromise City. During this phase I work closely with developers to make adjustments so the models can still do their jobs within the confines of the CMS’s capabilities.
This phase also involves building customized help and content guidelines directly into the CMS interface, because that is my jam.
4. Getting the content into the CMS
This is the dirty secret of content modeling: someone actually has to move all the content from those dusty receipt piles into its new tidy home in the filing system. There are some nifty advances being made around extracting data using algorithms, but for now this work needs to be done by people. Given my druthers, I like to have the team move existing content directly into the models in the new CMS, which familiarizes the team with the new interface and helps us find places we could improve the authoring experience on their behalf.
Having the team move old content directly into the new CMS is not always a realistic plan, because of scheduling and timing, and other complexities. So often we do half-measures, having the team move content into spreadsheets and then auto-importing those to the CMS, or hiring interns to do the bulk of the migration labor. This phase can take a long time, but content migration is a really great way for everyone to get familiar with the CMS administration and workflows long before launch.
5. Shampoo, rinse, repeat
I lied. I said “four phases,” but after those four are complete, the final, endless phase is maintenance, iteration, and improvement. In the same way we promote doing regular content, performance, and code audits, we should also work with our teams to do regular content model audits, reviewing the fields and relationships to make sure they’re still aligned with design, development, and business needs.
I would love to be able to sketch out a content model, quietly close my laptop, and come back the next morning to find all the content humming along in a new and beautifully flexible CMS implementation. For the record, I would also like a mini-donk. Even without magical content gnomes (or tiny equines), recognizing the distinct phases of modeling work has helped my projects run more smoothly. I’m better at getting the right people at the table for the right discussions, and budgeting appropriate energy and time across the entire project. Talking about the phases also helps my stakeholders understand the larger picture of a long-haul content modeling initiative, and helps all of us make decisions that move us closer to meeting our business and content goals.
7 Reader Comments
Amazing post here. The models are very interesting and providing a great knowledge. I agree with you that stress testing is very important. It will make the model better.Thank you for sharing the post
I just recently started following ALA and have read some of your articles, which I find great.
I got this question, though: every single time I read about content projects I come upon the “content audit” phase, which, as far as I understand, requires previously existing content in place (doesn’t it?). So, what about completely new content projects, i.e., websites being built for a new company? Where do you start when there’s no audit to be done? Just built the initial models from scratch?
Thanks a lot!
Astonishing post here. The models are exceptionally intriguing and giving an awesome learning. I concur with you that stretch testing is vital. It will make the model better.Thank you for sharing the post
David, starting from scratch on a project is both wonderful and horrible. Wonderful, because clean slate! Horrible, because all those real-world limitations around copy quality and data integrity still exist, but they’re only going to reveal themselves over time.
The best luck I’ve had has been replacing the migration pilot with a new-content pilot, and basically putting a full stop on the project until we have at least 10 *real* entries of each type of content. You’ll uncover a bunch of low-hanging problems (like “turns out we have no author headshots” or “some of our events span multiple days”) which is better than nothing. Then, you get to skip Step 4, but plan to spend a bunch more time on Step 5.
Good Content is always helpful for very Blog site. you have suggest good ideas how to write quality content and you explained very useful tools. thanks for sharing.
Nice article. Content is in the soul of marketing activities that speaks louder than the sales team. It is important to consider it as a part of core business strategy. For better content, make sure to understand business offerings and write a personalized content. Once content is decided, the next big step is to select a tool that manages content. Web content management systems like WordPress, Sitefinity, Joomla, Drupal etc. can make the job easier, however it is difficult to choose a system that fits your business strategy in long run. Consider flexibility, scalability, security and reliability before finalizing a content management system. More simple the user face, better it is. To ease the job, allows different users to access certain blocks of websites and allow them to manage the content.
nice article.. the content of a certain activity is the center of what it means.. bodas originales
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions