Key Points
- All organizations should focus on easy, day-to-day publishing.
- Publishing should be streamlined for common tasks (and not for unusual situations).
- Easy publishing should always be a priority, on an ongoing basis and with big redesigns.
Fundamentally we need to have strong, end-to-end publishing. This should be highly prioritized in any implementation, and also for ongoing improvements.
What is easy, day-to-day publishing?
Easy, day-to-day publishing is:
Streamlined publishing of...
the content your organization most frequently needs to publish...
in a way that makes it easy to publish at high quality.
To accomplish this we need to:
Reduce steps in the publishing process
Reduce cognitive load
Make it easy for the publisher to publish high quality content
Focus on the day-to-day publishing rather than the obscure power user cases
Selling the importance of improving publishing
Part of our problem is that publishing difficulties can be somewhat invisible to everyone not affected. After all, the publishing process is a behind-the-scenes problem. A good approach to convince teams of the need to improve publishing is to emphasize how this ends up affecting the site itself. In other words, sell:
Better consistency
Better quality
More frequent publishing
Ability to better optimize
If you do high volume publishing, then a key selling point will be:
Staff spend less time publishing.
This is difficult but achievable
We have two key times to improve the publishing process:
During big change. If you are considering replacing your CMS, then the publishing process should be front and center. But seeing how easy it is to publish default content types in the CMS isn't very useful, unless they meet your needs. You need to look at how your common content would be published. For instance, if you have a news site then you need to see how easily and quickly you can publish a news story. Then of course during execution you need to keep a focus on this.
During ongoing change. Whenever someone asks for a change on the front end is a good time to talk about the publishing process. Basically, you want to always be asking "how will people publish the content to make this type of change in the future, not just now?"
The basic steps of content publishing
Obviously the steps need to be developed that are specific to your organization's needs — as a starter:
Start from a blank slate (the content publisher isn’t already logged into the CMS).
Content publisher logs into the CMS.
Content publisher initiates publishing a new piece of content, preferably indicating the content type (product update, webinar, research report, etc) — not file type (PDF, Excel file, image, movie, etc) or some technical type of how your CMS will render the content. The way the content publisher thinks about the content, not how the CMS forces the publisher to think about it.
Content publisher enters information to publish content.
Content publisher previews, preferably across multiple representative device screen sizes, what the entire page / other common representations
Content publisher either publishes the content or submits to workflow (in the case of workflow then it should flow through all approvals leading to publish)
Content appears
There often does need to be an education process with content publishers to think in terms of structured content types rather than pages, and sometimes it makes sense to continue with a very page-based approach. But nonetheless there is a logical way of talking about content (people don’t walk down the hallway talking about creating a static web page but about publishing a press release).
Measuring success
The most concrete measure is how long it takes to publish, from end-to-end (all the steps listed above), a piece of common content. When considering different tools and implementation teams this could be a core part of your selection process. Other measures of success are softer to measure but equally important: mental burden on the content publisher and how well the system steers the publisher toward high quality publishing.
The amount of effort to expend on implementing this use case is mitigated by two factors: the number of publishers (the smaller the number, the less urgent this is) and the frequency of publishing (the less frequent, the less urgent this use case is.