WCM Implementation Advice: Design Stage Considerations

Design Stage Considerations

Welcome back. This is the second in a series of three posts. (See Part 1: Before you Start and Part 3: Development Stage Considerations.)

In addition to all the normal things you'll figure out during the design of a normal web project (like user experience, content strategy, usability, template structure, and environments),

here are some additional items to be figured out during the design phase of a WCM project which are typically missed or done incorrectly:

Workflows

Many times, there is a tendency to overbuild workflows. If this is your first go around with a new WCM, you should start simple and add complexity as you gain more experience. A typical scenario is manager and executives want to be part of the workflow process. This typically results in an increase in unnecessary emails as the best case and publishing getting stuck in workflow queues with outdated content in the worst case

Editing Granularity

Editing granularity refers to how granular your templates are within your CMS. The more granular your templates, the more control your development staff has over enforcing the functionality and UX, but your editors need to do more clicks (think "Add center body list" module and "Add center body image" module). If your templates are less granular, it means the editor has more free-form control over the page, but potentially can make each page look drastically different from the other (think "Page with Center Blob of Text"). Many WCM implementations fail because editors are surprised about the amount of flexibility they have to edit pages or because they would like the "system" to handle more. More on this editing granularity can be found on my previous post on template development.

Two Apps to Design

Don't forget there are two applications here that need to be designed: (1) External Site for users and (2) Editing Interface for editors. It can be as simple as making sure the interface has proper help text and visual cues for the editors (if your WCM has proper Inline Editing) or as difficult as designing the entire editing interface with separate taxonomy to find content and forms interface for contributing content (in the case your WCM relies on forms UI for contribution)

Package Selection

Most times this is run as a separate thread of work with people prioritizing WCM specific features, coming up with long lists and short lists and doing vendor demos and potentially even package POCs (proofs of concept). Many times, companies think if they just get someone to answer "what CMS I should use?" that things will fall into place for them. The truth is, this is one important component of the WCM project but is akin to General Motors deciding how to design their next automobile around which engine has the most features. There are many aspects to the solution that need to work together for a successful project.

What types of data to store in your WCM?

Figuring out what type of data is in your enterprise and which you should store in your WCM can be trickier than you think. There is data that is absolutely appropriate for your WCM like images and text content. Some data isn't as good a fit such as transactional data like "customer orders". Other data is content whose system of record can never be the WCM, such as product data that is required to also be maintained within an ERP system. This data is most likely better to be pulled into the WCM using a decorator pattern (described by Scott Gottlieb). Being clear about this will inform your editor training and also your content migration. This is why it's important to map out during your design phase.

Related:

• Part 1: Before you Start
• Part 2: Design Stage Considerations (this post)
• Part 3: Development Stage Considerations