Whether you work with a remote email team or not, email design systems can help you. From scaling your programs and ensuring consistency, to saving time when designing and coding emails, a strong design system has your back. But how do you get started with creating and maintaining one?
In this round table discussion, experts from Stack Overflow, Zillow, and Litmus talked through the benefits and challenges of using email design systems.
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.
A big 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 our take on some of the questions we didn’t get to during the live webinar. Have any additional questions? Please leave them in the comments.
What are the key modules/components of an email design system that can get a team started?
Ted Goas: This varies from team to team. We started with an audit and inviting folks to brainstorm in a Google Doc. There are probably a few safe things that every email needs (buttons, typography, etc.), but it was only after the audit and brainstorm sessions that we knew what we should start with. This starting point varies from team to team. I wrote about this in my email design systems article in the section “Lesson 3: Start small, involve others early.”
Jaina Mistry: Agree with Ted, and we started the same way at Litmus—with an audit of our current emails to see what modules and components we often repeat. For us, that turned out to be CTA buttons, paragraphs, lists (ordered and unordered), hero imagery, links, and typography.
Crystal Ledesma: Starting is as simple as auditing your emails as the rest of the group mentioned. If you send a lot of email and auditing them all is too big of a task, identify and audit the emails that have commonly used design patterns and/or are high performers. I like to get things in my hands and print (sorry trees!) the audited emails, take a pen and draw over them to help us identify which design patterns we see again and again. Those become our “building blocks” or modules for the system. That’s how we got started with our email design system at Zillow. Though we wanted to get down into smaller components like buttons and how to make them consistent across every email, we were still trying to still get things out the door and initially I was a team of one, so we kept it simple.
Once you have buy-in from cross-functional partners on actually building out an email design system, what would you recommend as first steps in getting it off the ground?
Jaina: Set yourself some realistic goals to aim for. Look at the calendar and map out what you want to achieve by certain dates. Email marketers are busy folks, so you’ll probably be balancing working on the design system as well as your day-to-day work. And you’ll have times when you have no time to dedicate to working on your design system. If you’ve set out to have it complete in a matter of weeks, each day you don’t get to work on it will feel pretty negative. Instead, carve up what you want to achieve in chunks and tackle those bit by bit.
Crystal: Identify who the people are that will be using the design system, and start to think about the email design system as an internal product, not a project.The people you identified are your users. You want to get user feedback early, and the bonus is getting them involved early helps to foster trust in the system. Aside from that, echoing the others’ advice. The beauty of design systems is that they can—and will—evolve and scale with time. Keeping it small is the best way to get things going.
What would a design system look like for a marketing agency with many different brands?
Crystal: The tough part about working with many different brands is that there are likely many different needs visually, along with different subscriber email inboxes and even subscriber behaviors. Zillow has our better known B2C brands, but we also have several B2B brands. This means we are working with an extremely wide and diverse group of subscribers, content, needs, and inboxes. We are working toward having one email design system for all of the brands, but we know there are going to be unique needs for each brand, too. We will have a “core” email design system, with branches of the system that are unique to each brand’s specific needs. I imagine that structure could be helpful in an agency environment as well.
If your team does not have a dedicated design system coordinator, do you think the responsibility for keeping brands on point and design consistencies within the templates falls more on email developers or designers?
Jaina: I’d say developers AND designers. Developers can speak to what can technically be achieved, meanwhile, designers can help address issues like accessibility. Neither role can take on that responsibility on their own—they have to work together.
Crystal: Before I was managing our design system and working on just one brand, it was definitely a group effort. Both designer and the developer worked together to ensure things stayed on brand and consistent. Even now that I’m managing, Zillow is a big company, so it will continue to be a group effort. Things like onboarding users to the design system and documentation helps educate them on how to keep things consistent and on-brand, so they can be empowered to do it themselves. My team functions more as the go-to experts in cases when our partner teams may be uncertain. Even if your company doesn’t have a team like ours, it’s possible to do this with interested volunteers similar to what Ted described at Stack Overflow.
How often new components are added to the system and do you A/B test before making it part of the system?
Crystal: So far we add new components and modules on an as-needed basis. Usually this happens when there is content or goals for the content that doesn’t quite fit in what exists in the system today. If it arises more than a few times and if there is a strong business case for it, we determine that it should become an official part of the system and we create it. Because our modules and components are based on previous designs, we did not A/B each one before making them a part of the system. However, having our designs converted to a system format meant we could A/B test portions of our emails easily, our teams have been able to shelve modules that underperform and highlight ones that perform better with our audiences. In the near future as we continue to evolve our system and explore new designs, A/B testing is going to be a required step before any component becomes part of the system.
How do you maintain the quality of the emails if they’re being created by people who are not email specialists?
Ted: It’s an everyday struggle! An email design system doesn’t guarantee a low-quality email won’t ever be sent. Evangelization and teaching helps, but it’s impossible to be everywhere at once and you don’t want to be a blocker. I try to maximize my impact by focusing on large-volume sends, recurring emails, and emails that are sent at a pivot point in a customer’s experience.
Crystal: What Ted said! Especially if the design system is brand new, it’s going to take time. Time to create it, establish it, onboard everyone, and so on. With time and ongoing support, the quality will improve. Depending on the tools you have, you may be able to leverage those tools to add some fine-tuned control to keep quality intact as well.
How does something like interactivity in email come into play for design systems?
Ted: I experimented with interactive email in December. The exploration worked, but it didn’t solve the UX problem at hand so it was shelved. However if we had proceeded with it, I would have treated the interactive component like every other component: Once it’s used three or more times, it should be codified and documented in the design system. Until then, the component is treated as ad-hoc design.
Crystal: We haven’t been able to explore interactivity in email and design systems quite yet, but our approach would be the same as Ted’s and it’s already similar to adding any component, interactive or not. Initially, it would be considered an ad hoc item, and saved in our back pocket should we need it again. If we start to use that interactive component more than a handful of times and it proves to be impactful, it will be added to the system with guidelines for use.
We have attempted to implement a design system, but it is difficult to get our branding team to use one properly. We then have to create brand new email designs every time. How do you combat this?
Jaina: What challenges do the branding team face that stops them from using the design system? Ask them for their feedback and understand how you can help address that. If the branding team feel like they’re being heard, it may well help you to get buy-in from them with the design system.
Crystal: This type of difficulty is usually rooted in a misunderstanding of the system or a need for the team that we were unaware of. Get to know the team needs, goals, and friction areas, whether or not those things apply to the system directly. Connect those findings with the system, and you may be better able to diagnose what is missing in the system itself that is blocking the team from using the system properly, or which areas of onboarding and support that the team still needs to use the system successfully.
The feedback we’ve received as email designers is that the design system makes emails look and feel boring. How can you keep emails exciting but still consistent with the design systems?
Ted: We’ve had this problem in reverse: Folks would follow our routine starter templates to a fault. I saw a few first drafts for major, once-a-year announcements that were mostly black text on a white background. In response, we created a section in our design system that shows folks that it’s ok to design something unique and how we’ve done that in the past.
Jaina: With a design system in place, there’s often more to be creative with! With a structure in place, designers don’t have to think about how the content needs to be structured but can spend more time on the imagery or illustrations used in an email and how those assets complement and enhance the email copy. That’s where I see a lot of typically “boxy” emails win big—structure supported by fantastic copy and design.
Crystal: To help get designers out of feeling constrained by the system, sharing inspiration from other companies and describing how those designs can be broken down into components has helped. Even better if the designer shares the emails that inspire them that you can walk them through! If time permits, I would also suggest having the designer to design an email however they want without considering the design system. Have them reconvene with you and you can highlight what tweaks can be made to ultimately have that design fit the system. You can also use this as an opportunity to highlight that the design system will help get simpler emails done faster. That the saved time will give designers opportunities to propose new designs to test that may become a part of the system down the road, and more availability to propose and create unique email designs for campaigns that require more than what the system currently provides.
What happens when you need to revise your design system—and what do you push back on when a request to make an update comes in?
Jaina: We haven’t had this, yet, at Litmus, but I’d ask “why?” to understand if the effort required is going to be worth it.
Crystal: We are moving forward with revising our system now so it can scale to support all of our brands. That is an extreme example of a crucial business case for a revision, but it’s a good standard to keep in mind when considering whether or not to make revisions at all. When the system was smaller and supporting only one brand, reasons for revisions included a rebrand and updating the code for improved accessibility, both obviously strong business cases. If the request to update contributes to a larger business goal or need, that’s a clear sign to move forward with them. If it’s not clear, ask questions. What is the use case for the revision? How do the revisions affect everything else in the system? Is this revision hyper-specific to the requestors use case, and will a revision for that use case cause a disruptive ripple effect to other users? Does the team or person that works on updates to the system have time to make the revisions? Is it needed immediately, or can it wait? In other words, as Jaina said, is the effort required going to be worth it?
Ted: To build on what Jaina said, I’d ask why and when. I’d love to understand how a component would be used and when it’d be used. The best candidates for design system components are things that will be reused often, so understanding how often something will be used is important.