I had the opportunity to lead the redesign of a major company solution called MediaCMS, which centralises the management of all of BCE’s customer media content.
For the past 10 years, the product has had to adapt to different market demands while retaining the base product. This situation led to the creation of a very complex system, difficult to maintain and develop.
So what exactly is a complex system, you may be asking? Well, in the case of MediaCMS, it is a digital product with many interdependencies, aimed at many different types of users with numerous systems relying on one another to work in harmony. MediaCMS centralises content management, work and distribution in one tool. Customers can place their orders into the system; these are then managed and tracked, and finally, those same customers are then invoiced, all through the MediaCMS.
For the redesign, there was a lot to take into consideration regarding harmonisation between the systems and the users.
What is the company, and what does it do?
The company in question is BCE — Broadcasting Center Europe, which is part of the RTL Group in Luxembourg. Broadcasting Center Europe (BCE) is a European leader in media services, system integration and software development in the areas of television, radio, production and postproduction, telecommunication and IT.
The MediaCMS is mainly used by BCE’s Digital Media Operations, which are a complete set of services to digitalise, enrich, store, transcode, edit and distribute your content.
Who finally decided that this tool needed a redesign? Why only now?
With the relocation of the company to its new premises and the evolution of its workflow and technology towards IP, OTT and streaming, it was paramount for BCE to modernise its product range.
Evolution is not only about technology but also about customer experience. Nowadays, user experience is as important, if not more, than functionality. It (the user experience) plays a vital role in the life of the software, through its attractiveness and productivity. With all this, Olivier Waty, Technology and Product Director at BCE hired me to oversee the User Experience design of all the company’s solutions.
The goal of this project
The purpose of redesigning this product was, mainly, to increase the number of customer orders by creating a more efficient tool that would allow the technicians to work faster. At the same time, it needed to be made friendly enough to enable our customers to create their orders themselves, manage their content and track the progress and status of said content without asking BCE employees to do it for them.
BCE decided to create a new version of its MediaCMS software by redesigning not only its user interface but its back-end as well. The goal was to improve user productivity, extend its features to adapt to modern trends and create a platform as a service (PAAS).
Roles and responsibilities — The dream team
We started with six developers, two designers (me and another designer, which made us the team’s UX duo) and the product manager. We all worked closely during the development phase completing 2-week sprints.
I was responsible for leading the design “team” and driving the end-to-end UX design process and its implementation strategy, however, both my design colleague and I worked side by side, participating in the tasks together throughout the several phases of the process.
So where does one start redesigning a complex system? Interviews
Since my colleague and I were unfamiliar with the MediaCMS, we needed to understand what it was exactly, how it worked, what it provided the company and the customers, the impact it had on the company and who had a stake in its success or failure. So, we interviewed all the stakeholders who were somehow involved with the product starting with Olivier Waty.
- The product played a crucial role in the company’s business, and it was one of the tools used to provide the various services to our customers.
- Who was selling and promoting the product to consumers as well as gaining insights on the customers.
- Who had decision making authority and the most to lose or gain with the redesign, allowing me to identify the people with whom we would need to manage expectations.
Interviewing the stakeholders
After knowing about everyone who played a role in the product’s life, we, the UX team, set out to interview each one and jump-start a relationship with them, one that we would nurture throughout the process. My colleague and I needed to know what their roles were, what their hopes and fears for the project were, who the competitors were, and how they would measure success after launch.
It was important to work closely with the stakeholders throughout this process to make sure that what we were redesigning was always relevant.
Identifying and analysing the competition
After the stakeholder interviews and some internet research, I discovered there was a small number of MediaCMS competitor products on the market.
Getting to know the product itself
Of course, another crucial step in this whole process was to use the tool myself, to go through the same day-to-day tasks the users did. The developers, who currently worked on and now manage the system, helped me discover all the different use cases and workflows existing on the tool, along with all the other different systems that work together and are dependant on the MediaCMS, and of course the numerous users.
After this exercise, I created a user and workflow diagram to summarise the use of the system. It helped clarify how all the different parts worked together.
Time to roll up my sleeves and start planning
Now that I had got to know the tool, the users, and what was essential to the business, I could begin to plan out how I would approach this redesign project.
There would be two distinct phases: the discovery phase, which I was already in the midst of, and the conceptualisation phase.
In the discovery phase, I would gather as much information as possible about the product, the users and the business goals and analyse everything. I would then be able, in the second phase, to organise this data and begin the creation of solutions for the new version.
Starting with the users
This product, up until now, had been a business to business product where most of the people using it were employees working locally, and a few working remotely. However, one of the objectives of the redesign was to extend it to “business to customers” as well.
The fact that the users were on the premises was fantastic for me as I had direct access to all the information within the company. I had already identified all the different types of users during the exercise of exploring the tool myself and so I created the first draft of personas for each type of user, making assumptions about them as a starting off point.
Getting feedback from the users
I set up interview sessions with the users and then prepared questions and use cases that I would need them to go through depending on their different roles and tasks. I conducted interviews for a total of 9 users, one user for each persona. As for the interviews themselves, my design colleague and I set up a screen capturing software and a webcam on each user’s computer to record their screens, voices and facial expressions during the sessions. We asked them to walk us through their daily tasks and to think out loud, letting us know their frustrations or appreciation toward the tool and asked them to perform specific use cases if they hadn’t shown us organically.
Updating the personas with what I discovered
After the user interviews were done, we had a better understanding of the users who represented each role within the system. So I updated the personas with information regarding:
- Their day-to-day responsibilities
- How they used the product
- Features and functions that were important to them
- Their thoughts and emotions
- Behaviour and environment
- Pain points and gains
- And situational conditions like what they thought, saw, felt and did when interacting with the tool.
The persona characteristics, plus the business goals, were what would essentially define the product.
Analysing the footage from the user interviews
Once the personas were well defined, my colleague and I proceeded to analyse all the footage captured during the user interviews noting down all the problems the users had performing their day-to-day tasks with the MediaCMS. We put each issue on an individual post-it note and placed each note on an empty wall in our office. This technique is called an affinity diagram, and once all the problems were captured, we then started to look for patterns in the data and began to organise and structure the problems into logical groups. This exercise helped us not only understand the requirements the new system would need to have, but also how the new system would be structured.
Top insights from the data analysis
The main problems we identified were:
- The current system lacked a crucial functionality that prevented users from managing the media content in bulk; they had to do a lot of repetitive tasks often.
- The lack of automated processes, forcing users to do a series of manual tasks unnecessarily.
- Lack of customizable or dedicated work environments. In the current version, the system provides all kinds of information for all users in one place, overwhelming them with things they don’t need to see because it only relates to other user roles.
Defining the requirements for the new MediaCMS
Using all the insights from the stakeholder and user interviews, we created a document that listed all the proposed requirements for the features and functions that should be built in the new version to increase efficiency.
This list formed the basis of discussions with the team and was an excellent source of inspiration for the needs to be covered. Once the requirements were validated, the team was able to define/negotiate a clear timeline for the first launch date. One of the challenges of a project like this is that the first version would have to allow the users to perform the large number of tasks they currently did.
The IA structure
It was crucial to define the skeleton of the new MediaCMS system, as there are a lot of intricate connections and workflows all linking to one another. So, the best part to start with was the information architecture, defining the structure of the tool and grouping the different functions into logical sections allowing users to be able to navigate the system as quickly and intuitively as possible.
Once the main structure of the system was defined, it was easier, for the whole team, to break up the development into larger chunks, or epics, calculate the workload of the redesign project and prioritise the features and functionalities to meet the deadlines.
A clear vision and timeline
At this point, we had a solid plan; in regards to the UX work, my colleague and I knew what needed to be built and how much time I had to build it. The only thing left to do was use the allotted time for each subsequent phase, which in the case of our team, designers and developers alike, was two-week sprints until launch.
The design workload was divided equally between myself and my design colleague; however, we still worked closely and regularly convened to brainstorm and conceptualise together, feeding off of each other’s ideas and creativity.
Mapping out the user flows
In this phase, I mapped out all the use cases (all the actions the users can do on the system) for my part of the design work, to know what the users would need to do step-by-step to achieve their tasks. This exercise would serve as the blueprints for the graphical user interface. Once this was all mapped out, the other designer and I joined our diagrams to make sure they worked together.
Buckle up your creativity belt; it’s time for design blast-off into wireframes
So finally, at this point, I could start to conceptualise the design of the new MediaCMS screens and translate my concepts into visual form. For this phase, I created wireframes to define how the users would physically interact with the system to be able to complete the use cases mapped out in the user flows.
Prototyping and testing
I created simple click-through prototypes to validate the high-level concepts and task flows of the system. These were validated with the product manager and the users and then iterated upon if needed.
High fidelity visuals and the pattern library
Once the wireframes were validated, I was made responsible for defining the look and feel of the product. Once the visuals were validated, the other designer then used the defined visuals to create his part of the design work. For this, we used a collaborative design tool where we could work on one document simultaneously, which made our jobs much easier as we were able to work faster and more efficiently.
Upon arriving at the company, I had built a pattern library of components, which was then implemented by the front-end team, that would be used across all BCE software products. This design system was used for the redesign of the MediaCMS as well, however, given that this was a complex system with more elements and components than the other company applications, most of the components for the graphical user interface had to be built from scratch. They were then added into the first version of the pattern library.
Once the interfaces were validated with the stakeholders, the front-end developers would then implement the designs.
The users were then given access to a beta version where they could test the platform. I gave them a couple of days to use this test version and perform their usual tasks. Afterwards, my colleague and I got their feedback in usability sessions that were organised and conducted very similarly to the first ones where everything was captured for post-test analysis. From the feedback we received, any existing problems we identified were analysed and prioritised by level of impact on the product and, if not easy to implement or crucial to the usability of the tool, were placed in the product backlog for future development.
Example insights from the usability tests (excluding known bugs/defects):
- Users had a hard time trying to read the font when it was presented with a thin weight.
- Multiple users did not know or could not find an easy way to perform a global search on the media content list page.
- They could not find the notifications history, which is hidden within the small bell icon on the top navigation bar.
So far, no major workflow problems were identified, only minor bugs and interface fixes that were easily fixed. It’s always a great feeling to discover ways in which we can continuously provide a better experience for the users.
A lean UX approach to software development
Even though this process may be described linearly, for our team, this was an ongoing process of investigation, making assumptions, defining solutions, testing with the users, learning, prioritising and making adjustments, in a constant iterative cycle. This approach allows us to keep the product relevant and usable for the users.
An important lesson
Something quite valuable the entire product development team (designers included) learned was not to underestimate the power and value of testing/validating design concepts with the stakeholders and users before both implementing the designs and developing the back-end.
We received a lot of positive remarks from the users, the internal employees, stating with excitement, how happy they were to see the product evolve and meet their needs. They were also very appreciative of how involved we kept them throughout the process and how they could see their input making a difference.
“It’s nice that we can take a look behind the scenes from time to time to test the interface and it’s even nicer to see our problems being resolved.” MediaCMS user.
The biggest challenge in designing a complex system was taking all the different networked parts into account, making sure that they work well together and in multiple combinations. I found that I could overcome this by interviewing all the stakeholders involved to get feedback on how their parts work but also on how they connect and then map out that visual structure for a clear and concise overview.
Centring the design process around the users was a clear benefit for them and me as well (the entire team really). It is rewarding to watch the users, in the usability testing sessions, be able to use the tool as expected and to see that all our effort is having a positive impact on their work.
Currently, we are working on testing the implemented designs to prepare the new tool for its first release. We look forward to testing, refining, and improving the system regularly once it is deployed. All the redesign participants have high hopes for the added value it will bring the company.