This is a great topic thanks Ollie, and one that I have a great deal of thoughts on (so brace yourself).

A successful user experience within a CMS I think is associated to four key areas which are aligned to either the platform being used (Umbraco, Sitecore, Drupal etc) or are the responsibility of the consultant configuring the given platform. The success (or failure) of a given project can hinge on the usability of the CMS.

No matter how great the website, if it’s unmanageable or if the administration associated to managing content is so onerous that our client is operationally hamstrung then reputations will be damaged, clients will be unhappy and projects will be deemed unsuccessful.

The four key areas are:

Platform Usability

Some CMS platforms have invested heavily in their usability and UX. It shows.

Take Umbraco and Sitecore for example, both systems are conceptually the same, content is modelled in a similar way, the API’s are similar and terminology (largely) is consistent between the two systems.

However, consider the two images below.

The Umbraco UI is simple and clear.

Interactions and CMS actions are applied through consistent, repeatable patterns (if you want to apply an action to a given page, right-click it and select the appropriate action)

There is typically only one way to perform a given action (you publish in a single way, you delete in a single way)

A CMS user is presented with an uncluttered user interface which presents only the actions that are relevant to the current context of the user at a given time

This isn’t to say that Umbraco is a restrictive, immature CMS; it’s incredibly powerfully, but the UX has been meticulously considered to the extent that Umbraco is a joy to use. Equally training is a breeze, no matter the size of the audience.

Consider how this contrasts to Sitecore which again is conceptually similar to Umbraco.

The UI is overly cluttered

Actions (publishing, deleting etc) can be performed in many different ways (in the ribbon, in custom menus etc)

Ribbon items are not always contextually relevant; it’s possible to have actions available in the ribbon that aren’t appropriate/relevant for the current page/item being edited. This creates a great deal of noise and confusion for the user

It should be said that Sitecore is a considerably more powerful platform, it’s more flexible, scalable and configurable than Umbraco and as such it’s more complex. However it’s through this additional level of flexibility where the usability issues derive from.

Platform Type

I’d like to add to your list of ‘types of CMSs’ if I might dare, as I think the third type is where the sweet-spot lies. I feel that a CMS which proves a successful user experience is one which leverages the maturity and investment of a pre-built CMS but which allows a bespoke CMS to be built on top of it (a hybrid if you will).

Take Umbraco which is incredibly mature, includes a rich API, provides enterprise features such as load balancing and localisation, but which provides nothing to a user out of the box. Upon logging in, the CMS is empty and it requires an expert to configure (from a UX perspective) it correctly. What it does provide out of the box is a framework of building blocks which allows content to be modelled in a way which feels bespoke – it inherently (if configured correctly) matches the content types appropriate to the given website. Equally it’s extensible to allow new features, content types and data types (text editors, media pickers) to be added and customised to suit the current project.

Content Modelling

How content is modelled within the CMS is probably the most important factor which can affect the user experience within a CMS. No matter how great the UI, how powerful the CMS, if it takes a user 45 minutes to create a page and publish it due to the number of steps they need to jump through to do so, then we’ve failed.

For example, imagine a situation where a website contains a blog and a blog is written by an author. When writing and publishing a blog the user needs to enter who the blog’s author is, which provides the following possibilities for content modelling (there are others, but these are the most appropriate here):

1 – De-normalised: Authors could be managed against the given blog page (author’s name, job title, and photo are ‘stored’ against the given blog article), providing ultimate flexibility regarding the author’s name and credentials. In this way, it’s possible to provide more contextually relevant job titles appropriate to the given blog article (a dodgy requirement I know). e.g. A given sales rep at a holiday company could be a ‘Villa Specialist’ on one page and a ‘Greece Specialist’ on another. However, this creates a great deal of duplication, an author may have published multiple blog articles and if the author gets married and their name changes, multiple pages need to be first found and thereafter updated.

Example content model being:

/blogs/blog 1/author 1

/blogs/blog 2/author 2

/blogs/blog 3/author 1

2 – Normalised: Conversely the author could be managed in a separate area of the CMS; a so-called ‘global area’. In this way, an author is picked to be associated with a given blog article. The author’s details are managed in a separate area of the CMS and when updated all articles associated with the given author are published with the new details; updates are quick and easy. However, this is achieved at a detriment to flexibility and less contextually relevant content may be presented to the user (holiday sales reps would have to be ‘sales rep’ on all pages).

Example content model being:

/blogs/blog 1

/blogs/blog 2

/blogs/blog 3

/global/authors/author 1

/global/authors/author 2

Equally, the direction of the picking can cause headaches, or cause a project to succeed, should blogs be picked from the author item, or should authors be picked from the blog items??? Both have their up’s and downs and the decision is relevant to our client’s needs.

Now, considering all of the above challenges it is possible to solve these issues and deliver a beautifully usable CMS, with a few compromises along the way. HOWEVER, content modelling is often left to the developer – not a UX specialist!!! Developers are great n’all (I used to be one), but they are not the best people to be making these decisions; their objectives and goals for the project are different and they’ll largely take decisions to solve their challenges rather than those of the users. I’m paraphrasing to make a point here, not all developers think like this of course, but it’s certainly a problem which occurs more often than not.

Data Types and Extensibility

Website content is natively composed of a collection of words and pictures, each content ‘type’ generally consists of a number of pieces of data. Take a blog article which may contain following pieces of data:

– Blog title: Text string (max 50 chars)

– Blog article: Rich Text

– Blog author: Author Picker

– Blog main image: Media Picker

– Blog published data: Date picker

The data types present within the CMS (e.g. text string, date picker, media picker) are typically limited and are provided by the CMS vendor/community. Additional data types are typically available as plugins and enrich the user experience of a content editor.

It’s probably true to assert the following:

CMS UX is dependant on the number and capability of data types available to the CMS

CMS UX is dependant on the number and capability of plugin data types available to the CMS

CMS UX is dependant on the ease in which data types can be created and extended and additionally to combine data types into aggregate data types

For example, most CMSs provide ‘media pickers’ which allow a media item such as a photo to be picked and associated with a given page in the CMS. However, the ability to upload a new image into the media picker and thereafter pick it in a single action saves a considerable amount of time over a media picker which requires a user to have first uploaded an image into a media library first, prior to it being picked.

Furthermore, the ability to combine data types into ‘aggregates’ provides a synergy with the content modelling process, allowing a much simpler and more easily understandable content model to be developed. For example, take a look at the following page:

This page lists the management team within a travel company. Without an aggregate data type we’d possibly model our content in the following way:

/homepage/our company/our people/george morgan-grenville

/homepage/our company/our people/ed grenville

This content modelling is great, however in a CMS such as Umbraco or Sitecore, the above model would mean that both employees would have their own ‘page’ and said page would be crawlable by a search engine. Conceptually this also confusing to the admin – “I’m creating a ‘page’ but there’s no actual page to view on the front-end, what the heck!!!”

By creating an aggregate data type we are able to combine the data associated to an employee (name, position, bio, summary, phone number) into an aggregate data type called ‘Employee’ and manage this content within the ‘our people’ people, with no child pages. See the image below which illustrates how this might be applied in Umbraco (a video explains the concept further here).

This again provides for a much simpler content model which is easy to understand and manage from the content editors perspective.

To summarise

If you managed to get this far and wade through the barrage of content above then I’d summarise the above in the following way.

A successful user experience within a CMS is dependant on:

A CMS platform with a clutter-free, simple and contextually relevant UI, which requires small, simple repeatable patterns from the CMS admin to execute actions A CMS platform which is extensible, allowing new data types to be created easily and the ability to aggregate data types. This provides a simple content model to be produced and requires fewer interactions from the user to complete a task A CMS platform which provides a pre-built flexible framework upon which a bespoke CMS can be built, allowing a designer to model content in a manner which exactly matches our client’s workflow and operational procedures A user experience consultant capable of making sense of points 1-3 and able to leverage the benefits to create an inherently easy to use CMS

N.B. In addition and whilst most of my work is consulting on Sitecore projects these days due to it’s extensive marketing automation and personalisation capability, it’s fair to say that Sitecore falls way short of Umbraco from a UX perspective which (IMO) is lightyears ahead and perfectly provides the capability associated to points 1-3 above.