Redesigning the header of BBC’s main CMS
And how we establish the UX function in an agile team
iSite is the CMS used by most BBC’s editors and journalists to publish content to our websites.
My role
I was leading UX for iSite. As part of the Systems and Service Design team (S+SD), I reported to a Senior Designer and worked collaboratively with designers working on other tools.
Key skills
- Cross design team collaboration
- Creating pattern library
- Influencing skills
- Kanban process
- Collaboration with developers
- HTML/CSS
- Usage data analytics
The challenge
As I joined the iSite team, I wanted to establish trust. No user research was conducted recently, so I decided to organise some. I also had to find a way to make sure my research findings will influence the product owner and impact the strategy.
The approach
Design Process
My design process is very lean and flexible and has 2 parallel work-streams: discovery and delivery.
I use the discovery stream to do activities that broaden my understanding of the product and users and will help shaping the product’s strategy, such as user research, global strategy analysis and collaborating with other teams. Knowing the company’s strategy also helps me to make the tools “future proof” by making sure the interface encourage behaviours changes in line with the company’s direction. Together with the rest of the IS+SD team, we’re looking holistically at all the editorial tasks using Service Design principles to make sure the different tools the editors use integrate well together and offer an efficient workflow.
For the day to day work, I use the delivery stream where I work very collaboratively with the rest of the team and come up with ideas that we test in the cheapest way possible, starting with low fidelity deliverables such as sketches and cheap test procedures such as sharing with colleagues and slowly increasing the complexity until we build production code and track live data.
Research
When I started working on iSite, I wanted to understand how the main users — the editors — create articles and publish them online, as this is iSite’s main function. In order to do that, I conducted some contextual inquiries where I asked different editors to demonstrate their process. The research highlighted that most of the users were not very technical, found the tool complex and didn’t use many of the functionalities. In some cases, they also found that the process of creating content for the audience facing sites was time consuming and inefficient, especially when uploading images. We also discovered that they only started to use iSite very late in the process which highlight a lot of new opportunities for iSite.
In addition, I wanted to know what on iSite’s interface was really important for the users. I knew that simply asking people this direct question wouldn’t give great results so, at the beginning of each research sessions, I asked the participant to sketch from memory what he or she could remember of iSite. In those sketches, many things were forgotten, and some were even added! This highlighted what was important and what was secondary for the users and it helped me simplify the interface. For example, almost everyone forgot to sketch the navigation bar. When I talked to the users about it, they said they didn’t really use it and didn’t know what some of the pages did.
Making users sketch an interface from memory is a great way to discover what matters to them and it helps simplifying an interface.
As this was the beginning of my time at the BBC, I wanted to establish trust among the Developers, Product Managers, and myself. In order to do this, I decided to try to bridge the gap between them and iSite users by bringing along one member of the team during each user research session. They were very interested in participating and started to empathise with the users, which helped them to understand my design decisions, and ultimately made the design process much faster and smoother. This has been so successful that the Developers even started to talk to each other about the users over lunch breaks!
Bringing along Developers and Product people during research sessions helps establishing trust and accelerates the design process.
Findings Analysis
Another key step has been to effectively share my research findings with the team. In the past, in order to do that, I often created personas and maps inspired by an experience map consisting of a user journey with pain points, happy points, user types, touch points, and an emotional graphic through the user journey. I would then usually present and stick those on the wall, but most of the time the team wouldn’t engage with them.
Collaborating with the team when visualising and analysing research findings helps with making them understand and use the findings.
To avoid this situation, I decided to try something different. In order to be more effective, I involved the team by organising a workshop in which I presented the user journey, and asked everyone to write user pain points on post-its, and stick them under the relevant step. We then went through each pain points they came up with, comparing those with the ones I found during the research sessions, and discussed them together. I used what we created during the workshop to complete a 3 meters long map that is now on the wall! To make sure research findings are understood by everyone, I also share the main findings during standup every time I meet with a user.
Involving the team really had a positive effect on making the Developers and Managers use the research findings. We referred to the map during several discussions about new features with the Product Manager and Business Analyst. The Product Manager also used it to identify new opportunities with the Head of Online Production as the map shows part of the process which iSite is not yet covering and a lot of the findings have been included into the strategy.
The experience map helped facilitating discussions about new features and discovering new opportunities.
Lessons learnt
The team appreciated being involved and the whole process helped them understand the findings, and therefore feel closer to the iSite users. However, they found the workshop a bit long and the Product Manager found it hard to identify the main areas he should focus on to relief user pain.
I now use a technique inspired from the mental model mapping from Indi Young where, we get together and, write on post-it notes every relevant bit of user feedback collected during research sessions, and we group them by topic. This highlights topics that received much feedback and helps to identify exactly who reported what. This activity helps the Product Manager with prioritisation. We then add the topics to the experience map to have an idea of where in the user journey those insights sit and visualise where is the most painful part of the process.
Mental models maps can help the Product Manager identify what are the main user insights.
Strategy
The Product Owner used the user research findings to update the strategy and decided that during the next quarter, we will focus on improving content discovery as user research highlighted that one of the main things users do on iSite is to search existing content and it was not always performing very well. Part of the strategy was also to make iSite responsive therefore, we decided to start by redesigning the header, as many users complained about it, it is used to search content and it is a logical element to start with to make the pages responsive.
Outcome
Design & Test
The new header had to feel simple, focus on search and be responsive. I started by checking the usage data on Google Analytics to validate users were not using the navigation bar much. Once validated, I started sketching some ideas, refining and sharing them with my colleagues in the iSite team and the tools’ UX team. As only a few users used the navigation bar, I decided to hide it into a menu which made the design less complex and saved some space which was very valuable when on a small device. I also combined the name of the project the user is in and the search box, allowing more space for the search box and making the header looking even simpler. The search icon on the right of the search box is used to help the user understand its functionality as well as a search button for users who don’t use the ENTER key. On the left of the header, the “Project Switcher” allows users to quickly switch between projects. Users having several projects are mainly Developers users and the majority of the users rarely switch between project therefore, we wanted to keep the functionality without making it too obtrusive for regular users. The size of the logo was reduced to gain space and the full logo with text was only kept on the home page which has a slightly different header. Creating a document is one of iSite’s main function and many users complained not to be able to create new documents from everywhere. For those reasons, we added a new button to create a document. It was designed as a primary button (orange) as it is the main call to action.
I created an Axure prototype to run some usability tests in which I also redesigned some other parts of the site that would be in development subsequently. Most of the participants prefered the new header to the existing one and understood how to perform all the tasks. I used the rest of the results as a basis for the design of future stories.
Build
After successfully testing the header, it was time to break up the design into “minimum testable stories” and get the Developers to build. They used the internal tools’ HTML pattern library to reuse existing patterns and added their new ones to it for reuse by other teams.
Using a pattern library is a great way to let Developers reuse code and keep products consistent
Pilote
Once the first version of the header was ready, we piloted it with the CBBC team and I went onsite to observe them and make sure the new design was valuable for the users. Their reaction was very good and they said that this change made the interface feel simpler. Some didn’t even notice any changes which was a good sign and proved that we made the right choice to move the navigation bar.
Using GitHub is a fast and efficient way for the Designer to polish the CSS
The Developers added the rest of the features and I helped them polish the CSS using my sandbox and Github. It also allowed me to quickly simplify the the visual style of the overall interface without having to use any of the Developer’s time. The new style helps the user focus on the important parts of the page while leaving secondary information on a grey background.
We slowly increased the number of teams using the new designs and collected their feedback. Everyone was generally happy about the changes so we push the changes live to everyone. Monitoring the usage data told us that only a few number of people use the menu which validate the design decision to hide the navigation bar.
Next steps
Using a similar process, we simplified and reclustered the dashboard, content library and search results pages. During the next quarter, we will focus on improving the image uploading process as it was found to be a major pain point for the users. We will start by doing an “ideation” workshop with the team where we will focus on solving user pain points. I will then use all the ideas generated to converge and test until I reach the design that will be implemented.
What I’ve learned
- Making users sketch an interface from memory is a great way to discover what matters to them and it helps simplifying an interface
- Bringing along Developers and product people during research sessions helps establishing trust and accelerates the design process
- Collaborating with the team when visualising and analysing research findings helps them understand and use the findings
- The experience map helped facilitating discussions about new features and discovering new opportunities
- Mental models maps can help the Product Manager identify what are the main user insights
- Using a pattern library is a great way to let Developers reuse code and keep products consistent
- Using GitHub is a fast and efficient way for the Designer to polish the CSS
Disclaimer: This article represent my personal views and not those of the BBC.
