I’d wager that if you’re working in email design—down in the trenches, knee-deep in tables and testing tools—then you come from a web background.
Email probably wasn’t your first choice, but it’s either something you took on and now love, or something that you have to deal with regardless of how much you hate it.
It used to be that email and web design were pretty much identical. Back in the days of table-based layouts and spacer GIFs, both the technology and techniques involved in both pursuits were one in the same. But, some time in the mid 2000s, the mediums diverged.
Now, we’re seeing another paradigm shift. Web and email design are once again converging as email design starts to catch up to its more advanced cousin. I like reflecting on the industry in which I spend most of my time, so this post is an opportunity to look at how email design is using the state of the web to evolve beyond the archaic process we all know (and love?).
At the most basic level, both the web and email are built using the same things: HTML and CSS.
We’re stuck with the way the web was.
We use tables and inline styles. Some of us still use spacer GIFs. Due to the limitations of the many, many shitty email clients out there, we have to build in a way that’s reminiscent of 1998.
It sucks, but there’s hope…
As mobile has grown both for the web and email, we have had to hack our way to responsive campaigns. Everyday web technologies like media queries, CSS3, web fonts, and SVG are now making their way into email design.
More importantly, some designers (cough, cough… Kevin… cough) are using all that cool web stuff that leaks into email to develop some revolutionary techniques.
The technology leaking into web design is cool. But what is really amazing is what that technology allows you to pull off. Gone are the days of completely static, boring emails. Using all that good web code, we can now reliably use things like CSS3 animations, SVG, web fonts, and even HTML5 video in email.
At least in some clients.
These techniques require an intimate knowledge of your audience and where they are opening your emails. As such, not too many designers are using them. Yet.
But, as more designers use these techniques (and learn and teach others about vital strategies like email client targeting), we’ll see advanced email design concepts implemented at a larger scale.
With any luck, this will help achieve a few things:
- Further refinement of these techniques, making them more reliable for everyone.
- Increased pressure on email client vendors to support things like CSS3, better HTML, etc.
- Increased engagement and connection with our audiences.
Those first two are more or less for our benefit. As email designers, we’d love better email clients and bulletproof techniques. But that third one is the biggie. We want to use these techniques to connect with our audiences at a level previously unseen in email marketing.
While I firmly believe that not every email campaign needs insane animations, HTML5 video backgrounds, or even web fonts, I’m looking forward to the day that both email designers and their subscribers are comfortable with all of this cool shit working in a wide range of email clients. And I’m supremely excited about what these techniques will mean for building relationships between senders and their subscribers.
One of the most interesting intersections of the web and email revolves around the processes we use to build our projects. For the longest time, email designers have been stuck in Dreamweaver, either hand-coding each and every campaign or relying on snippets and poking around in the design view to achieve what they wanted.
Web designers, on the other hand, have been steadily refining the process of building for the web. Countless tools exist to make designing, coding, and publishing web sites and applications more reliable and efficient. Frameworks, build processes, package managers—they get it all.
Now, a few intrepid email designers are taking those same tools and applying them to email. Brian Graves recently published a great article on Smashing Magazine about how he uses Sass, Middleman, and Grunt to build email. All of these tools are standard for web designers but are a new concept for the majority of email designers. Dan Denney and Lee Munroe both posted recently on how they use similar tools to improve their workflow.
I know a lot of email designers will resist updating their processes (and not everyone needs to, either), but for a lot of email designers, these tools are a revelation. The automation they provide means that not only are your builds generally quicker, they are more robust. When you’re not writing each and every line of code by hand, fewer mistakes creep in and your emails are the better for it.
Sure, it takes an initial time investment to set up, test, and learn these tools, but once you find a good process, you can use energy previously spent on hand-coding and manually fixing mistakes on more important things like creating valuable content and interacting with your subscribers in a more honest, human way.
So, what’s next?
I don’t know. Things are changing quickly. I think we’ll see people continuing to push the boundaries both of the code used in email and the tools used to write it. More importantly, we’ll see more designers openly sharing what they are doing and why. Once all that information is out there, we can all start focusing less on hacking our way to decent emails and more on building amazing experiences and relationships with email.
I can’t wait to see what’s next.