Emails aren’t as simple as you think
Published: January 17th, 2018
I wish I could get this point through to so many people. People who don’t take enough care in the design of an email to listen to the development team. Especially when they keep letting them know the limitations of their design options. To the people who review them and don’t take into account the time needed to make these things. Emails would be a simpler process if everyone took efforts to learn some simple truths.
Truth #1 — Design isn’t the whole email
Depending on your target audience your design may or may not have to change. Everybody wants to have the fanciest designs and use the newest shiny bauble. This isn’t plausible in every project. It’s sometimes about delivering actual important and good content to your subscribers. They don’t care how fancy your email is. They don’t care that you have integrated video capabilities which is functional on 20% of email clients. They are viewing this email on their few or one device. If they can view it and read it, they are good.
Truth #2 — Specificity helps in troubleshooting
The sheer amount of email clients makes troubleshooting a very difficult problem. Being vague about a problem encountered is one of the most annoying things. Try and be specific in the nature of the problem. It will go a long way on cutting down the troubleshooting hunting-down-the-problem phase. Instead of a vague “this image is cutoff” a better option would be “in Outlook 2016 the second image is cutoff at the bottom”. It’s a simple difference but it makes figuring out the potential problem, so much easier.
Truth #3 — Digital means perfection is impossible
Pixel perfect isn’t happening on the web. It’s a ridiculous expectation. No consumer, besides #emailgeeks, will be comparing the email in gmail vs outlook vs apple mail. People will open the email, read it and then put it aside. They will not notice the rounded button on gmail versus a square button on Outlook. We–development, design and management–spend more time worrying about that they any consumer will. It hampers our ability to deliver good content to our subscribers if we are too nitpicky about the email.
Truth #4 — Work as a team for the best output
Siloing the process doesn’t help make a good product. Without having development involved in the beginning process they can’t help creative. In a case where creative is making poor design choices. Or, making promises that development may or may not be able to keep. Having those checks and balances is necessary to making a good product. Having knowledge of what is coming down the pipeline is crucial for maintaining build expectations and prioritizing.
Truth #5 — Consistency is key
Both in design and development. If your making a series of emails there is no need that each needs to be unique. They should have consistency in font-size, logo layout, footer placement and content. People don’t necessarily care about the overall design but a constant change in layout will confuse them or just be generally off-putting. This also helps with development. Emails are created quicker when you can reuse the same templated pieces over and over again.
Truth #6 — Email are not websites
This is a big one, I know a lot of people get confused about the limitations of emails. They see all the cool stuff happening on the web and want to replicate that in emails. Yet, emails are not and will never be mini websites. They will get close but using javascript and linking out to stylesheets, probably won’t become the norm. Mostly because of the hacking risks that would pose, having someone be able to inject something malicious into your emails from an outside source. Try and stick to the limitations of emails and your target audience. Those are more important than tricks.
These are a few crucial things to remember when working with email development, design and/or management. The development team isn’t being difficult or not wanting fulfill your vision. Sometimes people just need to get on the same page and work together to create functional and great emails.