Blog home

How to avoid UX overreach in CMS projects

Tony Byrne of Real Story Group have written an interesting blog post about how he’s seeing a new trend where more companies are having over-ambitious UX strategies in their WC(X)MS.

Tony lists a number of typical examples of ambitious UX overreach that I found very interesting:

  1. Overly sophisticated "related content" modules that require unrealistically complex tagging and system intelligence
  2. Content re-use visions requiring highly granular information models that become unsustainable over time
  3. Devilishly complex navigation structures to support myriad potential user journey variants

I’ll comment on these further down in this blog post.

He then suggests a checklist that the UX consultancies can create for the customer to help determine if the proposed UX will be manageable for the customer. While there are several very good advice in the checklist, I do have a couple of issues with the checklist and the blog post in general:

First of all, I don’t think there are any UX consultancies that can give good and correct answers to all of the questions in the checklist. Some of the questions have no definitive answer until the implementation of the feature is implemented, or at least prototyped. The answers demand an extremely detailed knowledge about what implementing the proposed UX will entail, how it’s different from the existing implementation, how it should be implemented in the selected CMS and how it will be implemented.

I’m all for developing good processes, but in this case, I don’t think the checklist alone will solve the problem of UX overreach. It might help a bit on its own, but it will also involve quite a bit of work and cost for both the UX consultancy and the customer.

I would have focused more on these areas to avoid the problem of UX overreach:

  • Involve the implementation partner in the UX process.
    This will give the UX people instant feedback on the viability of the proposed functionality. Any good implementation partner should be able to give valuable feedback that can help you avoid a lot of wasted time.
  • Choose the right CMS for the job
    Of all the typical examples of UX overreach Tony made, all of them can be minimized or completely overcome if you select the correct CMS for the functionality you desire.
  • Choose the right implementation partner
    While choosing the correct CMS is extremely important, that’s only part of the equation. An incompetent implementation partner can easily wreak havoc with your project, even if you did choose a good CMS.

The points above can be combined with the checklist, but without wise choices in the areas above, it doesn’t really matter how good the checklist is.

As for the typical examples of UX overreach mentioned in the blog post, IMO all of the examples are symptoms of content modeling gone wrong. If you have done a proper job of content modeling, you shouldn’t be having those problems. If the base content model isn’t good, you often end up adding bits and pieces for new UX items, which quickly turns into an unmanageable mess as described by Tony.

To illustrate the importance of content modeling, I like to make an analogy to how you construct buildings. For a small shack (a blog for example), you don’t need to put a lot of work into the foundations (aka the content model), but if you’re creating a skyscraper in an earthquake zone, everything is dependent on a very solid foundation. Building a skyscraper on poorly built foundations, leads to all kinds of problems, expensive repairs and makeshift solutions. But they will never fix the underlying problem. The same applies to content management and content modeling.

A common problem is that many of the content management systems on the market have some limitations in their content modeling capabilities. This makes it difficult to have one content model to base all the different “views” on (templates or other UX elements/components).

Relations between content is key for creating a rich content model.

Without support for relations between content, you have to simplify the content model. This often consists of forcing the content into a hierarchical tree structure. With a simplified content model, you lose a lot of the semantics and metadata about the content, which means the content model usually can’t be used as the universal source for content for the whole UX anymore. You’re then often forced to create and maintain separate menu structures for different user journeys.

Relation-based navigation.

In situations with complex content models we often recommend using something we have termed relation-based navigation.

Relation-based navigation is a navigation method where the navigation is automatically created, based on the relationships between content items in one coherent content model. There is no need to manage separate menu structures.

This have some big benefits for all parties involved:

  • Easing the editorial burden
    Editors doesn’t have to spend time to find out where to publish a piece of content. The locations where a piece of content is displayed is based on the properties and relations of the content. The rules as to how and where the system displays a piece of content is determined by a set of rules the developers create, based on the deliverables from the UX consultants. The only thing the user has to do is fill out the information in the form representing the content item.  
  • More natural navigation for users
    Users get a much more natural way to navigate the site as the navigation is based on “real relations” between content. As Tony mentioned, in order to support multiple user journeys or different paths to the same content, you need multiple starting points for users to start the navigation. With a relation based navigation approach, you solve the problem without adding a lot of complexity.  
  • Better structure and re-use for developers
    Relation based navigation allows developers to create a nicely structured site with one coherent content model. Having one coherent content model is a great benefit for developers in many ways, including easier content re-use in multiple channels, less training to get new developers up-to-speed, easier to adapt to change requests etc.
Posted by: Vidar Langberget
Categories: CMS 
Comments (0)
Add comment
Captcha Image