Developing your CMS for your content designers

I’ve been working around content for more than 15 years now, and I’ve seen and used a range of content management systems.  

I’ve even been lucky enough to be involved in the design of one said system from a user (content editor) point of view.

I’ve put together a list of things for CMS developers to consider when configuring a new system. It’s part of a set of guidelines to help people thrown into a web redevelopment project to understand the content aspects of the project.  

Content considerations for CMS developers

The first thing on the list is talk to someone who will be using the system.

Content people actually know a lot about the kinds of content on our sites; we know the way we need to report on it, and how to use headings, or particular metadata to optimise search, or accessibility. We know what we need the CMS to do.

• Templates — there’s some general information (for example, ownership and review dates) that we need to be able to capture, so it can be extracted to help us with reporting, and site maintenance activities.
• Non-html files — we need to make sure that documents, videos and images get added into the system with the correct metadata, and that we capture accessibility information related to the file.   
• Accessibility — many accessibility requirements get built into CMS page templates, or the CSS. In a perfect world, the design of navigation elements, link and heading styling and how content is structured to be mobile friendly will be done with someone like us who is thinking about the user journey.
• Search and analytics — make sure Google tracking code is added to all pages, and ask us about tracking downloadable documents as well.

We want to be involved in the design of the systems we’re going to use.  We want to help make sure the labelling of fields and elements makes sense and is helpful. Hint: ID356 is not useful if I am looking for contact details for a particular company.

And while we’re on structure and naming, it would be great if folder structures mirror the site structure and are never listed alphabetically.

Benefits

Most of the tips listed here and in the guidelines are about getting some content management basics in place.  A well designed CMS can:

• Help content teams keep their content aligned with key standards and guidelines
• Streamline content reporting and tracking, so maintenance efforts can be assessed and prioritised
• Minimise the need for ongoing development support
• Support compliance with the Web Accessibility Standard (this is mandatory for  Public Service departments and Non-Public Service departments in the State Services as of 1 July 2017).

Then there are the business benefits.  

Thinking about content requirements before the system is designed means:

• The system can enable and support broader content strategies
• End users get a better product that is accessible, and they can trust the information — because it is maintained properly.

Why wouldn’t you want the system you design to be useful and fit for purpose — for all users?  

This is just one of the many boxes you tick by considering the content requirements early, rather than later in your project planning.

More information

Web Content Accessibility Guidelines 2.0

A web project manager’s guide to SEO

PATCH: 5 quick and easy web accessibility techniques