How we approach designing transactional email templates

Matt: 00:06 Email clients are like web browsers in like the '90s when everybody was doing their own thing. And that's why email, they've got a lot better, but when you're still supporting older email clients, that's kind of what it's like. You do all these weird hacks, but like one specific email client that you're at least 10 years ago.

Marek: 00:24 Hello, and welcome to Talking Email with Postmark. I'm your host Marek Loder, and in today's episode my guests, Matt West and Derek Rushforth, both tenure designers here at Postmark, will share real-life examples of how we've approached designing and testing templates here at Postmark. We'll look closely at some recent changes we've made to our transactional email templates and touch on key considerations and important lessons we've learned along the way. In sharing our own experiences with template design, we hope that you'll come away with some ideas on how you can improve your own transactional email templates for your business or side project. Hope you enjoy the episode.

Marek: 01:04 Thank you guys for joining me today.

Matt: 01:06 Hey Marek. Thanks for having us on.

Marek: 01:08 Let's maybe start out with some quick intros. Matt, you're a self-taught designer and spent the early part of your career freelancing and working for web agencies. Can you briefly tell us about your early days as a designer and what ultimately led you to Postmark?

Matt: 01:25 Sure. So, yeah, after leaving school, I spent about five years mainly freelancing doing web design and development, and then I got to a point where I wanted to join a bit of a bigger team. So I went and worked to an agency and spent 18 months there, mainly doing front end work actually, and then came to the realization that code's great and I enjoy writing code, but actually where I get my most satisfaction is through design. So that's when I started looking for a position that would allow me to do design full time and that's when Wildbit came up. And I've been here about two and a half years now working on Postmark and it's been tremendous fun. So, yeah, it's been brilliant.

Marek: 02:09 Wonderful. And Derek, prior to joining the Postmark team, you served as a US marine and spent some time in Afghanistan. Tell us about your less traditional path to front-end web design and how you got connected with Postmark.

Derek: 02:24 Yeah, so right out of high school, I went to art school for a little bit but I ended up dropping out to join the marines. I spent about six... yeah. I spent about six years enlisted with one tour to Afghanistan. I got to try a lot of different jobs, especially while I was a marine, but it just wasn't something I wanted to make it creative. So most of my enlistment was spent in the reserves, which means I wasn't obligated to be on duty full time. So throughout my enlistment I had the opportunity to work for a couple agencies where I did everything from marketing websites, marketing campaigns and web apps.

Derek: 02:59 That was really helpful for me because it just kept me interested in design and coding and I was able to just learn a lot from them. Then later on I found myself wanting to transition to product work and I came across a job posting from Wildbit and it was awesome, so I submitted my resume and yeah, that was five years ago and it's been great.

Marek: 03:19 Well, we're certainly lucky to have both of you guys with us at Postmark and I certainly love working with each of you, so thanks for that. All right, well, thanks for joining us guys. Let's maybe jump in and get us talking on email. To give our listeners some context, just a few weeks ago, we redesigned a number of transactional email templates for Postmark, which was ultimately the inspiration for this episode. Matt, you worked on this project. Could you start by telling us which emails were redesigned?

Matt: 03:52 Oh, sure. So a ton of them. Basically, we touched almost all of the emails that we send out through our rails application. So most of the emails that customers receive from us got at least some sort of update. Some were updated more than others, but yeah, it was a pretty big project.

Marek: 04:17 Yeah. We're going to touch on a that project. And before we jump into the why and how we approached the redesign, I just want to make sure that we're all familiar with this concept of transactional email. Derek, can you maybe just speak to what a transactional email is and how it's different from, let's say a marketing email or an email sent from a local mail client?

Derek: 04:41 Sure. So a transactional email is triggered by a user's action. It can be very through like a web or a mobile app. A good example is a password reset email code activation or a comment notification. And people typically expect these to arrive at their inbox. So by nature, they are time sensitive. Most people generally don't want to like sit around waiting for forever for a password reset email to arrive. Whereas marketing emails typically consists of newsletters or any type of like promotional email. In most cases, a bunch of other people received the copy in the same email since these are generally sent to large lists.

Marek: 05:20 Okay. So transactional email is really an event triggered email that's time-sensitive?

Derek: 05:26 Yeah.

Marek: 05:27 Okay. With that, Matt, can you maybe tell us a bit more about what changes were made to our templates and perhaps more importantly, why we made them?

Matt: 05:38 Sure. So, to start with the why, over time, the Postmark has been around a little while now and we've added more templates. I was with Bill on new features that required them, and we got to a point where some of the stuff we were sending out was excellent, some of the stuff wasn't quite great and then some of the stuff was just plain outdated. So we... for instance, we had some emails where we were sending out plain text versions, but there was no html by equivalent. Some emails it was the other way round, we were sending out html emails, but we weren't intuiting a plain text version. Some of them, there wasn't a clear call to action or we had... we needed to update some copy to make things clearer, so there was a lot of tidying up.

Matt: 06:23 And the actual templates that we use as well, we changed our style about 12, 18 months ago and switched to a newer template layout for a lot of the stuff we were sending, but some of our older emails, so like our welcome email and our signup email for example, we're still using quite an old template, and a lot of the design motifs in that, we don't actually have that even in the web app anymore. So it made sense to update them, bring everything in line so it was all consistent. So if you get an email from Postmark as a customer, it's going to look the same across the board and you're not going to get one welcome email that looks in one style and then a reset password email or something that looks completely different. So just making sure that that's consistent for customers as well as a big point.

Marek: 07:14 Okay. So it sounds like there's a smattering of emails that were in different states. And that was one of the key things you'd want to do is tighten the branding, bring all the templates to the same level of clarity and design. So, you and I assume our product manager probably talked through this project, discussed some of the timing and the priorities and agreed that it was worth investing some time on this project. Walk us through how you approach a design requests like this, Matt, and maybe where did you start?

Matt: 07:50 Sure. So, to start with, we've been collecting a lot of things that we'd like to do to improve these emails for the past couple of years early, and adding them all and noting them down. And it got to a point where luckily we had a break in the regular project work that I was, that I had. It just seemed like it was the right time to tackle this. So fortunately we were able to carve out the time for it and prioritize it so that it was something we could work on. My first thing that I'll always do is just inventory what we've got. So it was a matter of just going through all of the emails that we have, figuring out what state they were, are we sending both html and plain text versions? Are they using the latest design style? Is everything up to date? Are we doing in our own emails what we always ask our customers to do?

Matt: 08:41 We're really great. We've got loads of guides on our website for how to create a great welcome email and are we actually leaving those recommendations in the stuff that we send out? So it was a matter of going through everything that we've got and trying to identify ways that we could improve them and then merging that in with all the ideas that have come up probably for the past couple years and that we've noted down and the smaller things that we've said, "We don't have time for this right now, but we really want to get to it at some point."

Marek: 09:09 And with that inventory process, is there anything specifically that you like to use? Is it just a paper doc or a Google doc or do we actually have some other tools that we rely on for that?

Matt: 09:21 Sure. So, my first core was to basically just create a big table. So, I think it was in a paper doc and just list out all the templates we've got, what versions do we currently send out, what style is it, does this need updating, does it not? What are the main issues? And then I'll go through and take screenshots of all the emails that we're sending as well. And the way that I approached that was basically just to create a sketch file and dump all the screenshots in that and then we use Abstracts on the design team for getting design feedback. So I just put them all into a Sketch file, sample branch and Abstract so I can keep track of all this work, and that gives me a starting off point so I can run through the visual of the templates and figure out what's working, what's not and what we need to update.

Marek: 10:04 Okay. And for just non designer like me, I'm not as familiar. I'm familiar with Sketch but not Abstract. Can you just speak to a little bit more about what Abstract is typically used for?

Matt: 10:16 Sure. So Abstract is it's a design feedback tool, but you can think of it like get for designers.

Marek: 10:23 Okay.

Matt: 10:23 So it allows you to basically work on design files but keep versions of them and you can do things that you were doing get creating branches when you're working on a particular task or project. So we can do all that and maintain a master version of our designs but then also branch out. So whilst we're experimenting on stuff that's not affecting what any of the other designers on the team are doing.

Marek: 10:46 Cool. That's helpful. So it sounds like big table sketch file for all the images or the screenshots that you capture and then using Abstract to collect feedback from the team.

Matt: 10:58 Absolutely. Yeah.

Marek: 10:59 Okay. And Derrick, would you approach a design request in the same way as Matt? And perhaps more broadly, is there really a right or wrong way to approach this sort of request?

Derek: 11:09 Yeah, I think I definitely would approach it in the same way. It's really important whenever you're taking on a set of existing emails to expand to go through them all and inventory them, just taking get that birds eye view of things so you can spot those inconsistencies and just get an idea of the visual elements that the emails are comprised of so you can break things down into smaller bits. But the approach would probably be a little... my approach would probably be a little different as opposed to if I was starting from scratch, but I think that's... I think Matt's approach for taking over an existing set of emails is definitely the right way to do it.

Marek: 11:48 Well, I actually... I'd actually love to just touch on that a little bit. I certainly recognize that our focus here today is to talk about our redesign, but maybe you could just touch on, if this was from scratch, if we're a new business and we haven't actually built any templates yet, what would be different about the approach?

Derek: 12:10 Yeah, so for me at least, if I was starting from scratch, first thing is to identify the emails that your application's going to be sending out. So, you have things like welcome emails, password resets, just understanding those things. Just having a scope for your project and then I would probably start with focusing on the content first. And that's just opening up my text editor and just thinking about what I'm going to say because emails ultimately they are comprised of words and it's important that you know what you're going to communicate to your users before you actually figure out what it's going to look like. And then from there, just get some feedback from the team and then I would go into just building out that visual language in Sketch design, figuring out what the components are going to look like, the overall look and feel of the layout, et cetera. And then from there I would pop the continent in and build on that.

Marek: 13:09 Cool. Perhaps we can, I mean it sounds to me like one of the key things, and I think you both touched on this, really is focusing on the content. The design is critical, but part of what informs the design is the content itself. Going back to this project, Matt, maybe you could talk to us a little bit about how we make decisions about what information to include in these templates. Can you just walk me through some of your decision tree there?

Matt: 13:40 Absolutely. So at the end of the day, I always comes back to what's the customer's need. So we're sending this email for a reason. So if it's a password reset email, they've requested that because that took on that password and there's going to be a link in my email for them to go and reset it. So that's always going to be the key action for the email and we need to keep that front and center the whole way through. And that informs what the copy is going to be, it forms what the main call to action is, how we display that. The whole email revolves around what it's first purpose is.

Matt: 14:12 So I think that the most important thing to begin with is to identify that single purpose for each of the emails that you're sending, and that's especially important for transactional because in most cases a transactional email is only going to have one main call to action where in order to preserve that float, because all of the time, email is used either as a delivery mechanism for a particular message in sort of an asynchronous manner, so for example, an invoice email would be a great example of this. Like say someone's subscription renewed, we send them an email with the invoice.

Matt: 14:47 They didn't request that straight away, but it's still an event triggered email because it was triggered by the renewal of that subscription and that... the key point of that email is once you notify them that their subscription is renewed, successfully bought, so it's deliver that invoice. So if they have to send that on to other like an accounting department or whatever, they have that. So it's really key that we make that really easy for them to get hold of. Whereas a password reset or say, user invitation email where they need to click a link to activate their account, it's always going to be that link that needs to be the focus. So that's the first thing to start with and then build out from that.

Marek: 15:25 All right. So with that, it sounds like the customer need is ultimately the driver behind the content decisions, the design, call to action. Perhaps we could talk about how that all comes together in layouts. Derek or Matt, do you guys want to speak to how we think about layouts as we are trying to fulfill that customer need?

Matt: 15:46 Sure. Derek, do you want to handle that one? You literally just worked on a layout speed test.

Derek: 15:52 Yeah, just in terms of layout design, I guess I'll touch on my preference for layout design, aside from just the content... approaching it from the content first, but for me I just, when it comes to the emails, I always try to just keep it really simple. You have a lot of email clients that you need to be compatible with, so it's super important that you try to reduce the amount of columns that you have. I usually generally try to stick with a single column layout and I think that really helps when it comes to mobile as well. A lot of times you approach things from a mobile-first approach, so you consider the simplest form factor first, and that's generally always a single column layout. You don't want to stack things side by side. You want to have clear call to action and just the good flow for your email. So that's generally how I would've approached it. It's just to keep it simple.

Marek: 16:46 So let's talk about this mobile-first approach. It sounds like the single column is your preferred method. Matt, I should ask this, is that the same for you?

Matt: 16:57 Yeah, I know I would I agree with. I think keeping it as simple as possible so that you're... that whatever action that the customer needs to do with that email is really, really clear, and then not digging through tons and tons of stuff to find that button that they need to click. On a single column layout is almost always the best solution for that.

Marek: 17:17 Okay. And I want to just touch on an interesting stat on this mobile-first approach. According to the latest US consumer device preference report from Movable Inc, 66% of all emails in the US are now opened or read on smartphones or tablets. With this increasing trend towards mobile, clearly you guys are thinking about this, how we're designing our layouts to be compatible in mobile devices, but can maybe one of you guys tell us a little bit more about how we ensure that our final templates are in fact fully optimized for mobile?

Matt: 17:58 Sure. So we use a bunch of different tools for testing that in addition to some manually testing. So we're sending emails to ourselves and looking at it on our phones and stuff. But we also use Litmus, which allows us to test any amount and see how it pairs on a whole bunch of different devices and different email clients as well. So, that's a really, really valuable tool for making sure that the emails that we design actually work for everybody, and that there's a consistent experience that everybody that receives them.

Derek: 18:31 Yeah. I don't know. We used to do before tools like limits. I think there's a lot of guesswork involved with building emails, but now with tools like this, I think it definitely raises the quality bar for emails because there's really no excuses why something should click wrong and an email claim. And sometimes it feels like stepping into a time machine. [inaudible 00:18:53] trying to support super old versions of Outlook, and so stuffs like this they're amazing.

Marek: 19:01 So how does that work? You basically just have the email, the html, the email, and you just drop it into Litmus and then it basically just shows you how the email will render across different devices or mail clients?

Derek: 19:14 Yeah. So, there's a couple of ways it works. When you can send them, send an email to one of their addresses from your email service provider, and they'll read that email and then they will load it using the virtual machine and took on a bunch of environments in different email clients and I'll take a screenshot of it. And then I'll post a screenshot on their web app, and then you can go through and preview, then approve things or make notes of what needs to be fixed. Another way is you can just literally just copy and paste your email markup into their app and they'll just generate a bunch of client previews for you.

Marek: 19:52 That's awesome. That sounds like a major time-saver for us, huh?

Derek: 19:57 Yeah. Definitely.

Matt: 19:58 Absolutely. I think they've got like a build a feature as well now, so you can go in and edit it live as well.

Marek: 20:04 I know. Wow.

Matt: 20:05 Keeps like re rendering it. It's like the tools that we have now are so much better than a few days ago even.

Derek: 20:11 Yeah.

Matt: 20:12 It's come along a lot.

Marek: 20:14 That's remarkable. So, with respect to tools, it sounds like we use Litmus for making sure that the emails are compatible with different devices and mail clients. Kind mosof moving back to our redesign and getting into the design phase, are there specific tools that you guys like to rely on for mocking up templates?

Matt: 20:38 Sure. So, pen and paper is a great one. If you're are designing a new email, once you got an idea of what content you want and what the main action is going to be, you can be pen and paper for that kinds of stuff, how something's going to work, and then depending on what the email is, for this particular project, a lot of it was the redesigns of existing emails or adding in counterpart versions. So like a html version or a plain text version. So I actually did a lot of the work straight in codes. So, just from got all rails up set up locally and just dived into the code and so mocked things out there because a lot of it was already built out so it kind of makes sense.

Matt: 21:19 But sometimes, so if it's a new email, I might go into Sketch instead and design that in Sketch and then share that image through Abstract or whatever project management tool we're using at the time to get feedback on it. Sometimes that can be a lot quicker than going to code and building something out fully. You can iterate on something a lot quicker in Sketch than you can in code in most cases. But it really depends on what the email is and whether it's a redesign or a complete new email from scratch just what [inaudible 00:21:52].

Marek: 21:52 Derek do rely on some of the same tool sets?

Derek: 21:58 Yeah, I would say my approach is probably exactly how Matt does it with... one exception is I'll say instead of pen and paper, I generally like a text editor before that. I just... because I think about the emails in a linear flow, I just like to structure things out in that way. Depending upon if there's a lot of visuals or actions, I'll go to pen and paper, but sometimes I'll just jump straight to Sketch or I'll jump straight to code if there's already an existing development framework that we're [inaudible 00:22:30].

Marek: 22:30 It sounds like there's really not a great substitute for good old pen and paper or basic text file.

Derek: 22:38 Yeah.

Marek: 22:38 Do you ever use that... you've got an iPad Pro, right Derek? Do you ever use Sketching online instead of pen and paper?

Derek: 22:44 No, I actually don't. I don't like. For some reason I haven't... it hasn't stuck with me. With sketching interfaces and emails for some reason I just don't. It feels a little slower to me. Even though there's tools to help you build shapes and stuff, I would just prefer to just go straight to real paper for some reason. But when it comes to actually doing illustrations and stuff, I prefer to use the iPad, but for sketching interfaces, I don't. I just hadn't stuck with me yet.

Marek: 23:15 That's interesting.

Derek: 23:16 Cool.

Marek: 23:17 To me, you're obviously starting with pen and paper and over text edit, in Derek's case, I want to touch a little bit more on the concept of where we do the final design. It sounds like some designs, some designers prefer to create their designs in a tool like Sketch, right Matt? That was... that's what you used. And then there are certainly other designers I guess that prefer to design them in the browser. Can you guys speak to, maybe Matt starting with you, can you tell us about the pros and cons of each approach and perhaps which situations would dictate which of those two methods you would go with?

Matt: 23:59 Sure. So, I think Derek touched on this as well, but like at the minute with Postmark, we've got a pretty established design framework for emails, so we've got most of the layouts played out. So it's really easy to go straight to code because a lot of this stuff's already built out. So we're really focusing more on content than we are on layout. We're focusing on content and making sure that we're highlighting the appropriate call to action. If it's a brand new product, like when I was in the agency world and we'd be designing stuff completely from scratch, that's when it can be a lot more useful to use the... a tool like Sketch because you're trying to get buy in from various stakeholders.

Matt: 24:40 You've got client, you've got other people on your team that you need to get feedback from. And building out everything from scratch so you can go straight to code, isn't always the most efficient way of doing that because it gets harder to iterate quickly on your designs. So using something like Sketch is really good for that because you're not investing as much time up front in that specific solution. And if you decide to go in a completely different direction, you've not spent... a whole bunch of time is not wasted, but yeah, if you've got an established design framework for what you're going to build and you can build that email with pre-existing components you have, you're focusing more on content than going straight to code and designing in the browser. Totally makes sense.

Marek: 25:23 Cool. And I guess touching on this concept of designing in kind of on local environments or in the browser, Derek, you had actually recently expanded on a hack week idea and launched a command line interface for Postmark. Can you tell us more about where that idea came from and why it's significant?

Derek: 25:44 Yeah, definitely. Andrew, who's one of our engineers here at Postmark, he tossed around the idea of building a command line tool so that you can upload your templates to Postmark and even download them to your desktop with a simple terminal command. He didn't have the bandwidth to work on it, so I decided to build a proof of concept during one of our hack weeks. The cool thing about our command line tools that you can use your own code editor to build your templates, you can start them and get... you can even automate your workflow using continuous integration tools like Travis or CircleCI, where else before this, you're pretty limited to just using the template editor in our web app. And writing code in the browser usually has pretty limited functionality and it can be a bit frustrating. So the command line tool is nice because you can simply just use the development tools that you're comfortable with.

Marek: 26:34 Cool. So, and you mentioned there are some limitations to writing code in the browser. Can you maybe just elaborate on that a little bit?

Derek: 26:42 Yeah, so a lot of times when you're writing code directly into a template editor and browser. It's really depend on how it's been implemented by whoever built the editor. A lot of times you've got like a million other tabs up until you're dealing with other distractions in your browser as well, so performance is a little limited there as well. You can't... a lot of times those templates, they're not sitting on your desktop, so you can't actually interact with them locally or use the tools that you're comfortable with. So you're forced into using the tools that have been provided for you by whoever is your email service providers.

Marek: 27:23 So it sounds like by using this command line interface for Postmark, you're able to utilize your own code editor that you're familiar and used to. Matt, can you maybe speak to your preferences with respect to where you actually modify and edit the code?

Matt: 27:44 Sure. So, I pretty look at him in the eye. I always liked to do things lightly. So I like to use the text editor. I use VS Code and those things and I'm comfortable there. I know all the shortcuts. That's where I want to do my development. So if I'm writing code in an editor in the browser, I find that I'm not as productive because I don't have all the tools that I'm used to there. So for sure, the CLI tool has been massive because being able to sync your template style to your local machine so you can use the tools you're already comfortable with, is so much better than trying to use something that you're not. I shouldn't say that the template editor and Postmark's not too bad, sorry, but it's alien if you're not used to using it. So, yeah, for sure, I always prefer to do things locally if I [inaudible 00:28:33].

Marek: 28:33 That's awesome. And I guess in that same vein, with respect to we're in ESP, right? And there are plenty other ESPs and each ESP offers their own specific design framework. We built an open source template tool cape called Mail Mason, and I believe that was to help. It's a tool that we use to build our own templates. Derek, do you want to tell us a little bit about Mail Mason and why we decided to build it and why you might want to actually use it?

Derek: 29:05 Yeah. So sure, a few years ago we opened source Mail Mason as like a workflow for developing email templates. It's a complete tool set that uses Mail Jazz and Grunt Jazz. That lets you build templates using tools like SaaS, which is a pre-compiler for your CSS and handlebars for your templates. And if you've built templates before, you'll know that trying to follow the best practices can get pretty tedious and sometimes you want to rip your hair out. So, Mail Mason automate things in line in your CSS for you automatically, which is best practice if you want to have email client compatibility across a bunch of devices and stuff. And then it automatically generates text versions for your emails and even you can even quickly send test emails to the inbox or quickly to Litmus from your own desktop.

Derek: 30:04 So basically this kind of enables... it's used in conjunction with the CLI tool, so you can use it with your Postmark templates, but ultimately it just gives you more power and control over your templates and you can also reduce certain bits. So, going back to how we use handlebars for templates in Mail Mason wheeze, is you can use things like partials, which are essentially like reasonable components. So if you have a button component, you don't need to... you can have one button component and you can reuse that same button, that same markup across all of your email templates. And you don't have to, if you have to make a change to that button, you only make a change to one partial file. And so it just really makes the maintenance a lot easier and it saves you a lot of time down the road.

Marek: 30:51 And I mean it certainly sounds like using a tool like Mail Mason in conjunction with perhaps CLI, is really powerful. Matt, when we actually went through this redesign process for our templates, did we utilize any of these tools?

Matt: 31:07 Yes. So we didn't actually use Mail Mason for this project to redesign our transaction emails, but about two years ago, not long after I started, we did a big redesign of all the our email newsletters. And one of the thing, the challenges are all, but is because we have multiple products, we were struggling to maintain email templates for all of our different products. Because we have newsletters, we'll go out for Wildbit, at the time we still own DeployBots, so we were sending out newsletters for DeployBot, we have Postmark, we have Beanstalk and we had, Conveyor was just emerging as well, so we needed to solution there. So it was getting a bit of a nightmare to manage all these templates.

Matt: 31:45 And we actually used Mail Mason with a slight modification, and designed basically a system of components for creating newsletters. So we had a components, featured article components, takes blocks like call to actions, all these different things that we could use to construct a newsletter, and then created one centralized configuration which basically contained all the branding for each of our products, for Wildbit, so that with one command we could generate all of the email templates we needed for across all of the different products. So we were no longer maintaining multiple different email templates.

Matt: 32:25 We had one template and we just compounded it down and then it got branded as whatever the product was. And we use Campaign Monitor actually to pro a lot of our newsletters and so we integrated it with all their templating language as well so you can just go into the Campaign Monitor editor and literally build your email from the components. So there's all the control to create those emails without having to go to code as well, which has been really helpful for people. And may or may seem like was instrumental to that. We definitely wouldn't have been able to do it if it wasn't for Mail Mason.

Marek: 32:57 Wow. That was super, super useful though. It sounds like Mail Mason actually is something that can be compatible with really a number of different providers. Is that right?

Matt: 33:06 Absolutely. Yeah. It's not Postmark's specific, so you can use it for anything, whether you use one of our competitors or whether you use Postmark, you can use Mail Mason.

Marek: 33:16 Wow. Cool. And just to... for our listeners, Mail Mason is a totally open source tool. So if you're looking to manage a lot of different templates across a single product or multiple products, definitely check it out. I'll include the link in the resources for you for this podcast. All right, well, let's shift gears here. I want to get back to the actual designing of the emails themselves. We all have different opinions on fonts. Can you guys talk to us a little bit about your font preferences and maybe we can start with what we use for our transactional email templates.

Matt: 33:57 Sure. So, our transactional email templates depends on Xbox, I can't remember what type it is. But it is not a word-form. It's a system-

Derek: 34:04 System [crosstalk 00:34:05]. Yeah.

Matt: 34:06 Yeah. I think it's just how vertical it's for use for that because that's our brand style, that and Rockwell, but I don't think we have Rockwell anyway.

Marek: 34:15 Derek, you could talk about Mail Mason because you've just changed the web format [crosstalk 00:34:18] to a different one.

Derek: 34:19 Okay. Yeah. So, with regard to the Mail Mason, we actually going to really sending updates in integrates with Google fonts, so I just went through the fonts there and I'm trying to find something to give it a little more personality. Something like [Ninidu Sounds 00:34:34], I think that's how you pronounce it. So my preference for integrating fonts as Google, I think that's a really fast and reliable service to integrate with, but when fonts can be a little tricky because it's only supported on more modern email clients.

Derek: 34:52 So it's important that you have what they call a font stack, which basically lets you, first you delegate your custom font, and then behind that you can set up your system, say fonts, which you'll pull from the default fonts on that device. So sometimes if a email client doesn't support that custom font, it's going to fall back to aerial athletic or whatever's supported there. So it's a little tricky to make it compatible in our browser, so there's some little hacks that you have to do especially for older versions of Outlook, but our hope is that with Mail Mason, this'll be a lot easier.

Marek: 35:34 Cool. And just for those folks who may or may not give Mail Mason a shot, what are the... some of the considerations for making sure that you guys have fallback fonts, that the font will be supported?

Derek: 35:49 Yeah. So, I think the general question most people use this, this is what I use for Mail Mason, is I'm mostly dealing with some weird quirks with older versions of Outlook. It's almost like a vendor prefixed syntax that lets you target Microsoft clients specifically, where I create any fallback CSS class that has just the default fonts for windows devices. And what I end up doing is I wrap most of the techs elements with this CSS class so that when that custom part won't load, it will end up inheriting that CSS class that's on the html element. So that your term. There's one thing I totally forgot to mention is that, again, so don't put this on the podcast. If you put it there-

Marek: 36:46 This is how complicated emails are.

Derek: 36:47 Yeah. I'm just [crosstalk 00:36:49] because it's really not that straightforward because-

Marek: 36:53 Is the solution to just use a tool like Mail Mason since it's going to do this for you? Is that really what we're getting at here?

Derek: 36:59 Yes, yes. Yeah. You have to, but actually the solution is not that straight forward honestly because even if you have like a font stack, Outlook ignores it and they're just going to default the font to be Roman if you don't do this hack. So it's not like you can't, you... I don't know. So it's hard to explain.

Matt: 37:18 Email clients are like what browsers in like the 90s when everybody was doing their own thing and that's kind of what email... they've got a lot better, but when you're still supporting older email clients, that's what it's like. You do all these weird hacks, but like one specific email client that was released 10 years ago.

Marek: 37:35 So email is really, really complicated. Basically is what you guys are getting at?

Derek: 37:39 I don't know if I can explain this in a clearer way, or [crosstalk 00:37:42].

Marek: 37:42 All right, well, maybe we can just shift gears here. And perhaps speaking of a weird thing in the world of email, we put some really beautiful illustrations in some of these new emails that we redesigned. Matt, are there any important things to keep in mind?

Matt: 37:59 Sure. So, we decided to add illustrations to three of our emails. And the reason we did it was because we wanted to announce that first customer experience is what people have with us, so we put it in the welcoming mail, our sign up email, and then the usual invitation email. Because we wanted that first email that people get from us to be just a little bit special and to represent the Postmark brand a little bit beyond like our standard templates. But there's... for sure there's some considerations that you have to make there.

Matt: 38:33 One is, you quoted the mobile stat earlier, 66% of emails being read on mobile or whatever now, and whilst mobile networks have got a lot better, you've still got to consider like bandwidth and if you're adding this massive animation or something to your email, that can take a long time to load. So you need to keep that in mind because if that's not providing direct value and is indirectly helping to just make it feel nicer and more pleasant to the user, then that's probably... if someone's trying to load that on a really poor connection, you're actually just ending up providing a bad experience. So that's for sure one thing you need to be wary of.

Matt: 39:13 There's also some accessibility considerations as well. They're making sure that you've got your old tags on these things and that they're descriptive so people can understand these if they're using an assistive technology, and a whole bunch of other things. One of the thing you got to worry about is trying to make sure you don't disrupt the flow of the email too much. It's really easy to add some massive, nice illustration that looks beautiful, but if that's not actually helping the customer get to the key action, you've got to decide like is it worth having that huge illustration or should we use something that's a bit smaller?

Matt: 39:48 This still helps to convey the overall feel, but it's not getting in the way of the customer getting to the whatever specific action is an email. So for sure I think they help, I think there's a big trend at the moment to use a lot of animation in email and start getting a little bit more interactive, and some of that stuff's great, but some of it just gets in the way. So it's worth using, but using when it's appropriate and not just stopping out for you.

Marek: 40:15 Interesting. So it really kind of going back to the beginning here, it really boils down to what does the customer need and does this illustration or does this image support that need or make that message more clear to the customer?

Matt: 40:29 Mm-hmm (affirmative)- Exactly. And that is like design in a nutshell. That everything comes back to what the customer need is and how we can satisfy that appropriately.

Marek: 40:39 Cool. And how about links? I know that's always kind of a confusing topic for some of our customers. Derek, do you want to speak about using links and emails? The links themselves, these are often pretty critical junctures in a customer journey. Can you talk about maybe secure, not secure, what are designers need to be aware of when using links in email?

Derek: 41:04 Yeah, so in terms of secure versus non-secure, I think it's always important that you know where your link is going to and that it's something that's going to essentially live almost forever because a lot of times emails end up sitting in the inbox for quite some time and people might end up opening it, it can be months down the line sometimes, and clicking on something. You need to make sure that that link is almost going to be, is essentially permanent, and that it's going to have a permanent home there. So, obviously secure is better, but sometimes you don't really have the choice. I don't know. Do you have any advice Matt?

Matt: 41:43 I guess for plain text emails, it's probably a little bit more appropriate. And email is widely abused anyway, because whether it's phishing scams or whatever, it's really easy to make an email look like it's coming from a legitimate source and it not be, and people get caught out going to like dodgy log forms or whatever. I think with plain text email, it gets harder to do that because you can see the URL. So like if you're it linking somewhere, if you put your URL into plain text email, people are going to see the domain on that. So that's important to try and present that domain.

Matt: 42:15 Now it gets more complicated if you're using something like link tracking on the email because then it's going to replace that link with something... with like a shortened URL easily. Usually that's not going to be as recognizable to customers, so that's always a consideration there. And in Postmark for example, we allow you to enable or disable link tracking based on whether it's a html email or plain text. So if you want to send the link in a plain text version, then you can do and then use the link track to link in the html version where it's not as visible to customers, but for sure, like I always think, the customer needs to be confident that when they click on that link, it's going to take them to where they need to go in a legitimate place.

Derek: 42:56 Yeah. One of the things we also do with our open source starter templates is, with the starter templates that have a call to action, so for like account activations, we usually have the button. But it's also... one of the best practices also include just include the raw URL somewhere below that just in case for whatever reason, for accessibility or if they're using a crappy email client, that button doesn't load or the link doesn't work, there's a raw URL at the bottom of the URL with the call to action so that they can easily click on that. So that's one of the things that we do with our starter templates.

Matt: 43:37 Another thing to look out for in plain text emails, it's a lot of people will rely, a lot of email service providers will automatically generate a plain text version from your html version, which is less work for the developer. It's just great, but the problem is that if your pastry mail version's got a bunch of like fancy header with links off to your homepage or wherever and when that thing gets translated to a plain text version, you're going to have all of these links at the top of that plain text version. It don't really make an awful lot of sense to the customer, so it's really important that you actually do the extra work and create that plain text version yourself because then you have full control over the content and you can make sure that none of that stuff adds in there.

Matt: 44:17 So the only links that are in that email, the only URLs in the actual copy of that email are for the key actions that you want. So you... ideally you'd have, you just started with normal content like plain text and then you'd have your... one of your cool traction is in the URL to that and then maybe you have the URL to your homepage further down at the bottom. You're not cluttering that email with a whole bunch of stuff because it's been ultimately converted from your pastry mail version.

Marek: 44:44 So let's just touch on that. I mean, html, plain text email, we're talking a lot about how that relates to links and being mindful of how those links are going to be rendered. Why are plain text emails such an important component when you're sending transactionally?

Derek: 45:01 Yeah, so it's pretty common for spam filters to lag your email if it doesn't have a text version. So ultimately having both an html and text version should improve your deliverability. And I think the thinking behind it, is that a spammer is generally pretty lazy and they're not going to take the time to create a plain text version of their email, and so they by default a lot of them and it's lagging in. So in a lot of cases it's better to just send a plain text only email as opposed to html only. But the best practice is to send what they call a multi-part email, which is both html and plain.

Derek: 45:42 Another thing too is that sometimes, some people simply prefer seeing the plain text email over html. A lot of accessibility comes into play there, so some people configure their email clients to only see the text version maybe because they might have visual impairment issues or it's easier for their screen reader. So accessibility is definitely something to consider there.

Marek: 46:09 I wonder if the Apple Watch relies on the plain text version as well. So you can read your emails on your Apple Watch. I wonder if they're doing something like we're talking, conversion of the html or if it's just pulling the plain text version now?

Derek: 46:22 Yeah, that's a good point [inaudible 00:46:23].

Marek: 46:23 Rather like everybody's reading their emails on their Apple Watch, like on a tiny inch square screen, but like they [crosstalk 00:46:29].

Matt: 46:29 But I really want to focus... you really want to focus on keeping it short.

Derek: 46:33 Yeah, for sure.

Marek: 46:36 So maybe we can just touch on quickly the concept of email headers and footers. Are there any important design considerations there?

Matt: 46:44 So it's... similarly if you're designing a webpage in that, it needs to convey your brand. So if you're creating like a transactional email template for example, and yet you worrying about your header's input is like, you don't want to overstock them, just like you wouldn't overstock your header on a webpage. You're probably going to want to put your logo there. You're going to want to use your brand colors, but you don't want to go to over the top with it, footers are already great place to put the light.

Matt: 47:13 So I think in our newsletters, we have a section in the footer which we can update every time and just like out a little message or something fun, and a lot of customers will just... they won't even see it. They won't notice it. But it's a good place because you're not disrupting the flow of email. You're not disrupting the customer getting to the key action, but if they know what to say, I might give them a smile. So I was like to try and add a little bit of delight in the flip side.

Marek: 47:39 All right. Well, so let's... so we've talked about a lot of the components of the email. I would like to talk about, once you have a really good working prototype, what does the process look like to get buy in from the rest of the team? It sounds like Abstract maybe is a good tool for this. Are there other mechanisms or tools that you guys rely on to get that buy in?

Matt: 48:00 Sure. So, it really depends what tools your team is using any way for getting design feedback, but it could be something as simple as like forwarding that email around to a bunch of people and getting that feedback on it so they can see it in their email client and pick up the phone and see it, read on their phone as well and get the real experience of it, or maybe just taking screenshots and sharing it in something like Abstract or on like a Dropbox Paper doc or whatever really mechanism you use to get feedback. It doesn't really matter that much. It also depends on what level of feedback you wanting because if you're looking for feedback on like content, actually sending the final emails, probably not the best thing to do.

Matt: 48:42 If you want someone to focus on giving content feedback, send them a document with just the content in, because then they're not distracted about all the extras, all the visuals. If you just want to know whether the copy is good or not, don't send them everything out. Whereas if you want feedback on the visual design of it, use the tool or Abstract or something where they can literally point to like this pixel and add a comment and say like, "Hey, this thing should be like blue, not red." It just depends on what level of feedback you're looking and as to what approach you want to use that.

Marek: 49:17 All right, so you get buy in from the team, everybody's good to go. The templates look great. Let's talk about launch or moving them into production. I know I've put together marketing campaigns in years past and when that moment comes to click the send button, it's always a bit of a panic. I always found myself asking, "Did I do everything right?" When making changes to transactional email and then moving them into production, what are some of the steps that we go through to ensure that things are locked tight?

Derek: 49:48 So I would say run it through Litmus. You can't go wrong with Litmus. They have a checklist feature that will do a bunch of checks to your email, and so what they can warn you about is, are things like broken links, whether it's subject line or content sound spamming, whether you're going to... you have a high possibility of being flagged by spam filters. Just a bunch of other tools that will help you increase engagement and catch simple mistakes. But I can't stress how valuable that tool is when it comes to sending emails as spam.

Marek: 50:26 Anything else?

Matt: 50:27 Well, we are really lucky because we have Igor, who's our QA guy on Postmark, who's just a absolute wizard with this stuff. So whether it's an email change or like a change to the application or whatever it is, everything goes through Igor before it's released. And he will... if there's a problem he will find it. It's very rare anything gets past him. So I heard some old teams have that luxury, but it's super useful for us to have by a real human tester that makes sure that everything's working.

Derek: 50:59 Yeah. It's also, aside from just the email content itself, when you're looking at transactional email, it's important to also test how the email gets triggered and to trigger that scenario to within your web app because there's often been times where I've curated it incorrectly or whatever and it doesn't fire off like I thought it would, even though the email content looked great when I was previewing it, but application actually wasn't sending it. So it's important to actually test beyond actual design of the email.

Marek: 51:29 Cool. So, we published these templates. Matt, I believe it was close to like a month ago. How do we go about monitoring and measuring the efficacy of these design changes? Are there specific metrics or things that we keep tabs on?

Matt: 51:48 Sure. So it depends on what's the changes, but in these templates, for example, some of them we changed their call to actions a little bit. So there's a couple of templates where we were giving the customer a few different options and weren't really adding the preferred option and in the design, and all the things like that. You can use tools like link tracking and measuring engagement like, "Hey, your customer's actually doing the action that this email is being sent to them for."

Matt: 52:18 You can measure open rates and things as well. It depends on what motivated you to change that email. So because we've changed so many in this update, each one has its own different goal behind [inaudible 00:52:32] and trigger behind why we actually touched it and why we wanted to update it. But yes, like monitoring call to actions is great. Monitoring open rates is great. Also monitoring like spam notifications, so like have you changed some content and now is a bunch of those emails going to spam? That's something you need to keep an eye on. Yeah. And so it's kind of all the book. Could you agree, Derek? Is there anything you can answer?

Derek: 53:02 Yeah, yeah. To add to that, I think it just really depends on the goals of the organization and the particular email. And so I think a good example is, recently we released some improvements to our password reset emails to clear up some confusion with our customers. Our key metric was to see if this had a significant reduction in customer support requests, and so far it seemed to work. So that confusion was resulting in higher customer load because people were confused about certain things. But, yeah, just to add onto what Matt said, with transactional, generally it's important to keep tabs on your open rates. Since recipients often expect these emails, you should have pretty decent open rates. So if you have a low rates, then people aren't reading triggered emails and maybe something's wrong and... yeah. If you were call to action in your email and you can use tools like click tracking to see whether people are interacting with it.

Marek: 53:59 All right. Guys, I feel like we've touched on a lot of really awesome topics today. I want to just end with some takeaways. Derek, are there some key takeaways that you'd like to leave us with?

Derek: 54:16 Yeah. So I think the key takeaway is when you start on designing a particular email, then you need to start with the content first. So that means just opening up your text editor and figuring out what you're trying to say. Emails are words and you just need to know what you're communicating to users before you figure out how it's supposed to look and, yeah. Another one of those things is using Litmus to test your emails and email clients and just ensuring that you're not making silly mistakes.

Marek: 54:49 Matt, anything to add?

Matt: 54:52 Yeah. Always keep your focus on what you want the customer to do with the email as well. Don't let yourself get carried away with doing what's trending with new animations or something like that, and take your eye off why are you sending this email in the first place and what do you want the customer to do with it?

Marek: 55:10 All right. Well, I think we're going to wrap up this episode. Matt and Derek, thank you both so much for being with us today. It was wonderful to have you guys.

Matt: 55:20 Thanks Marek. [inaudible 00:55:21] .

Marek: 55:23 And to our listeners, thank you for joining us today for this episode of Talking Email with Postmark. If you enjoyed the episode, please leave us a review on iTunes and subscribe to receive updates on all future episodes. And be sure to check out the resources section for this episode where you'll find useful tools and helpful articles on transactional email design. Lastly, if you're ever looking for design advice on your transactional email templates, be sure to reach out to us at support@postmarkapp.com and we'd be more than happy to help. See you soon.