Designing for CMS

Include Content Management in Your Agile Framework

July 12, 2015

Design is problem solving and one of the key problems of almost every website is managing the content. Often the Content Management System (CMS) is an afterthought – something to be addressed later. Procrastinating on this essential operational function increases the risk that there will be a gap between the intention of the web design and the reality of how the website actually functions. And this gap is likely to widen over time. Web producers need to consider the CMS throughout the lifespan of the project – start to finish.

Agile

Agile workflows encourage a team to simultaneously address multiple web production elements rather than waterfall them into separate stages. In the waterfall method, a designer may create a visual look and then pass off the project to a developer. But the initial design (especially if it is just a Photoshop file) can’t account for development realities and opportunities. Design and development need to happen in tandem in order to account for screen size variety, viewing experiences, and interaction opportunities. Including CMS development in the agile workflow offers similar synergistic opportunities. Web producers need to design for the CMS so that the solutions remain operational over time.

Evaluate the Landscape

Consider the CMS options. Many organizations are already attached to a particular CMS and each CMS comes with a set of advantages and limitations. Design and development plans must fit within the CMS functionality. Budget time and money for any necessary augmentation.

Also evaluate the content editors who will be using the CMS. You need to create a design that users can manage within their time budgets and skill sets. Be clear about which kind of content will be editable through the CMS WYSIWYG and what changes will require coding.

Selecting a CMS

Establishing a CMS is a big investment. Sometimes switching CMS is more labor intensive than changing design, especially if there is a large pool of editors and content.

  • Identify functionality and make sure the CMS addresses the foreseeable needs.
  • Make sure the CMS can be customized and iterated after launch. Are you dependent on a single company to make updates to the CMS? Is it accessible to other developers? Less options means more risk.
  • Avoid placing mission critical functions on time-sensitive technologies. Are you depending on 3rd parties to maintain applications or plug-ins? Consider the alternatives and the backup plan before utilizing a WordPress plugin, especially if it’s from a less established team.
  • Try to create a CMS that has CMS agnostic content. Can you import your existing content into your new CMS? Can you export from the new CMS into the next CMS?
  • Leverage the crowd. Is there a community that shares ideas/code to improve features?

HTML Structure

When I created Rensselaer Giving, the IT department favored a particular Drupal parent theme with a particular HTML structure and many of the modules also imposed a specific nested nomenclature. I needed to branch the CSS in order for the code to conform.

Pattern Library

  • Consider how CMS users will implement the design patterns.
  • Create templates for essential patterns like navigation, footers, and page margins.
  • Create toggles for established variations of patterns, such as a header type.
  • Use the WYSIWYG to assign CSS classes for basic patterns, this might include a responsive image size.
  • Consider how accessibility tags will be added based on content.
  • Complex patterns are created through a combination of basic patterns. For Rensselaer Giving, there are example CodePens with instructions. For Bard College at Simon’s Rock, there are editable code blocks that users can drop in.

See the Pen Give Now Button by Chameides (@chameides) on CodePen.

Example Call To Action Button on Rensselaer Giving

Don’t assume that the CMS (or the CMS developer) can implement the desired solution. Test and plan the development in sync with the design decisions.

Website with field notations
The Columbia Land Conservancy Real Estate Listings page has very little flexibility. The content originates in a database and the style and page layout occur with little to no oversight.

Fields

Carve the design into CMS fields. Creating numerous, specific fields will make it easier to maintain fixed style patterns - especially if the design is complex and/or the content managers don’t have time or skills to follow governance rules. Alternatively, use fewer, more flexible fields to allow for more choice when creating content within the CMS. Make explicit choices based on the content and governance needs. For each field consider:

  • Field type (text, radio, etc)
  • Data options (numeric, specific selects, maximum or minimum length, validation, etc)
  • Functionality, design, and processes dependent on the field
  • Relationship between fields
  • How content editor edits the field
  • How the field and functionality is built into the CMS

Dynamic Content

Identify which content on a page is auto-generated based on data stored elsewhere. Is there a newsfeed or event listing? Dynamic content saves time by automatically updating and formatting. But, it is generally less flexible and bakes content and design decisions into the code.

Content Author UX

Content editors are essential to the content delivery and therefore the ultimate goals of the website. Designers and developers need to create a CMS that gives content editors an author experience that supports the strategy. We want to make it as easy as possible to deliver great, strategic content.

Learn more about creating effective media, view my Production Remarks.