Saturday, January 21, 2012

Designing content modules

In my last post, I talked about the "why" and "how" of using content modules to improve efficiency and user experience. In this post, I'll talk about some of the specific considerations in designing content modules. 

Content Module Categories

It's important to think about content modules as a whole, and not to use them for a bunch of one-off messages. Think about the type of information that you want to convey through content modules, and then categorize them. For example, in a recent project that I worked on with Theresa Putkey for Rocky View County in Alberta we decided to use these categories:

  • Alerts
  • Events/Meetings
  • Profiles
  • News
  • Related Topics
  • Contact
  • Application CTA
  • Survey
  • Interesting Facts

Categorizing content modules is extremely important for a number of reasons. Categories are a cornerstone of developing an effective taxonomy, which is they only way to automate updates of contextually relevant content. They're also important to ensure that similar types of information are presented consistently.

Content Module Types

Once you've got your key categories, you can break them down further into content types. These represent the different common types of information that you'll present in each category. You really need to have a strong understanding of your content at this point. Using the examples from the Rocky View County project, here are two of their categories broken down into standard content types:

  • Alerts:
    • Fire bans
    • Weather warnings
    • Road closures
  • Events/Meetings:
    • Basic statistics and link
    • Statistics with brief description and link
    • List of upcoming events/meetings and links

Defining content modules to this level helps to keep them focused and consistent and prevents a reactive approach to using them to publish any small bits of content that don't fit anywhere else. It also really helps writers to have a template to follow so they can quickly and easily write content that works for each type of content module.

Content Module Priorities

Depending on your website, you may want to assign each category of module with a different priority so that your CMS can pull one type of content module in preference to another. In the examples listed above, the Alert modules were the only content module given a priority one. This meant that in the spots that we wanted Alerts to appear, they would take precedence over any other content modules if they were available. If there were not, then that spot would be filled by a priority two module that met other specifications required of that spot.

Content Module Design

Once you know the type of content you'll be working with in each module, you need to define design requirements. Content modules should be designed to stand out on the page, but not compete against each other for user attention. “Alert” modules should be the most prominent element on any page. Strong CTA's should also be very prominent and obvious. All content modules should follow a consistent visual schema, with each type of content module having its own consistent structure and design. 

Some of the design decisions you'll need to consider and standardize include:
  • Visual design
  • Size and dimensions
  • Text and font size
  • Headings and phrasing
  • Information design
  • Number of characters or words per text element
  • Use of photos and/or graphics

Visual design aside, the best way to figure out these design issues is to draft some copy for a number of each type of module and get a sense of the "norm".  Then you can develop sample copy for each content module that can be used to inform the visual design and content guidelines. That way you can be sure that the design requirements actually support the content and not the other way around.

Below are two examples of different types of content modules in the Events category:

Looking at these examples, you can see how a visual designer could get a good understanding of the type and scope of content that he's designing for, and how you could easily create templates and guidelines to help writers develop consistent content across similar content modules. 

Be sure to include content modules in your writer's style guide, and include specifications for each content module type. For example, one type of content module may consist of a heading, brief description, and a descriptive link to the main topic page. You can also specify if there are any constraints such as character limitations, phrasing preferences, or tone of voice variations. 

What other ideas do you have for working with content modules? I'd love to hear other stories about what has worked well for you, or what challenges you've encountered. 

And I extend a huge "Thank You" to the Rocky View team for allowing us to reference their project work and examples in this post. 

1 comment: