This Cyber Monday Tuts+ courses will be reduced to just $3 (usually $15). Don't miss out.
On top of the regular requirements which come with building templates for an email marketing service that designers use (for example, that campaigns look good, even on mobile devices!) there were a couple of extra things we needed to address. First and foremost, there was working collaboratively with design, testing and of course, amongst email coders to make this project happen. As it turns out, developing a process around that was indeed, a project in its own right.
Working in and across teams is a) hard, and b) really demands both tools and processes to be in place upfront. If you struggle with getting the results you want from your design projects - even if they aren't email related - then you'll likely relate to these points. With any luck, you'll find our experiences useful when overcoming your own challenges with team collaboration.
As an email coder who, for many years, has taken a brief > code > delivery approach to tasks, using a similar waterfall approach seemed natural when developing each of the Canvas templates. To give you an idea of the complexity of the task, each of the ten templates consists of multiple layouts and a selection of elements (text fields, buttons etc), with every piece requiring close collaboration between both our email code and design teams. As was the case when I started years ago, collaboration can be fraught with danger, even amongst the most well-behaved of us.
So, here's a look at the seven steps, from kickoff to testing and handover, that our team worked through to create the templates. Again, while these reflections are on an email project, you'll likely find these workflow tips just as applicable to the web.
1. Choose the Best Tools for Communicating
It was really important that we found a means to collaborate and share between design, email coding and whoever wanted to jump into the project.
We tried a number of approaches to discussing and clarifying issues, including the use of Shipment (for design reviews), LayerVault (for version control) and a HipChat room (for team chat). At the end of the day, we selected Basecamp, a popular team collaboration app. Not only was it already in use and familiar to many within Campaign Monitor, but it's pretty good for organizing coding tasks and facilitating deeper discussions in teams.
For template issues (for example, rendering glitches), JIRA, an issue and project tracking app, was selected - again, a tool that is very familiar to the team. Using JIRA allowed us to also loop in our cohorts in the testing team, without forcing them to use tools outside of their existing workflow.
2. Get to Know the Design
Once everyone was settled on collaboration tools, it was time to receive the Photoshop mocks in PSD format from the design team. This was a bit of a discovery phase (and perhaps not so waterfall-y after all) requiring email developers like myself to have a good look through PSDs of both the desktop and mobile versions of a template.
Things that we focused on included identifying standard layouts that email coders are generally familiar with (eg. 1-3 static columns), vs non-standard, more adventurous ones. Seeing how the same layout or element looks translated between desktop and mobile is always very interesting; thankfully our designers are pretty used to working with responsive emails (and their quirks), so aren't prone to making outrageous demands as far as layouts go!
3. Identify Tricky Layouts and Elements
Anyone who has coded a web or email design from scratch knows that often, finding out what works and what doesn't across multiple platforms can be quite an exploratory process. With our templates, some of the elements had to be coded and tested aside from the template-in-progress, to ensure they could be incorporated into the design. As always, some things may not look exactly the same across all email clients (or browsers, as is with the web), but they should at least degrade gracefully - and look good.
Also, if something in a mock turned out to be actually impossible to achieve, it was good to give that feedback early, since design changes can often have ripple effects.
4. Create Assets
Once fairly confident that the template mocks provided by our designers could be turned into a rock-solid email template, it was time to slice away and create assets. This includes both graphic elements in the template itself, and placeholder photos from the mockup.
To ensure images are optimized for Retina displays, we exported them from the PSDs provided at 2x size, and then resized down to 1x using the image's width and height attributes. Yes, this is something that email designers do, too!
The exception to this were background images (for example, those used in bulletproof buttons), which were usually exported at both 1x and 2x sizes.
5. Yes, Let’s Code This Thing!
While each Canvas template is designed to be fairly dynamic as far as combining layouts and elements goes, we found that coding a long, static HTML file with placeholder content helped us envision the final product. We developed a framework from scratch based on LESS, with each template's styles.less file containing a number of variables for basic styles and calculations, followed by styles which are specific to the template. CodeKit was used to process the LESS files and speed up browser testing.
As an aside, the ever-helpful Stig on our team created a Chrome extension for overlaying the PSD designs over HTML pages. Called Blueprint, this extension allowed the team to achieve an unprecedented degree of pixel-perfection.
While a lot of folks may rail against making things look "the same" across all email clients - or browsers for that matter - there is certainly virtue in aspiring for that goal, to achieve a level of quality and perhaps even appease a fussy client to some degree!
6. Test IRL, Not Just Virtually
As far as testing both the "desktop" and "mobile" versions of an email design goes, our process was not that different to what happens on the web. Sadly but truly, we'd do a lot of squishing and stretching the browser.
However, at least as far as testing goes, simply viewing the template in Chrome (or your browser of choice) is never enough. At this stage, we'd usually import the campaign into Campaign Monitor to run a quick Design and Spam test (being an email project) and/or tested in Litmus (which also provides automated browser screenshots). If the design looked off in virtual tests, we'd progress to live device tests.
In addition to using a few virtual machines in VMware, we also turned to our "device lab" - largely consisting of mobile handsets - in order to test as thoroughly as possible. If you don't have the benefit of a device lab in your workplace, check out OpenDeviceLab to see if a publicly-accessible collection of devices exists in your area.
7. Calling it a Day
Once satisfied with our work, coding these templates became no different from any other project. At Campaign Monitor, we use GitHub to commit our work and collaborate on any outstanding rendering issues, as well as loop in testing and design where required. If you haven't used GitHub before, readwrite has an excellent beginners' guide to get you started.
Admittedly, more often than not these steps would bleed into one another, or be repeated; web and email coding and testing is seldom quick, clean or without incident. However, end results speak for themselves - a first batch of ten robust templates, delivered on time and now ready for everyone to use. Check out Canvas when you next need to send an email newsletter that looks great on mobile devices, as well as Gmail, Apple Mail and all the usual clients.
What You Can Learn From Our Workflow
Both the processes and tools used to create and collaborate with others didn't come to us in an instant - but given the multi-week timeline of the project and that we got to work on similar tasks repeatedly, we did have the benefit of being able to improve our workflow as we went along. Following this project, our recommendations to others are to:
Have a plan documented publicly.
The above steps were outlined in our internal wiki before work commenced; having this guide/specification accessible to everyone allowed new and remote staff to get up to speed very quickly, while giving other teams visibility over how the coders work. This document was refined as we went along, thus providing everyone with the latest information.
Look at how existing tools can be used in your workflow.
While there's always the temptation to "shop around" for the latest and greatest when commencing a new project, forcing everyone to adopt unfamiliar apps can create unnecessary challenges. Talk to other teams about what they use to collaborate and see how they can be adapted for your own tasks.
Take the time to scope out a design.
In both email and web projects alike, there can be disconnects in what designers, marketing teams, sales and others think is possible and what can be done as a coder… Especially when there are deadlines to meet. Take the time to conduct your own discovery and set expectations - spending a few extra days experimenting and discussing tasks is always better than missing an important milestone, or under-delivering!
Testing doesn't just happen in your favorite browser.
How does your design look on Android devices? Even if you don't use one personally to browse, 33% of the US does - and this percentage is much higher elsewhere. The more platforms you can test on, the better.
To Sum Up
So, while there may be big differences between how email and web work is coded and produced, the steps required to bring a designer's vision to life are just as relevant. Hopefully our experiences will help you formulate a plan for your next code project, as well as ensure your team remains happy and productive when collaborating together.