MailOnline has a very large and diverse offering of digital display and native products. There are about 40 different ad formats ranging between desktop, tablet, mobile, across web and apps. Not to mention all the new formats currently in development.
Part of the projects that are sold to clients are designed and built in-house by the MailOnline Creative team. However, a lot of the time, clients, media agencies and their creative agencies prefer to build things themselves.
This web app was designed and built from the ground up to fill this necessity. It aggregates all of the digital offerings and fleshes out every little detail the external creative teams might possibly need in order to complete their work.
I worked with a Project Manager, the Head of Creative, the Ad Operations Manager, the Sales Director, one of our Account Managers and a few of his clients to run some basic research, competitive analysis, set design goals in response to this fundamental need of the business.
I also gathered the ad formats data from various sources, structured and normalised it into a concise and easy to digest spec sheet, common across all formats before solving the underlying problem through visual, UX and interaction principles by designing the Ad Specs web app from the ground up.
The email conversation below illustrates a common scenario we were trying to solve. In short, our clients would often want to get a sense of what formats they could place on the MailOnline website, how to build them and ideas of past executions so they could get their campaigns up and running and set basic metrics to track and figure out whether their campaigns were returning their investments.
This was a real problem in terms of productivity because as simple as it may seem, the MailOnline did not have a centralised source for such data. Account executives had to rely on their own backups and would often send out outdated specs to clients who would in turn become very frustrated once they realised they were sold (and paid a lot for) the wrong thing.
In summary, our problems were:
The initial reaction was to approach the solution as a mere direct replacement to what the MailOnline had at the time, ie. spec sheets in digital form (PDFs, PPTs), except this time they would be aggregated and centralised.
I thought this wasn’t the best approach so I suggested approaching this a scalable tool, an online repository that someone within the business could truly own and maintain. It made sense to empower the Creative team within the MailOnline to be the gatekeepers to the MailOnline Specs.
I started this project by analysing what types of users we were trying to communicate with. The primary users being creative / agency types and therefore familiar with the technical ins and outs of ad serving platforms and rich media, it was safe to assume the information should be easily accessible and using technical terms wouldn’t necessarily get in the way. Non tech savvy users also had to be catered for however, so clearly stating format names as recommended by the IAB was a great way to make sure they knew exactly where they were.
The rest of the team and I created a few proto-personas that we would often come back to during the development of this tool. We found having these proto-personas was a great way to remove ourselves and our own biases and ideas from the process, allowing us to approach it more objectively and with the end users in mind.
The main users of the site would include MailOnline’s own sales team, brands, media and creative agencies working for their digital clients, each having their own unique set of goals.
The internal sales team would be after simple specifications: where formats sit on the MailOnline page, their dimensions and where these formats are available on the site. They’d also constantly have to show clients what formats they had sold in, this is why the site creates unique persistent URLs for each format – a feature we added on release 1.1.
Clients and creative agencies would be after the techy side of things: Flash Player version, file size limitations, whether it can run on mobile devices or not, build templates, etc.
Looking at what other similar sites did to organise their data, I noticed most of them seemed to have trouble classifying information in a way that made it easy for the user to compare between different formats – ie. not all formats used the same fields, even naming conventions and some of those websites weren’t even public, forcing you to request access and wait for a response.
I made the assumption, that was later validated by clients, that every ad format should follow a defined set of fields such as dimensions, accepted formats, initial file size, maximum FPS, loops, etc. while keeping a separate area for unique details. This way, every spec sheet would be similar and differences would be easy to spot at a glance and compare.
After all the initial research, we concluded our scope should be divided into the two parts below.
I then started collecting all the ad format data. Some of it came from our Ad Operations team and some had to be collected from other departments. There was a lot of back and forth at this stage since some of the data was missing and it was important to fill those gaps and provide full spec sheets for every format.
Once collected, this data was then used to generate the downloadable packages that also included build guides, Photoshop / Flash templates and printable versions of the spec sheets.
I sorted all the data into categories and normalised them into the same spec sheet so they could be easily compared and clients could get a better understanding of what they were buying into.
Now I had a good grasp of what we were trying to accomplish, I then started sketching out ideas and coming up with ways to navigate and represent this data structure.
The overall consensus was to narrow it down to two main ideas: a navigation that functioned around accordions and one where the content could be swiped in a carousel-like fashion.
I quickly built these two options as HTML, CSS and JS prototypes so that we could get some early feedback from potential users. You can test them via the links below.
Prototype 1 – Accordions
Preview it here.
Made with: HTML, CSS & JS
Prototype 2 – Carousel
Preview it here.
Made with: HTML, CSS & JS
On both versions, the large preview at the top is directed at brands and media agencies, and illustrates where a format sits on the page, how much space it occupies and how it relates to the content.
On option 2, the switch toggles between the placement and a real life example, so clients can see what the possibilities are with said format which was a very common request.
Option 2 received much more positive feedback, mostly due to the fact it requires fewer interactions in order to access the spec sheets, and the overall layout makes it a lot easier to compare them.
The 3-column layout also makes it very easy to navigate through formats. Users can either use the nav menu on the left, the prev and next arrows on each side or simply use their left and right keys on their keyboard. This makes it easy for a potential buyer to compare between multiple formats they’re interested in.
The visual style of the site should cater to all these different users while still maintaining MailOnline’s branding elements. There was no branding style guide defined at the time, apart from the coloured bar that symbolises the multiple channels across MailOnline. Hence the decision to use one main accent colour – orange in this case – and more neutral colours of similar shades for all the other elements. The typography works alongside the colour scheme to provide a clear sense of hierarchy and break things into smaller, easy to digest sections.
The 3-column layout breaks the site down into navigation, main content and additional information for easy navigation and makes most of the information accessible while minimising the need to scroll.
I also devised a visual system that allowed us to show whether a placement supported expansions or had sibling elements. The idea was to show formats within their native environments and near realistic – although redacted – content.
This being a very dynamic area of the business, it was clear from the start that the website would require constant updates and should be built on a framework that simplified the process of adding, removing or modifying existing entries.
All of the data resides in a JSON feed, making this a very flexible setup, with next to no overhead and allowing the Creative team to own this data source and keep it up to date without being limited by technicalities.
In order to keep things lightweight and performant, the data source is only queried from the server once during the initial load. It is then stored locally and only 3 spec sheets are generated at any given time, with 2 empty shells at either end.
This improves performance by saving memory as opposed to rendering all spec sheets even when they’re not being displayed and allows transitions to be really snappy and responsive.
As mobile didn’t represent such a big market for MailOnline at the time the site was built (circa 2013), the website wasn’t built with responsiveness in mind. After the initial release, we noticed more and more users were accessing it from mobile devices, possibly in between meetings or while out and about with clients.
This prompted me to start working on a reimagining of the tool that took all that into account while improving on the existing functionalities, such as adding search capabilities.
This prototype is a result of my own personal ideas and explorations at the time. This was just before I left the MailOnline so I’m not entirely sure it has been picked up and whether it was ever developed. You can test the prototype by following this link.
Looking back at this project now, I’m happy with the end result and very pleased that clients and internal teams have a tool that is not only reliable, but allows them to focus on more important aspects of their work. It’s a win-win for me as a product designer. That said, there are quite a few things I would have liked to do differently if given the opportunity.
This project came with some pretty big constraints I would like to touch on:
This was both good and bad; Good because despite us having specialists of many fields in the team, no one truly knew how to conduct research, create hypotheses and validate ideas. So I was forced into wearing many hats and doing things slightly outside of my usual remit (research, planning analytics) which allowed me to learn a lot simply by doing.
The downside is not having specialists to seek guidance from and make sure I was on the right path.
No development resources were allocated for this project
I doubled down as a designer / developer for this project. While it was incredibly fun and I’m well versed in front-end development, dealing with a back-end to store all of the ad format data required a kind of knowledge I didn’t possess at the time. I did my best to find a solution that met our needs but I would have much preferred being able to hand this part off to a back-end developer who could do it more elegantly.
No research resources apart from contact with clients and internal stakeholders
This ties up with what I already mentioned above about us having many specialists from different areas in the team but no true research insight to help us validate our assumptions. While it is the role of a good product designer to create reasonable assumptions to get an idea off the floor, having input from a research specialist is invaluable and adds a lot to the value of a product.
Lack of a branding styleguide
When this project started, the MailOnline did not yet have a branding style guide. One would only be introduced years down the line. This meant we didn’t have a whole lot of direction to go off of when coming up with a visual style for this tool.
Heavy time constraints
We had a very short turnaround for this project which meant we had to make a few compromises, particularly in the areas of research and visual explorations. I am confident in the navigation patterns we chose, but I feel the visual aspect could have been worked on a bit longer had we had more time.