A New Media Monitoring System

The Project: Scenario and Objectives

During this project I was an employee at a design agency in Malta, and in the past PR and media monitoring brought in the biggest share of the business for the agency. As time passed and we started taking more design projects and more media clients, the need arose to look at the media monitoring processes and understand how it can become more efficient.

The media monitoring team consisted of an PR admin and two media content creators, and they were using a legacy web system to upload new entries. Desktop was the only required device for this system not just due to its data inputting nature, but also due to the fact that for submissions to be successful it connected to another third party media and PR online system by Kantar which was only available on desktop too. After analysing the whole process and running some user testing and feedback sessions with the team I noticed the following:

A lot of the work was done manually.
The user journey in creating media entries was in dire need of streamlining and updating: there were multiple pain points which led to high percentage of user error, and in many scenarios there was no turning back, just starting from scratch. This led to user frustration and also decreased efficiency.
The UI was not helping either; the whole system consisted of forms – which was a necessity since the whole process basically consisted of data inputting – however those forms were badly categorised and even more badly designed: no instant verification of the inputted data, almost non-existent error messaging and no clear instructions and labelling. The users were getting confused and uncertain.
The system was not safe, given the sensitive data that was inputted.
No user reporting or dashboard for permissions control – once the developer was gone, there was no way to update the user hierarchy or available actions to the users.
There was no client list or article library – every article uploaded by the content creators was sent as an email to the administrator, resulting in complete confusion, fragmented storage and lost or undelivered articles.

The user testing and also some test runs I ran myself on the system as a person completely new to the process provided a lot of insight into what the main objectives of the project needed to be:

Streamline the user journey and turn it into an intuitive flow; categorise the forms from the outset to reduce user error
Analyse error case scenarios and cater for them; then re-test to make sure that all were covered
Provide a structured dashboard and re-design the forms: categorise the fields in a way which matches the user’s data input flow, including tab order, and apply a cleaner design.
Provide more control to the admin: Create a simple user hierarchy with a dedicated profile for each user based on a permissions framework and add a user reporting function.
Create an integrated database for media and PR clients and for articles with a very simple UI which the administrator can access and remove the unreliable use of email from the user flow altogether.

Streamline the User Journey

The user journey was simplified based on the feedback collected from the user testing conducted with the team and based on my analysis of the previous user flow. It was very interesting to note that the users – although aware that the system needed updating – were very patient with its shortcomings, trusting that it was given ‘due to the nature of its technology’ (I assured them that it should not be like that at all 🙂 ), and even though as we discussed they were agreeing with proposed solutions to make their life easier, they still seemed a bit resistant to the change. It seemed that their mental model had adapted to a complex, inefficient system so much so that after that steep learning curve the complexity seemed like a requirement.

User Journeys: Part of the Content Creator flow

User Journeys: Part of the Administrator flow

Analyse error scenarios and cater for them

There were many gaps in the media monitoring process, most of which were concerned with error handling. The users were not informed of the consequences of their actions, and many times there was no turning back. Furthermore, there were dead ends in the flow – for example after completing or discarding an article, instead of offering the option to create a new one they had to go back to the first screen to create a new one, adding multiple no-value clicks.

Notifications and alerts: as you can see, the above notifications all offer a possible next action for the user. This way, the workflow is not broken.

Errors and Parameters: The field data was not instantly validated, and even though the data would be entered incorrectly, the field parameters were not correctly set in order to trigger the right error either. Therefore, data entry process, requirements and system feedback loop had to be rethought.

Create a simple dashboard, redesign the forms and provide more control to the users

One of the main objectives was creating a simple hierarchy and categorise possible actions via a simple dashboard. The administrator would have more functions available such as reporting, user management and database access.

A very useful function introduced in the wireframes below is the Preview function – which was not available before. This provides the user with a preview of the finalised article, and they have the option to go back and edit any mistakes before submitting. This put more control in the hands of the users as they can edit and review their work as many times as they wish and avoid wrong submissions.

Simple dashboard wireframe: Content Creator (Left) and Administrator (Right)

Form design example: Uploading a new Print article

Form design example: Uploading a new Web article

Preview of a Print article before uploading

Provide more control to the users

The simple user hierarchy provided an administrator role, and more control. The legacy system was not based on a permissions framework: basically all the users existed on the same plane and any changes relied on the developer. This dependency was not ideal nor secure, therefore I introduced this simple dashboard from which users can be easily onboarded and provided with the permissions accordingly by the administrator. The super admin would always be the owner of the agency.

With this framework, not only were the majority of the dependencies removed, but there was also the opportunity to add so many more functions such as user reporting for HR, which user actions to report and get notifications for and also the option to deactivate accounts in case the employee left the company. These were all actions that – a simple as they might sound – are so essential yet were not available.

Edit a user: permissions provide great flexibility that at a more developed stage can also lead to further roles depending on the types of enabled permissions.

Create a database with a simple UI

Previously, all the uploaded articles would be sent via email and using Filezilla. This system of course had many pain points: files were organised incorrectly, lost, undelivered or unseen due to a crowded inbox and a fragmented workflow. Introducing an integrated simple database for media & PR clients and uploaded articles was the best solution, and accessing it via an even simpler dashboard would provide the much needed control in the administrator’s hands.

The database was divided into Lists and Libraries, following a thought-out categorisation that the team was already familiar with, in order to reduce the learning curve. The Lists are mostly to collect performance and client analytics and were editable, while the Libraries act more as a permanent storage of all the uploaded articles and media content. Relevant reports can be extracted from both, and with this solution not only is the agency more organised, but is creating its own data and can carry out analysis from it in order to become even more efficient or discover new business opportunities.