Building emails with email modules is a great way to make your production process more efficient. We spent some time in our latest webinar to talk about this hot topic with Brandon Lawson and Ryan Wallace from Ferguson Enterprises as well as Lauren Kremer and Scott Epple from the Litmus team. We walked through what modular email building is, how Ferguson Enterprises does it, and how Litmus can help you get started.
Didn’t have a chance to watch the webinar live? Don’t worry. You can access the full recording at any time and read the Q&A below.
Thank you to everyone who chimed in during the webinar with a question! Here’s a recap of our answers to the most popular questions, along with the Ferguson Enterprises and Litmus team’s take on some of the questions they didn’t get to during the live webinar.
How do you maintain a consistent voice, style, and flow across different elements? Or does it always require a final close edit and tweaking for style?
Litmus: Voice and tone guidelines are a great addition to an email design system, but should probably be agreed upon across marketing channels. Using placeholder copy in your templates and modules that exemplifies your brand’s voice and tone (or gives explicit guidance) is another great way to guide users.
When building out partials, I would prefer to place CSS pertinent to the partial in the partial itself. However, I recently read somewhere that the CSS would be better off in the main template. Thoughts?
Ferguson Enterprises: I think everyone’s journey is different, but we recently decided to add our CSS as partials. We did this because we see ourselves having a wide range of templates in the near future, and when thinking of ways to streamline making any updates to the main CSS, partial-izing our CSS made the most sense.
I’m curious how you all present your modules/templates to internal clients who don’t have access to your email system (and therefore, design library). Do you present all the modules separately as options, or give them complete templates that are using available modules (and they don’t necessarily know that they’re “modules”)?
Ferguson Enterprises: We do this in a number of ways.
For our campaigns that are in support of local initiatives, we give those stakeholders an “Email Marketing Menu,” which is a collection of pre-made email templates that already fit their messaging needs and are plug-and-play friendly. Our national campaigns are custom built by our creative team, but we include our stakeholders in the proofing and QA more in those types of emails.
Can you talk a little about the process of using the code with an ESP that isn’t on Litmus’ sync-compatibility list?
Litmus: Use the ‘Export’ menu in Builder to copy the compiled HTML to your clipboard or download as an HTML file and then paste or upload to your ESP. Check out this help doc for more details.
I’d also love to hear more about Ferguson’s process for approaching Dark Mode that adheres to brand standards!
Ferguson Enterprises: This was a collaboration with our creative team. We worked with them to establish best practices for situations where Dark Mode email control was not supported. We also worked with the creative team to establish a color palette for things like title text, body text, CTAs, etc. that adhered to brand guidelines when we could control Dark Mode preference stylings.
Do you add style parts to the modules, or do you inline the styles at a later point when the whole email is ready? Do you create fixed-size modules?
Litmus: Adding inline styles to modules can certainly work, but it means that if certain styles ever change (say, font styles), you then have to update every module where those styles are inlined.
Instead, if you include your styles in your boilerplate template—or, even better, extract your styles into partials and include those in your template—then you can make changes to styles in one place.
With Builder’s ‘Inline CSS’ option, you can make sure that your styles are inlined automatically before syncing to your ESP or exporting your code.
How does the Design Library work with other ESPs? For example, how do you build emails within Salesforce Marketing Cloud using the Litmus library?
Litmus: Templates from your Design Library can be synced to your ESP for use.
Modules work best and most seamlessly within Litmus Builder, but you can still reference your modules in Design Library and copy the code for them to your building tool of choice by just selecting a module and clicking on the code preview in the right sidebar to copy the module code to your clipboard.
How do you make a module?
Litmus: We’ve got a great help document that walks you through the process of creating modules within Litmus step by step. If you’re talking very broadly about how to get started with modular emails, though, this blog post is a great guide.
When should you use one modular block vs. another? Are there rules for usage?
Litmus: Assuming this question refers to the difference between partials and snippets…
Partials are global modules that are referenced from your emails or templates. Making changes to a partial affects every email/template where that partial is included. Partials are great for commonly used elements that don’t change from one email to the next: headers, footers, CSS reset and base styles, responsive breakpoints and styles, spacer elements, etc.
Snippets are reusable modules that can be inserted into an email or template and edited within that email/template without affecting other emails/templates. Snippets are perfect for the majority of your “body” content: hero blocks, primary/secondary/tertiary content blocks, CTAs, etc.
How should you organize blocks?
Litmus: Check out our blog post on 7 ways to organize your email modules into useful categories (by email type is a common favorite!).
How do you keep people on the same page for consistency?
Litmus: That’s the beauty of a design system: It’s always up-to-date and drives consistency by ensuring that users are always building with the latest-and-greatest templates and modules.
Keeping your design standards and brand guidelines documented and accessible within or alongside your design system is another great way to communicate.
Some organizations will also keep a “change log” or “release notes” that they share with stakeholders.
Think of your design system like a product and communicate how-tos, benefits, and major changes so that users can stay informed and make the most of the system
And that’s a wrap on the questions we were able to get to. For more reading on modules, templates, and design systems, check out this related content: