Most of us know that email development can be a bit tricky and that it doesn’t typically follow best practices that we see across websites and applications. In short, it can be a pretty frustrating process, especially, if you’re planning on creating a whole set of custom templates for your business needs.
This is where a solid workflow can help, breaking up the development process into manageable chunks and making sure we don’t get too far down the road before noticing a big problem.
Before you jump into building a workflow, there are a couple things I’d like you to consider. Understanding these points will help save you time, which is the whole point of all this.
I can’t stress enough the importance of taking some time to educate yourself on the best practices for email development.
Not all email clients are created equal.
Some do a fantastic job of rendering modern HTML and CSS, similar to how we’d build a website or application.
However, there are also clients that require creative solutions for building layouts and adding styles. This is constantly changing as new devices are released and the world changes how email is consumed. Litmus does an excellent job of providing resources for email developers and I highly suggest you begin your journey there.
It’s equally important for you to understand your audience before you get too far along in the development process. This is important because if you know the types of devices your users will be reading your emails on, you can build around those and learn about any known issues others have run into when building their own emails. Researching the market share for email clients is a great way to get started if you are unsure which clients your users will be using.
Now that we’ve covered a few things to consider before starting, let’s talk about how to define a workflow. These aren’t rules written in stone, but guidelines you can follow and modify based on your specific needs.
Before you ever write a line of code, sit down and map out the types of emails you’ll be sending. Is there any commonality across the templates? I’m assuming you’ll find things like a header and footer that can be shared across all the various types of templates you plan to create. Perhaps there are common elements you’ll be re-using like buttons and images.
Break down your templates into small pieces so you only have to build and test those things once.
It’s important to start with something simple. It might be tempting to start with your most complex template as a challenge and to just get it out of the way, but hear me out. Starting with a basic template allows us to test the basics we’ll build upon when we get to those more complex templates. You don’t want to find out your email template is broken after you’ve spent 8 hours working on it.
Throw together a basic layout with your header, footer, and some simple content. Test this template and make sure it looks consistent across all the email clients you’ll be targeting. If something is broken at this step, it’s much easier to track down the issue compared to a more complex template with various sections and content where any one of those sections could be causing the problem.
As we talk about starting basic, don’t feel like you need to create all this from scratch. There are many examples out in the wild, both paid and free, where other developers have done a lot of the hard work. You can always start with something close to what you’re striving to achieve and modify it to meet your needs.
I’ve created some starter templates for our customers to use, and you can try them for free. There are other great resources out there too, like Litmus and HTML Email.
Let’s face it, doing the same thing over and over is really boring and not productive. Sure, it’s not hard to copy and paste your header across all your templates, but what if it needs to change and you have 10+ templates that all have the same header? It’s a pretty arduous process and contradicts a strongly held developer rule, don’t repeat yourself.
Consider using a template language to help break your templates into pieces that you can update individually, like a header or footer.
There are countless templating languages out there, so you’ll need to do a little research to see what fits your needs, but Handlebars, Nunjucks, and Pug are some great options. Each has their own pros and cons so make sure you understand what you’ll be getting with each before moving forward.
Build tools can help automate a lot of repetitive tasks. Do you want to write your CSS in a separate file and have it automatically inline those styles into your template? A build tool can help you do this. Need to test your email and don’t want to have to jump back and forth between your editor and one of the testing services?
Connect your build tool and just run a simple command to do it for you.
Or it can be as simple as refreshing your browser automatically as you work so you don’t have to do it yourself. The options are endless with what you can do with build tools like Gulp and Grunt.
It’s pretty easy to fall into this trap, but don’t rely solely on your personal devices for testing. I’m going to make an assumption here, but most of us who work in tech are typically armed with shiny new pro computers and smartphones. I wouldn’t be surprised to hear your email template displays perfectly in Chrome or Mail for iOS.
Test your templates against the devices your customers are using and you’ll be set up for success.
Additionally, make sure you test as you develop.
Tracking down what exactly is broken can be pretty challenging when you have a lot of sections and content.
An email development workflow is intended to make the creation process and maintenance of your templates easier. The process of setting up a workflow can be time-consuming, especially if you plan to use a templating language and a build tool to automate repetitive tasks. However, that initial investment in time will pay dividends in the future as you maintain your existing templates and add new ones along the way.
When you need to make a global change, like a logo or social media link, having this tooling in place will save you a lot of time. And, as I mentioned before, don’t feel like you need to create your own workflow, use one another developer has invested time in building and testing. You can always start there and build your own solution down the road when the need arises.
