Marcelo Davanzo

Senior Product Designer

London, UK
Hybrid or remote opportunities only

Ad Specs web app

See the live site

About the project

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.


What I did

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 problem

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 brief

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.

Competitive analysis

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.

Competitive Analysis
I judged each site based on a few simple pointers to serve as a benchmark for us.

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.

Users should be able to

The site should strive to be

Data gathering

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.

What our spec sheet used to look like.

Data sort

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.

Visual design

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.

UI elements
A few examples of the UI elements and overall design system used on the app.

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.

Build and scalability

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.


Future iterations

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.

Feature wish list for v2.

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.


Reflections and conclusion

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:

AdvertisingMailOnlineSpecsWeb application

Want to see more?

Here are my other case studies.