The Drupal 7 CMS that ESI Media used was causing a number of inefficiencies across the editorial team. It was slow, clunky and had garnered years of added functionality that made it bloated and hard to teach to someone new. It was decided that Brightsites' FLOW platform would be more performant. However, in its current iteration it would not be fit for purpose as it didn't contain certain functionality required at the Independent and Evening Standard.
I led the design of the two parts of the FLOW product that needed changing before the go live date, the article creation journey and the layout management feature. I also looked more holistically at how we could improve the journeys of our editorial teams and reduce the amount of platforms they rely on.
Although the product team sat physically close to the editorial teams much of our work focussed on external customers. This project was a great opportunity to understand the frustrations of our journalists and editors, which could help us empathise with their efforts moving forward.
I ran a number of initial workshops to understand their core journeys, e.g. publishing an article, setting up a live blog etc. This allowed me to map out their touch points and initial frustrations. The journey map below outlines the different platforms an editorial team may use during their day when publishing an article. Some of the interesting insights from this were that, although they could, they didn't want to use the CMS for everything. Journalists had become accustomed to a wide range of word processors and taking that freedom away from them would hamper their productivity rather than improve it.
I also spent a lot of time undertaking ethnographic studies, observing different members of the editorial team whilst they went about their day. This included early and night time shifts as the Independent runs a 24 hour operation. I gleaned a number of insights from watching them use the current CMS, from quirks they have learnt to deal with and long load times that visibly frustrated certain members of the team.
I kept an open dialogue with the team and even asked them to take notes and email me if any further frustrations or ideas came to their mind. This was an extremely helpful tool and means I continue to receive meaningful feedback from them.
To ensure we were able to adequately measure performance improvements I also spent time timing the editorial team undertake their core journeys, such as publishing an article. This meant we had a baseline once FLOW went live.
On top of the qualitative research I undertook a heuristics analysis on the article creation page, presenting it back to the FLOW product team to understand their reasons for certain design choices. Many of the recommendations highlighted below went on to be changed within the UI.
Realising that our CMS has a number of features not yet available in FLOW I undertook a card sort study to get an understanding of how we could intuitively group article settings before they were built in (e.g. grouping all headlines together and article sensitivity options). The results of the card sort were ultimately implemented within the new UI, creating a much easier to understand right hand rail.
I had come to realise that Trello was used by both publications to keep track of article statuses and to assign work, all pieces of functionality that could be better suited within the CMS, but for the moment it was so integral to their workflows I only recommended they move away from it in the future.
One editorial team at the Independent used multiple spreadsheets on top of all other platforms, leading to repeated redundancy in article management, I spent a lot of time with them helping to explain how this type of admin could be done quicker within FLOW.
Once the different teams were all aligned and happy with the proposed workflows I was able to start ideating and building prototypes.
A key part of the CMS that needed to adhere to our editorial teams' ways of working was the layout manager. This feature allowed users' to manage the structure of any non-article page (such as the home page) and what content was shown to the millions of readers who entered the site.
Through the discovery phase I had learnt that the Drupal implementation was overly complex and required multiple screens to manage both structure and content. I devised a new way of managing both simultaneously, saving users' time and reducing the chance for error. This idea was met with a lot of positivity as it was something they had never thought was possible.
Whilst spending time with those teams I also realised their equipment was not conducive to a productive workflow. I recommended they should receive larger 1440p monitors to allow them to view more content at once. This was extremely important as the layout manager includes a live preview of the site at all times.
I continued to iterate and perform usability testing with our editorial teams. Changes were made to how article components were grouped within layout manager and small changes to the account creation page occurred throughout. Below you can see the phase 1 live build of FLOW's account creation page and layout manager for ESI Media.
Feedback during the new CMS' training was unanimously positive. The new design of the layout manager was seen to be a huge improvement over the current version, and is able to speed up home page management exponentially.
The updated article creation screen was met with similar praise. Journalists and editors view the new user experience as much better than the original Drupal instance and time to publish an article was reduced across the board by 30%.
The features I helped design and build are now used across all of FLOW's customer base.