Before drawing a template in Figma, it's important to understand that half of the visual solutions in it will die when opened in a specific client. Each service interprets HTML and CSS emails differently, and this is not a minor technical detail — it's what determines whether the brand will remain recognizable on the recipient's screen.
| Client | Feature | What to do in design |
|---|---|---|
| Gmail (dark mode) | Automatically inverts dark text on a light background | Prepare the logo in two versions — dark and light — and check contrast after inversion |
| Apple Mail | Applies its own color adaptation algorithms | Use the prefers-color-scheme media query and manually test both versions |
| Outlook | Uses a Word engine for layout, does not understand border-radius or media queries, inline colors work unpredictably | Build in 'square' backup button variants and do not rely on rounded corners and gradients for identity |
| Yandex.Pochta | Shows only the desktop version, automatically links phones and addresses in yellow, changes letter spacing | Do not tie brand perception to exact text tracking, check how the email looks without mobile adaptation |
The practical conclusion is simple: email identity cannot be built on subtle typography details or complex CSS effects — they will not survive half of the clients physically. The support are things that work identically everywhere: color, block composition, large typography and iconography.
A brandbook describes the brand as a whole: logo, color palette, fonts, and overall tone of voice. An email guideline is an operational document for those who design emails weekly, and its purpose is not to repeat the brandbook, but to translate its rules into specific blocks and instructions.
It is better to store such a style guide not in PDF, but as a living document — in Figma with a component library that the team updates as new email types appear. PDF becomes outdated after the first button redesign.
The site and app live in an interactive environment: hover effects, animation, and adaptive typography work at any resolution. Email is an HTML document with reduced CSS that opens in dozens of unpredictable environments at once. Trying to transfer the brand gradient from the site there is a sure way to get a scattered layout in Outlook.
The working approach is to extract a stable core from the main identity: 3-4 colors, one or two fonts with wide support (or system fallbacks), and brand iconography in the form of static SVG/PNG. Everything that depends on dynamics or complex CSS is not taken into the email language at all. This is not brand simplification, but its translation into the language of another channel — just as the brand sounds different in outdoor advertising and in the app interface, remaining recognizable.
While the mailing is two letters per month, the designer can draw each from scratch. With growth to dozens or hundreds of letters, this becomes an operational problem: without a modular system, each letter takes hours to layout and introduces random visual discrepancies.
The solution is a master template built from ready-made blocks: hero, product grid, testimonial, counter, footer with a legal block. In the bank case, the modular approach accelerated letter production by 54%, in the pet store case — 1,5-2 times, with a library of 40-193 typical block variants. Not only is designer time saved — the risk is reduced that someone on the team will assemble a letter 'by eye' and deviate from the brand's visual language.
A full system of templates and a separate email guideline are justified for companies with a established brand, wide audience, and a frequency of more than 10 emails per month — only there does the volume override the economics of investment. For businesses sending rare emails, brand elements in the header and footer are sufficient: logo, brand color of the button, recognizable header font. Building a full email design system once a month is a waste of resources not well directed.
Before drawing a template in Figma, it's important to understand that half of the visual solutions in it will die when opened in a specific client. Each service interprets HTML and CSS emails differently, and this is not a minor technical detail — it's what determines whether the brand will remain recognizable on the recipient's screen.
| Client | Feature | What to do in design |
|---|---|---|
| Gmail (dark mode) | Automatically inverts dark text on a light background | Prepare the logo in two versions — dark and light — and check contrast after inversion |
| Apple Mail | Applies its own color adaptation algorithms | Use the prefers-color-scheme media query and manually test both versions |
| Outlook | Uses a Word engine for layout, does not understand border-radius or media queries, inline colors work unpredictably | Build in 'square' backup button variants and do not rely on rounded corners and gradients for identity |
| Yandex.Pochta | Shows only the desktop version, automatically links phones and addresses in yellow, changes letter spacing | Do not tie brand perception to exact text tracking, check how the email looks without mobile adaptation |
The practical conclusion is simple: email identity cannot be built on subtle typography details or complex CSS effects — they will not survive half of the clients physically. The support are things that work identically everywhere: color, block composition, large typography and iconography.
A brandbook describes the brand as a whole: logo, color palette, fonts, and overall tone of voice. An email guideline is an operational document for those who design emails weekly, and its purpose is not to repeat the brandbook, but to translate its rules into specific blocks and instructions.
It is better to store such a style guide not in PDF, but as a living document — in Figma with a component library that the team updates as new email types appear. PDF becomes outdated after the first button redesign.
The site and app live in an interactive environment: hover effects, animation, and adaptive typography work at any resolution. Email is an HTML document with reduced CSS that opens in dozens of unpredictable environments at once. Trying to transfer the brand gradient from the site there is a sure way to get a scattered layout in Outlook.
The working approach is to extract a stable core from the main identity: 3-4 colors, one or two fonts with wide support (or system fallbacks), and brand iconography in the form of static SVG/PNG. Everything that depends on dynamics or complex CSS is not taken into the email language at all. This is not brand simplification, but its translation into the language of another channel — just as the brand sounds different in outdoor advertising and in the app interface, remaining recognizable.
While the mailing is two letters per month, the designer can draw each from scratch. With growth to dozens or hundreds of letters, this becomes an operational problem: without a modular system, each letter takes hours to layout and introduces random visual discrepancies.
The solution is a master template built from ready-made blocks: hero, product grid, testimonial, counter, footer with a legal block. In the bank case, the modular approach accelerated letter production by 54%, in the pet store case — 1,5-2 times, with a library of 40-193 typical block variants. Not only is designer time saved — the risk is reduced that someone on the team will assemble a letter 'by eye' and deviate from the brand's visual language.
A full system of templates and a separate email guideline are justified for companies with a established brand, wide audience, and a frequency of more than 10 emails per month — only there does the volume override the economics of investment. For businesses sending rare emails, brand elements in the header and footer are sufficient: logo, brand color of the button, recognizable header font. Building a full email design system once a month is a waste of resources not well directed.