Ditch the spreadsheet for content analysis.

Golden Use Case: Easy, Day-to-Day Publishing

Last updated June 9th, 2018. First published

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.
Related resource
Content Management Medalists | When improving your CMS, cover these use cases first

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: 

  1. 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. 

  2. 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:

  1. Start from a blank slate (the content publisher isn’t already logged into the CMS).

  2. Content publisher logs into the CMS.

  3. 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.

  4. Content publisher enters information to publish content.

  5. Content publisher previews, preferably across multiple representative device screen sizes, what the entire page / other common representations

  6. 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)

  7. Content appears

Is your content publishing streamlined?

  • The publisher is only presented with a form for the information they need to enter (no extraneous or duplicative fields)
  • Requires a minimum of formatting, especially any HTML (like explicitly applying certain classes)
  • Not allow any formatting that will be stripped out anyway or that is not desirable
  • Be as natural a way of entering each field (dates should be entered as dates with perhaps a calendar option for example, references to other content should be managed, images should allow whatever processes are routine, taxonomy fields should be constrained)
  • Should streamline day-to-day publishing and not edge (or gee-whiz) cases
  • If assets need to be added to the page, the assets can be managed as part of the flow (rather than breaking the flow)
Also: Content Management Medalists
A note on step 3

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.

Mitigating factors

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.

Content Management Medalists When improving your CMS, cover these use cases first