On the surface a content management system (CMS) is a tool to create, edit and publish content. The dream scenario is a free-flowing, adaptable content delivery system. In this hypothetical world an editor or publisher asks and a CMS gives. But even the cleanest looking, seemingly user-friendly CMS systems have flaws. It can even appear like some systems are configured to test the sanity of users.
A CMS isn't inherently complex. Most content delivery products aren't born to the user as intricate puzzles. It often seems like they are when a CMS supports vast amounts of content for multiple visitors. If you take the complexity of such a website, or such a demand, try getting a small-scale CMS to handle the load. It's pretty unlikely, however neat you might think it'll turn out.
There's no way of avoiding it. Content designers have to develop an intimate knowledge of the CMS they're using. They have to become mini experts in a way. Some will come to thrive on the process of acquiring this kind of knowledge, cracking the system, using workarounds, and generally getting geek-deep. For someone like me whose passion is working out how a CMS ticks, this is a wonderful thing to see. Break and remake. However, there's a second group. They'll scream 'I'm just a writer for Christ's sake!' To a certain extent the second group have a point. Given that content designers spend so much time stretching their core writing skill across so many other disciplines, it surprises me they don't snap more often. Fortunately they're incredibly resilient people.
It's important to narrow a content designer's training-to-publishing gap as much as possible. This is especially the case when they have to check off many other processes before, during and after publishing. Ideally, they should be using the CMS at intervals from the day they begin writing. This isn't always practical or possible. But if it is, this approach will allow them to gradually gauge the look and feel of the final pages as they go. It will also help them to get used to handling the system.
I've experienced CMS training both as a trainer and trainee. Anyone who trains should have 6 months of intensive use. Their view of the system should be mostly positive, and they'll need a good sense of humour to handle frustrations. The ideal situation is that a select group of content designers develop a comprehensive technical knowledge of the system. This doesn't mean going back to university to get a computer science degree. It just means they've picked the system up quickly, fought for improvement, and are highly curious about how it works. They can then apply this knowledge to helping other content designers to build their content structures before testing and publishing. To this extent they become a bit like first-line support, but only within their specific field. They all learn more as a result.
Most content designers know how a CMS works. They've often worked in a variety of digital content jobs before. Focus their training on things they'll actually do. To find out what these are, speak to a content designer in your organisation who has a few projects (sprints etc) under their belt. Ask them what their content delivery process is from start to finish. Be sure of everything.
Covering the basics of a CMS will be easy. You can teach that to anyone. So work on the training process for specific users first. Apply the content design process directly to what you cover in your training workshop. Ideally you should split CMS training into 2 parts, each roughly an hour long. The first should cover the basics. This gives learners chance to get a feel for the CMS. The second should simulate some of the things they'll actually have to do. This might include:
Most organisations have a general CMS user guide. This won't cater for content designers. This is because general user guides are for frequent users who make light edits, then move on. Content designers often have to get a CMS to handle a large volume of new content, navigating new - and potentially conflicting - structures.
As with your content design CMS workshop, the guide document should reflect the content design process from A to Z. This is where you'll see that workshop training and guidance documentation both feed into each other. Remember that when you originally asked a content designer to tell you their process, that it might have changed the second time around. Check with them - or someone else - again.
Create a simple use case, making sure you address a content designer's needs. Bare in mind, this doesn't need to be dense. With the content design process and use case in place, you can start naming and structuring the sections of your guide. This is rough and it'll change, of course.
Documents like this can take up to two weeks solid work to complete, which will include step by step screenshots. Factoring in other work commitments will make it roughly a month's work to complete a first draft. This breaks down into two weeks creation, one week to give your eyes a rest, then a final week to reformat and tidy up.
Don't tie yourself in knots trying to cover every possible scenario. Just run through the main content structure build, testing, and then publishing process. You'll instinctively know if you've gone into too much detail, as the document will begin to lose its flow. A document has its limitations. Some things just have to be done by good old fashioned talking to people.
Work with someone else on the document. When I did this I was lucky enough to have an ex-technical author to hand. If you have an opportunity to co-author a document like this, just take it. As the document is likely to be long, there's nothing more valuable than a second pair of eyes. Whether you know someone with technical documentation experience or not, I recommend working with another content designer.
Once the first draft is finished and checked, get it out there and test it. See if content designers can follow it. Collect their feedback. Be realistic about what you can and can't change. Some of the feedback might require quite light changes, so deal with this straight away. Other feedback might require you to change the way a system works. Keep this on the back burner, as it might require technical development.
Create a channel for collecting feedback on the guide document and the overall publishing process. Also, allow people to leave notes on the guide (e.g. Google docs).