CMS replacement

The problem

The CMS that the Trust uses for its main website reaches end of life by the end of 2021.  This means that there will be no support, updates or security patches once this happens.  As an organisation with a website that attracts tens of millions of visits per year, this is an absolutely critical project with huge financial and logistical risks. As part of the exercise, the website itself will need to be rebuilt and all the content migrated.

The solution

This project is split into 3 phases: Feasibility, Design and Plan, and Deployment.  As at the time of writing, we’ve finished feasibility and are now in Design and Plan.

So far:

Around 90 stakeholder interviews

These were conducted face to face and remotely  and were mainly focused on the strategic needs of various stakeholders and CMS users.  As well as the simple pieces of functionality – can they upload an image easily, can they format text, etc, will it allow them to personalise content, will it give them more control over functional content, etc.


I planned and ran workshops with a cross section of the CMS users that we have, representing all the different user segments.  These were much more focused on the day to day needs of users; what their frustrations are, what bits they like and want to keep, how much time they thought they waste due to inefficiencies with the system, what their goals and desires are.

As part of this I also got them to fill in templates for their personas which I then amalgamated into 3 higher level personas that we could use.


Requirements gathering

One output of all these workshops was a list of features or requirements.  One of the first things I did was to run an online card sort which was sent to every single user.  In this, they were asked to prioritise around 60 different features so that we could see where the most common overlaps were.  These are being used to evaluate and score different CMS products for a shortlist where we’ll go through an RFI process to choose a supplier.

Product evaluation

I’m on a board of people looking at various CMS products through different lenses.  We have people from web-ops looking at the technical/hosting/security aspects, product owners, etc.  At this stage, I’m the lead on UX for the new CMS so I’m acting as the voice of the CMS users.  There is a propensity to sacrifice what users require over technical considerations.  I’m trying to argue a balance between the two things with some senior people within the organisation as my goal is to ensure that we don’t end up with a product that frustrates users like the current system does.

Ongoing user representation

As an organisation, we have around 600 users on the CMS.  We have national users who edit and publish content on a daily basis.  Their whole existence is based around logging in at 9.00 in the morning and using the CMS intensely until 5.00 at night.  In the middle we have regional users who might log in a few times a week to update content relating to one or two properties in their portfolio.  At the other extreme, we might have users who are based on a small property and act as front of house, gardener and content editor, using the CMS once or twice a month to make simple changes. At the top two levels, users are performing many different tasks.

My role here is to ensure that their voices are heard, and that they are kept informed throughout the life of this project.  So I’m having to manage comms with stakeholders at every level in the organisation.

User research – front end

As important as it is to get the CMS right, it’s equally as important to get the UX right for the public facing side of this.

There are over 20,000 pages of content to think about, generating 15 million+ page views per month.

The first things I did for this was to break down the web site into 11 different high level journeys:  Join, renew, donate, booking a holiday, booking to go to an event, finding a volunteering opportunity, etc.  Each of these has been user tested from a usability point of view with one or two tasks to see how easy it was for the user to complete.  It’s fair to say that all tasks could be completed but we often make it harder for users to reach their goal than we should do.  One of the challenges of this exercise is convincing stakeholders to focus on what users want to hear rather than what we want to tell them.  Pages are often littered with distracting calls to action, often duplicated on a page, that have no relationship to the journey that the user is on.

We’ve also used an external agency to perform a large qualitative survey for us to identify a number of different user profiles.  From these, I will be generating a number of personas that will help inform the process of developing user journeys, empathy maps and then the IA for the site.


Based on primary research conducted by an outside agency involving hundreds of participants, user segments were created giving us in-depth information about our audiences.

This broke users down into 9 different segments.  From those 9 segments, 3 further cohorts were created.  However, none of these focused on intent so I took these are created proto-personas.  These were “Traditional”, “Contemporary” and “5s”.  “5s” are a bit of an anomaly.  The other 2 are an amalgamation of different numbered segments. “5s” are one segment but they represent such a high percentage of users that we decided to use them as a group on their own.

The main use for these is to give us something to refer back to in terms of UX and putting human faces on groups of users.


User Journeys

Part of the feasibility exercise involved testing a number of different journeys on the current site based on user intent – I want to join, I want to donate, etc.  We’ve taken these and created journeys based on the personas and primary research.  We’re confident that we know how users are feeling at different stages.  These user journeys just help us visualise what the user is thinking and feeling, and what we might be able to provide to remove negative thoughts, reinforce positive thoughts and nudge them through to taking an action.

Wireframes and prototypes

As of now, we’re half way through the design and UX phase.  The pattern of work, in brief is like this:

  • Sketch – 2 UXers and 2 designers
  • Wireframes from sketches – UXer (Me and another UXer)
  • Design – 2 designers
  • Build prototypes in Axure – UXer (Me)
  • Test using a mix of remote unmoderated, remote moderated, card sorts and tree tests – UXer (Me)
  • Analyse testing (Me)
  • Iterate designs and re-test as required

The pace of the project is quite fast.  We’re working in 3 week sprints and need to get page templates designed and tested to hand over for implementation in 2021.  It’s taken a couple of sprints to find our way with this but it’s working well..