This information is part of my presentation at the Email Innovations Summit on June 19, 2019.
Timing is critical in hiring a freelancer. Not only is there the time the work will physically take to create, but your freelancer also needs lead time. If you want to get the best designer or developer in your timeframe, you need to contact them early. How early?
You need to contact your freelancer to reserve your spot in their schedule at least two weeks before your go-live date. The more time your freelancer has, the better your email will be. If you're in a jam and have less than a week, be prepared to pay a rush fee.
Communication between you and your freelancer is critical for efficiency. The more detail you give, the less likely your freelancer will have to bill you for clarifying questions. The best way to communicate effectively is to have a single point of contact. The designated communicator needs to be the font of project information and resources. The less the freelancer has to hunt down answers to their questions themselves, the more they can focus on making your email the best it can be.
Your freelancer needs the basic information to design an email that is in line with your brand. This basic information includes your brand's hex colors and fonts. You also need to give your freelancer a high-quality version of your logo. A crisp email design with a fuzzy logo isn't going to represent your brand very well.
Your freelance designer needs you to give them a jumping-off point. The worst thing you can say to a designer is, "I just want to see what you come up with."
We all like creative freedom, but you need *something* to start from. What kind of email is this? What problem is the email trying to solve? What are its goals? How will you measure its success? The answers to these types of questions can help inform your designer when making choices. Sometimes inspiration for your design can come from browsing sites like reallygoodemails.com to see what your competitors have done. Showing your designer what you like and what you don't like in existing emails will give them the basics on your preferences, and that's somewhere to start.
You're taking a risk by not having your content finalized by the time your freelance developer starts coding. Placeholders don't always match the final content in word count, line breaks, point of focus, size, etc. This can cause big differences in the layout of the email — big issues you'll have to pay to fix.
All ESPs have their quirks, and some are more quirky than others. How they process the code matters to your design. Here are a couple of examples:
Campaign Monitor will only allow you to use a limited editor on custom emails. There's no drag and drop. You're given a way to swap basic images and a rich text editor for text, and that's it. If your email has background images, you have to change it inside the code.
Mailchimp takes the code your freelancer gave you and reformats it to over double the original size. File size is important because at 102 KB, your email gets clipped in Gmail. Mailchimp takes every style declaration and puts it in its own media query. And all those media queries are in one style tag. Gmail App has a quirk that when there are too many styles declared in one style tag, it just ignores them. So your email renders great on iOS Mail and Samsung's mail app, but looks wonky in Gmail App. With Gmail now #1 in email client market share, having code bloat like this can be detrimental to your campaign.
Make your mockup as detailed as possible to speed up coding. Every element of your mockup has to be investigated one by one to know its size, color, and so on. That's what your developer needs to do to recreate your design in code. So, the more information you can give them about the mockup, the better. The best mockup I've ever worked from had notes next to every piece of copy telling me the color, the font, the fallback font, and the line height. It also told me how much padding to use, which saved me tons of time. Normally I have to measure the amount of padding with the marquee in Photoshop. Their emails were cheaper because their designer put in the work before I was even involved.
You might be thinking, “I can speed things up even further if I cut the images for my dev!” This is not true. By delivering cut assets, you might actually be slowing down the process.
- White-space: Cutting images to use whitespace as a layout is a bad idea for many reasons. Side-by-side linked images can cause errant clicks. Think about the average thumb size. If the thing that separates your links is linked, you're going to get accidental clicks, which may confuse your recipient.
- Background color: By cutting an image with a background color, you are limiting the places that image can be used. You might find yourself needing to use a graphic you've previously cut before, but on a different color background. By letting your freelancer cut the images for you, you save time by using the same image over and over in different contexts.
- Baked-in text: We have all gotten an email that is blank, save for a lone unsubscribe link at the bottom, because all of the text is part of the images, and images are blocked by default. Your message will never get to the customer if you use baked-in text. “But what about alt text?” you might ask. You're right; alt-text is best practice and is necessary for image accessibility. But you know what's most best practice and most accessible? Real, live text.
- Buttons should be HTML: I'd argue that CTAs with live text are even more important than live body text. The purpose of an email and its content is ultimately to drive the subscriber to take an action. If your CTA is an image, it will get blocked. It becomes one more grey outline and red X, indistinguishable from every other blocked image.
It might not seem like a big deal, but having the URLs to your custom fonts to give to your developer before work starts is huge. Let me show you why.
This is a GIF (sped up 20 times faster) of me locating the client's custom fonts on their website and implementing them in an email. I first get the name of the font from the mockup, go to the client's website, inspect the code, find the font, click on the CSS doc that declares the font, copy the CSS, paste it into an editor, find the declarations, copy them into the email, and finally format them. This process can take up to 25 minutes to implement. Do you want to pay for a quarter- or half-hour of your freelancer just finding necessary elements of your design? Probably not.
Providing the font files directly to your freelancer in a ZIP is handy, but that doesn't solve the issue. Your custom fonts must be hosted on a server somewhere, and your freelancer can't do that for you. Chances are, your front-end web developer can tell you the paths to your fonts. And they can do it in way less time than it takes for me to find them.
There are certain situations in which your freelancer needs access to your ESP.
- Modular system: Your freelancer must have access to your ESP if you are having them build you a modular system. Creating a modular system inherently includes structuring the code in a way where chunks of code can be inserted into a frame in any order so you can create a multitude of different layouts. Though implementation of a modular system is different depending on your ESP, it will always require setup of content blocks and a frame. This is delicate work, because if even one tag is in the incorrect content block, your system could fail.
- Dynamic content If you have dynamic content in your email, your freelancer needs to be able to set it up for you. There is no way to test dynamic content without access to the ESP. If your freelancer can't test thoroughly, they can't ensure that your email will function correctly.
- Errors messages If you get errors when you input the final code into your ESP, your freelancer needs to be able to see what the error is and when it happens. Trying to fix issues from a screenshot is like trying to do surgery over the phone. Most error text in ESPs is general and could apply to anything, so most times your dev will need to get into the code inside your ESP and troubleshoot.
Your freelancer is probably quite educated on best practices in email. When dealing with more than 400 renderings every day, one tends to find patterns. Use your freelancer's expert knowledge. As a freelancer, your goal is to produce an email that brings in the most money. I can't do that effectively when I come up against inflexibility. I'm not saying you always have to take your freelancer's advice, but I am saying you should listen to it and process it.
If you'd like to change anything in the HTML yourself, make a copy of the original first. Do not modify the original HTML. Not every freelancer keeps backups. If you change the original, you might end up having to pay your freelancer to change it back.
You can save a lot of time and money if you know what email clients your audience uses. Email coding is full of hacks and structures that aren't necessary in web coding. Each email client has its own hacks. For example, if you know that only 1% of your audience uses Outlook, you might make the choice to not code for Outlook. That would save your freelance email developer tons of time by not having to use ghost tables.
Knowing the email client usage of your audience can help in other ways as well. If the majority of your audience uses iOS, you know that it will be worth the money to let your freelancer design and develop more engaging emails with CSS supported only by iOS.