Tag Archives: MailOnline

MOL – Ad Specs

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.
Hero

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.
team
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.
Convo
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:
  • Information in too many different formats (spreadsheets, presentations, PDFs)
  • Not easily accessible
  • No central repository
  • No one owns the data
  • Too many different versions scattered around the business
  • Not easily kept to up-to-date
  • Spec sheets are not standardised or comparable
  • Client does not fully know what they bought
  • Ads are built and delivered to Traffic based on wrong specs
  • Clients end up frustrated due to mismanaged expectations
  • Disappointed clients tend not to give us repeat business

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.
Chat

Research

Proto-personas

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.
Personas
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.

Scope

After all the initial research, we concluded our scope should be divided into the two parts below.

Users should be able to

  • See the placement area and how it relates to the content
  • See a preview of past campaigns that used that same placement
  • See on which pages / channels a format is available
  • See full technical spec sheet
  • Be able to easily compare between different formats
  • Include IAB standard formats as well as bespoke ones
  • Ability to download creative templates of each format
  • Scalable system to grow as our offering grew
  • Ability to be maintained by the design team without much effort

The site should strive to be

  • Performant and snappy
  • Easy to update
  • Simple to navigate
  • Cater to various levels of knowledge
  • Transparent and reliable

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.
Collect
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.
Sorting
normalize

Sketches

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.
Sketches

Prototypes

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.

Feedback

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.
Build
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.
Carousel

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.
Features
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.
Innovation

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:
  • Small team

    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.

MOL – Showcase

About the project

The MailOnline Showcase site serves as a portfolio of what the Creative Team has historically produced so that potential new advertisers can have a better understanding of what they'd be buying into in terms of execution.


What I did

I came up with the concept of laying things out in tiles containing appealing images of past campaigns, while giving the user complete control over what they see through a filtering system.


Wireframing

It was safe to assume the website would start with only a few projects but would eventually grow to hold several of those tiles. The challenge was to make it visually interesting regardless of how many tiles were on screen. The "empty" slots are marked with placeholders for that reason, so the page never feels empty.

Wireframing

UX

Since the user would be able to use several types of filters - channel, format, device, category - my main concern was in keeping navigation simple instead of overwhelming the user with options. Additionally, the OFF button provides a quick way to disable all active filters.

Filters

Design & UI

The concept here is that content itself is what makes the design instead of adding unnecessary elements. The tiles are comprised of the format name, client it was developed for, a short description and upon clicking, a live preview of said format is launched on a new tab.

The filters are basically a list of checkboxes, this way you can tick multiple ones in order to chain them together and expand your search.

Design & UI
This is the loader I created for when the page is loading. It is done with CSS keyframe animations and uses the colours of the different MailOnline channels.

Build

The back-end for this site is a simple JSON feed that can be easily updated by anyone on the design team. All they have to do is generate a thumbnail image and create new nodes in the JSON file.

Code

Mobile specific

Some of the formats we created are better experienced on real mobile devices instead of emulated through a desktop browser.

For this reason, I have also created a separate mobile-only Showcase site.

This is a neat little tool the sales team can use to show clients what the real experience would feel like before closing a sale. You can check it out here.

MOL – US Ad Sales

About the project

MailOnline is the world’s biggest English language newspaper website. In August 2014 it had over 180 million global unique monthly visitors with 60 million visitors from the United States.

This website serves as a platform through which the DailyMail US team can communicate announcements, their latest stats and present advertising solutions to potential clients.


What I did

I worked with the Trade Marketing team to come up with the best way of presenting their data and making information as accessible as possible while empowering them to maintain the website and keep it up to date.


Discovery phase

We knew this should be a one-pager from the get go, where data would be broken down into easily digestible chunks.

The trade marketing team had a pretty good idea of what kind of information they would like to showcase and even some creative ideas of how they would like to present them.

We had a few conference calls where we discussed those ideas and how we could bring them to life. We also sorted the data in order of importance so that we could make informed decisions and position things on the page. After nailing all of that down, we moved on to the wireframing phase.

Project image

Wireframing

We knew what sections the website would have and a rough idea of how they would be stacked. This was the stage where we had to decide what type of content each section would hold. Amounts of images, length of copy, and essentially the entire structure of the site onto which we could build all the functionality that would make it usable.

We went back and forth with a few wireframes until we were all happy with the main structure before moving on to hi-fidelity sketches, mock ups and UI elements.

Project image

Visual design

The visual design takes follows MailOnline’s branding guidelines and sticks to a certain colour pallette. The idea is taht the content should make the design, so the UI tries to get out of the way and simply present the content.

That’s not to say it doesn’t introduce delight by means of smooth transitions and animations throughout the journey. I particularly like how we resolved the navigation elements into a burger icon on smaller devices, transitioning the options in a staggered manner when the user clicks to open it.

This is one of my favourite pieces in the UI work I did for this site. You will only see it on mobile breakpoints.

The contact form is quite cool as well: when you try to submit without filling in a required field it indicates that by shaking the fields. Submitting is pretty delightful as well with a nice reassuring confirmation that your message was successfully sent – without nasty page reloads, too.


The header

The header is a chapter in itself. The original concept came from the US team themselves. They wanted a header that would really catch your eye and showcase what DailyMail.com is all about: celebrities, strong headlines and incredible numbers.

I suggested we created a composition with lots of celebrity images, a few stats and headlines from our site and kept shuffling through them every few seconds.

Performance was a big concern to me, so I made sure to optimise images as much as possible while ensuring no unnecessary elements are rendered. I also leveraged CSS transitions rather than JavaScript for the animation effects due to their improved performance in this case.

I used the isotope plugin to order the tiles, CSS to create the background animations and JavaScript for the subtle parallax effect you see when scrolling down the header.

All animations stop once you hit the header threshold, this ensures the site runs as smoothly as possible and performance doesn’t take an unnecessary hit.

Project image


Development

I knew the site should be built on a CMS that allowed it to be maintained by the marketing team themselves without them having to deal with any code or go through any technical hurdles.

I decided WordPress would be the way to go due to its user friendliness and wide array of plugins that would make the site a breeze to update to people without previous experience in managing a website.

I built a custom theme while using a few plugins to facilitate content management that allowed for a truly visual interface for each of the custom fields the team would have to update in the future.

In practical terms this means, for example, that image galleries behave as real image galleries where images can be added or removed through a visual interface, unlike most themes that require the user to input a URL to the image they want to display.

Project image

Post launch

The site has been a success and is proving to be a valuable tool for the American team. So much so that the Australian team have recently shown interest in having their own version of the site with a few minor tweaks to make it more in line with their market.