Design tokens
The atomic units. Colour, typography, spacing, radius, and button styles, defined once as variables and referenced everywhere. Updating a token updates every email.
A guide
An email design system is the spec. The CMS is the enforcement.
Tokens, modules, and governance rules that make on-brand email production fast, consistent, and resistant to drift. Here's what they include, how to build one, and what changes when you do.
Definition
What an email design system actually is
An email design system is the framework that decides how your emails look and how your team produces them. It's three things bundled together: tokens (the atomic colour, type, and spacing values), modules (the reusable layout blocks), and governance (the rules about what can change and who can change it).
Brand guidelines are suggestions. A design system is enforcement. A PDF says the brand blue is #1A365D;
a design system makes #1A365D the only blue your editor will ever output, because every button, link,
and accent references the same token.
That sounds technical, but for a marketer the experience is simpler: the editor only offers brand-approved options. Click a button colour and you pick from the three approved variants. Pick a heading and you pick from the type scale. There's no eyedrop tool. There's no "make it bigger." The system answers most of those questions before they come up.
The design system is the spec. An email CMS is the tool that implements and enforces it in the editor. The modules inside a design system are modular email templates: reusable, tested HTML blocks that snap together to build any campaign. If you're starting from Figma designs, our Figma to HTML email service converts them into production-ready modules.
The pieces
Four things you need; not just colours and fonts
A working email design system is more than a token sheet. These are the components that make it operational.
Module library
The reusable blocks. Hero, centred text, product grid, CTA, promo, social row, footer. Each module is tested across email clients once and reused forever.
Governance rules
What can change, who can change it, and how new modules get approved. Rules turn the system from suggestion into enforcement.
Documentation
A single page that explains the tokens, the modules, the rules. Adoption depends on it. Don't ship a 40-page PDF nobody reads.
How to build one
Five stages from zero to a system your team will actually use
Most teams underestimate the audit and overestimate the module count. Start small, document early, expand as needs come up.
- 01
Audit your last six months
Pull every campaign you sent. Group by layout. Note where the brand has drifted. The recurring patterns become your starter modules; the drift becomes your token list.
- 02
Define the tokens
Colour, type scale, spacing scale, button styles, link styles. If you don't have brand guidelines, derive them from your site. See our guide for a starter token sheet.
- 03
Build the module library
Eight to twelve modules covers ~80% of campaigns. Header, footer, hero, centred text, image-and-text, two-up image, product grid, CTA, promo, social row. Test each one across email clients once.
- 01
Set governance rules
Decide what marketers can edit (content fields, variants from approved lists) and what they can't (structure, tokens). Decide who approves new modules.
- 02
Ship and document
Roll out to your team. One short page documenting the modules, tokens, and rules. Iterate as new module needs come up. Don't try to design everything on day one.
The point of a design system is not that everyone follows the rules. It's that the rules are followed by default.
Drift signals
What 'no design system' actually looks like
If any of these sound familiar, the gap is bigger than a brand guideline can fix.
Five button colours across the same month
When marketers eyedrop a hex from a Google Doc, you get five 'brand blues.' Tokens make this impossible.
A campaign that breaks in Outlook
An untested module sneaks in. The pre-header collapses. Engagement tanks. A library of validated modules removes this whole class of failure.
Three slightly different footers in production
Each one was 'just a tiny tweak.' Together they look amateur. A shared footer module fixes this in one place.
QA round on every send
If every campaign needs a full Litmus pass, the system isn't doing its job. Pre-validated modules let QA shrink to spot-checks.
Approaches
Different ways teams try to enforce email consistency
Most rely on guidelines or repos. The CMS-with-tokens approach is the only one that puts the rules in the editor itself.
Approach
Pros
Cons
Approach PDF brand guidelines
Pros
- Familiar format
- Easy to share
Cons
- Suggestion, not enforcement
- Goes out of date
- Drift happens anyway
Approach ESP template library
Pros
- Built into your platform
- Ready-made starter set
Cons
- Locked to one ESP
- Limited token control
- Hard to enforce rules
Approach Internal style guide repo
Pros
- Lives where developers live
- Version controlled
Cons
- Marketers can't access easily
- No editor enforcement
- Drift between repo and live emails
Approach An email CMS with tokens and modules Recommended
Pros
- Tokens and modules enforced in the editor
- Marketers self-serve from approved blocks
- ESP-agnostic export
Cons
- Initial template setup required
Worth reading
Common pitfalls when building one
Designing too many modules upfront
Teams often try to design every possible layout on day one and end up with 40 modules that overlap, contradict, and take months to QA. Start with the eight to twelve patterns you actually use this quarter. Add more as the campaigns ask for them.
Treating tokens as suggestions
A token sheet is only a design system if the editor enforces it. If marketers can still type in a hex code, type in a font size, type in a spacing value, the tokens will drift. The whole point is to remove the temptation.
No documentation, or too much documentation
A 40-page brand bible is unread. A one-page reference with the tokens, the module names, and the rules is gold. Adoption depends on the team being able to skim it on a Monday morning.
Building it in isolation
Designers, developers, and marketers all need to feel ownership. Build the system with whoever is going to use it, not for them. The audit phase is a great place to involve everyone.
FAQ
Email design systems, in detail
-
What is an email design system?
An email design system is the framework that defines how your emails look and how teams produce them: design tokens, module library, and governance rules. Tokens are the atomic units (colour, type, spacing). Modules are the reusable blocks. Governance defines what's editable and who approves new pieces. -
What's the difference between an email design system and a brand guideline?
Guidelines are suggestions. A design system is enforcement. A PDF tells you the primary blue should be #1A365D; a design system makes #1A365D the only option, applied via a token, every time anyone touches an email. -
What's the difference between an email design system and an email CMS?
A design system is the spec. An email CMS is the tool that implements and enforces it. The design system says "use these tokens, use these modules, allow these variants." The CMS surfaces those rules in the editor and refuses to let anyone break them. -
How many modules should a starter system include?
Eight to twelve. A solid starter set covers header, footer, hero, centred text, image-and-text, two-up image, product card (single and grid), CTA, promo banner, social row. That covers ~80% of campaigns. Add more as needs come up; resist designing 40 modules upfront. -
Do I need formal brand guidelines first?
No. If you don't have them, derive them from your site. Pull the colours, type, and spacing you actually use, then adapt for email constraints (web font support, narrower viewports, contrast requirements on small screens). A one-page reference is better than a 40-page document nobody reads. -
How do I prevent design drift?
Two things make drift inevitable: marketers needing flexibility you didn't anticipate (so they improvise) and tokens that are 'guidelines' rather than enforced. Fix both by defining all the variants you'll allow upfront (button colours, layout options, image alignments) and by enforcing tokens through the editor instead of through PDFs. -
Do I need a developer?
For initial setup, yes. Template configuration is handled by us, your agency, or your developer: defining tokens, marking up editable regions, exposing variants. After that, the marketing team works through the editor without writing code. We offer setup as a service if you want us to handle it. -
Can I use the system across multiple ESPs?
Yes. With Modular Mail you build campaigns in our editor, then export clean HTML to any ESP: Mailchimp, Klaviyo, HubSpot, Salesforce Marketing Cloud, Marketo, anything that accepts HTML. Your design system investment isn't tied to a single platform.