From 90´s newsletters style to nowadays newsletters: an innovation story
On this very volatile context where we are living at, technology brings to the companies new and better ways to face some tasks - but sometimes they are very slow to take that path easy. This is the story of how we realised that something was happening with newsletters and how we have been trying to face it since that.
Originally I wrote this for a “Show and Tell” we are used to do weekly with my team. I just wanted to share this story with them and hope you find it helpful somehow.
Restrospective
Early 2011: old is cool
When I first arrived to the company newsletters were really 90s style, rigid, static, and the process to build them was “similar” to a piece of art creation.
Designers, newsletter managers, marketing specialists and adsales people were fully involved on the newsletter building.
At that days designers were doing the hard work: selecting and preparing all the images, cropping them and adding some graphics, creating urls by using FTP tools and finally writing the code with the new content.
Most of the times work was getting really humdrum and nothing creative, using templates and repeating tasks day by day.
Mobile was growing exponentially but we were not really on that mood. Our code based on rigid tables was not ready to be visualised on mobile devices. It was OK, none of our competitors were sending fluid or responsive newsletters so we didn´t care much about that.
2011–2012: we realised about a need
Suddenly I started to receive fluid newsletters on my inbox and I was really surprised of how good they look and at the same time very curious about how they could achieve that proper visualisation on little screens.
Our competitors were taking the advantage of being innovative and getting ready for the future.
I decided to download that fluid newsletter codes and play with them to understand how they worked. I took a piece of code from one and other piece from the other till I got the first “Frankenstein”. I was ready for the fire proof: send it throughout our sending platform.
Fortunately it worked! Was not perfect, was not pretty, but it worked!
I´m talking about very plain HTML: a modular table estructure with “Float: left” inline style and 100% width for the full images. At that time media queries were not allowed in some of the most important email clients.
2013–2014: first fluid newsletter design project
Due to this proof, a newsletter redesign project was a must so I started to lead it from a design perspective till today.
Coding newsletters is a very complex task if you want to achieve proper results and find people specialised on this issue is hard. We hired a frontender to help me with this.
I started to meet all the stakeholders and collect all their needs. Main interested on this were CRM managers and they have a lot of knowledge about their product, so I met them. After that, I scheduled some interviews with product people and advertising people.
With all the needs already collected, the whole picture on the table and a lot of benchmarking, was time to get hands dirty.
I already had a clear structure based on our current content and the technology constraints so first drafts had a big main promo as a hero banner with a 100% image width and 2 columns of 300px width each one to fit easily the advertising standard format MPU. Between sections I placed some titles and finally a cleaner header and footer.
Designing for newsletters is far away from designing for desktop or mobile websites. Code is very limited, similar to going back 15 - 20 years ago in web development. I mean:
- DIVs are not allowed so you are restricted to use tables.
- A lot of CSS are not possible in some email clients. Rounded corners and drop shadows could be a great examples.
- Web based fonts are not displayed properly in some cases. So you need to define a proper fall back to a system fonts like Arial. In older versions of outlook don´t recognise the fallback and automatically displays Times New Roman in default link blue, thats disgusting.
- No interaction allowed. Forget about mouse over effects.
- The use of media queries is getting more and more standard but big players like gmail app on android still are not recognising them so your newsletter will be displayed like in desktop on your narrow mobile screen.
Once our newsletter code was ready we started to use Litmus in order to optimize it for the incredible world of emails clients. Email clients are a nightmare for a developer but if you add to the formula the infinite world of screen resolutions now you get a explosive coctel.
If you don´t know, now you know: email clients are a nightmare for developers
Litmus is a platform that preview your newsletters in multiple email clients so we can know how the code works before sending it. We were focus on optimise every single module for the main email clients and devices our customers use, trying to achieve the best performance. Clients like Outlook are very restrictive with CSS and in some cases you have to apply the “good enough” rule.
2015: the time has come
Technology goes very fast and 1 year is a lot of time. New ways for building and sending newsletters appeared on the game and also new ways to manage them.
2 needs were the genesis of the new redesign project:
- Adapt the code to use mediaqueries and basically to the new technology advantages.
- Create a CMS for easily building templates and manage the sendings for the CRM managers.
Our fluid newsletters were performing right but far away from perfect. A lot of code limitations we had at the beginning doesn´t exist any more and the look was inconsistent with the last website release. -But this was not the main reason for the last redesign-.
When a company with multiple brands is very active in emailing the CRM managers need a tool to be more efficient doing their job. This time the project turned into how to build a CMS tool for easily create email templates by people who don´t know nothing about coding.
I started meeting all the stakeholders involved and collecting all their needs. The challenge was huge because we had to create a white label solution based in one code for 3 brands. Just with style tweaks (font-family, colors, iconography), not architecture, I had to achieve a proper brand differentiation. This is tricky.
All our know how, the data collected by our CRM team during the last years and best practices taken from benchmarking competitors and big players was applied to the wireframes. After meeting again with stakeholders, and wireframes approved, we decided to build a responsive newsletter using media queries.
Central idea was to create a flexible grid based in different pods that could cover all the product needs and at the same time allow to the managers to create their own templates based on fluctuant needs.
One of the challenges was to reduce the number of images and create some content travel related pods, not just with destinations and prices.
I did the UI for about 18 pods, for desktop and mobile, and created some templates for each brand. Finally I specify all of them in spacing, colours, font family and sizes, mainly.
In order to make CRM managers life easier we decided to create a tool which with an easy drag and drop you can build and send newsletters. Obviously they still have a lot of dependencies related with content providers or images and iconography but far away from the past.
We contacted with a third party provider specialised on create CMS for this kind of tasks and scheduled a kick off meeting. My role on this meeting was:
- Present myself and meet the team members. It´s very important to know personally -or via hangout- the people you are going to work with, it will save a lot of misunderstood.
- Introduce them on the specs and let them know your availability for issues and questions. (Soon I´m going to publish a story about how I specify mockups, stay tuned!)
Once this done we just could sit and schedule a proper QA.
Results
Bellow some links to real implementation:
