So Happy Together
(Content Strategists and Project Managers are)
The dust has finally settled on “CMS Mythbuster May” -when we attended, and spoke at, CMS Expo, JBoye, and Confab. What a month! The CMS Myth team has had some time to relax and reflect on everything we learned, which was a lot. One theme I keep coming back to is how much, as a project manager, I appreciate the rapidly emerging discipline of web content strategy.
Ironically, after more than ten years building CMS driven websites, there is one thing I wish people were more aware of: content matters. Sounds silly right? After all, the ‘C’ in ‘CMS’ stands for, well, content. You would think it is all anybody would be talking about. However, project stakeholders are often so wrapped up worrying about technical risks or marveling over new designs that content can nearly be forgotten or worse…Treated as an unimportant ‘detail’ to be figured out later.
If you are a project manager and notice that nobody is thinking about the content in the planning/discovery phase of a website design, redesign, or CMS migration, this observation can be dropped right in the certain/critical square on your project risk matrix.
Fortunately, as the project manager, you do have the power to set things right. Your secret weapon is your ability to specify the deliverables you deem necessary to support a successful outcome. In support of this goal we here at the CMS Myth thought we would consult with the experts and determine what are the absolutely critical, content-specific project deliverables. That’s why I had a chat with Margot Bloomstein while reading her book Content Strategy at Work, before drafting the following list:
Note: I believe the following list represents the bare minimum, requisite activities necessary. It is not meant to be exhaustive. You should consult an expert for a plan that successfully meets the individual requirements of your unique opportunity.
- Inventory and assessment of Web content in preparation for a redesign or CMS; (this article primarily focuses on this type of audit).
- Inventory and assessment of all content in preparation for a unified content strategy; (the information contained in this article is relevant to this larger-scale content audit, but it is not complete).
I believe it is important to lean forward into the second definition. This increases the scope to include details like error messages and email notifications, all too often left for engineers and developers to sort out. However deep you go with the content audit, it is as an absolute, 100%, must-do activity for any website redesign or migration project. This can’t possibly be overstated. To be useful the content audit must include the following components:
- A complete content inventory
- A qualitative content analysis
- Content template definition
The content inventory should be viewed as a living project document which evolves through the design process to include content objects needed for the new site, how they will be sourced, and when they are due. Project managers will love the content inventory because it is almost exclusively created as a spreadsheet.
The qualitative content analysis can be scaled up or down depending on the size of the project (and the budget). The purpose of this activity is to evaluate the content. The initial pass should be used to determine what, if any, content should be eliminated completely. This might be because the content is orphaned or obsolete. The second pass should be to prioritize the importance of what remains.
I’ve added the content template definition to the ‘essential’ content audit based on my own experiences. Similar to a data schematic, the purpose of defining content templates is to list the various unique content objects within the website and identify their constituent parts.
Content template definition is important because it establishes the fields necessary to make up the various, unique content types. This knowledge will inform user experience wire-frames and eventually the CMS build out. This activity has traditionally been left for the user experience architect to hammer out with wire-frames but I believe this is a mistake. User experience is more traditionally (and rightly so!) focused on the design implications of how users interact with the system while the make-up of unique content objects is fundamentally about the content.
Once the content audit is complete the project stakeholders will know a lot about what content does and does not exist, who is responsible for the content, and roughly what the content looks like. Armed with such knowledge the experience design team will be prepared to proceed with information architecture and user experience. In the meantime the content strategist can turn their focus toward aspirations for content by conducting a message architecture exercise.
— Margot Bloomstein (@mbloomstein) June 5, 2012
To learn more about this activity I consulted with Margot Bloomstein, author of Content Strategy at Work: Real-world Stories to Strengthen Every Interactive Project. To be honest, I was skeptical about whether or not message architecture was a critical detail but as I learned more I’ve had a complete change of heart. Audits let us know where we are…The message architecture informs us on where we are going. And what could be more critical for a design…Or redesign?
As Margot points out in Content Strategy at Work, A message architecture is an outline of hierarchy of communication goals that reflects a common vocabulary. This differs from brand values, which describe the company, where the message architecture describes how the company should communicate with its audiences.
In order to get a better sense for how this works, I decided to create a small, sample message architecture for The CMS Myth. This example not meant to be exhaustive nor is it official…It might look something like the diagram below.
Content Generation/Migration Plan
This one item is actually somewhat difficult to define since it will almost always be unique for every given project. Nevertheless, to be effective, a good content migration plan must clearly define how the content is going to get created and/or moved from CMS A to CMS B.
This must include definition around where responsibilities lie. Obviously, everyone with a hand on the move should be consulted during the decision making process and be clear on their role.
Website Governance Documentation
By now the audit, experience architecture and messaging architecture are complete and the design team can move forward with experience design. A project manager might think this is a good time to put the content expert on hiatus to control costs, since it will be a while before content migration will begin in earnest. However, experience has taught me there is still much more work to do.
The last, but certainly not least, absolutely critical content deliverable is content governance. Like all activities and deliverables, the governance plan may be scaled up or down based on the size of the website and the organization it serves. However, one should always include language defining the essential parameters and work-flow around publishing content.
Even a one person web team should have documented rules around how content gets published, so they can go on vacation. Nothing is worse than getting a frantic call on the beach from a sales person at the office who absolutely must get the latest case study up on the site today for the ‘big sale’.
More extensive governance documentation might also include details such as:
- Hosting information
- Support information
- Content management team information
- Measurement team information
- Advertising information
- Information architecture
- Hiring and training
- Standards and procedures
- Legal issues (Privacy, TOS, Etc.)
In closing, it’s important to remember content related conversations must, and will eventually happen, no matter what. The fundamental question to be answered is, who will be involved with the project, to make the important decisions? An engineer? An intern? Or an content strategist? You wouldn’t hire a designer to write the underlying source code, or an engineer to design the templates. Why would you treat the content any differently?