Дизайн электронных писем в 2026 году — странная дисциплина. Вы разрабатываете для среды, которая отображается по-разному в десятках почтовых клиентов, на экранах от смарт-часов до ультраширокоэкранных мониторов, как в светлом, так и в тёмном режиме, с техническими ограничениями, которые довели бы веб-разработчика до слёз. И тем не менее, письма с наилучшими показателями зачастую самые простые.
В этой главе рассматриваются технические основы, которые обеспечивают правильное отображение, быструю загрузку и надёжную конверсию ваших писем.
Мобильный дизайн прежде всего
Более 60% писем теперь открывают на мобильных устройствах. Этот показатель неуклонно растёт уже несколько лет и не собирается снижаться. Что ещё важнее: 64% мобильных пользователей удаляют письмо, которое плохо отображается на их телефоне. Не "выглядит не идеально", а именно "не работает".
Mobile-first означает разработку сначала для самого маленького экрана, а затем масштабирование вверх.
Одноколоночные макеты — самый безопасный и эффективный подход. Многоколоночные дизайны, хорошо выглядящие на десктопе, непредсказуемо разрушаются на мобильных устройствах, часто выстраиваясь в неправильном порядке или создавая кошмар горизонтальной прокрутки. Один столбец с правильно подобранными размерами текста, изображений и кнопок работает везде.
Удерживайте ширину письма в пределах 600–640 пикселей. Это стандарт, который работает в наиболее широком диапазоне почтовых клиентов. Шире 640 пикселей — и вы рискуете получить горизонтальную прокрутку на небольших экранах и в клиентах с боковыми панелями.
Кнопки, удобные для касания, должны быть не менее 44×44 пикселей. Это рекомендация Apple Human Interface Guidelines для минимальных размеров области касания, и я бы предложил сделать их чуть больше — 46×46 пикселей — с учётом менее точных нажатий. Ничто не убивает мобильное взаимодействие с письмом быстрее, чем кнопка слишком маленького размера.
Размеры шрифтов на iPhone должны быть не менее 13 пикселей. Всё, что меньше 13 пикселей на iOS, запускает авто-масштабирование, которое ломает вёрстку. Используйте 14–16 пикселей для основного текста и 20–22 пикселя для заголовков. На мобильных устройствах больше — почти всегда лучше.
Темы писем на мобильных устройствах лучше держать до 30 символов. Большинство мобильных почтовых клиентов обрезают тему после 30–40 символов в зависимости от устройства и наличия текста предпросмотра. Размещайте важные слова в начале.
Используйте медиазапросы для изображений, оптимизированных под мобильные устройства. Доставляйте файлы меньшего размера на мобильные устройства — это важно и для скорости загрузки, и для экономии трафика. Изображение, загружающееся за 1 секунду по Wi-Fi, может загружаться 5 секунд при слабом мобильном соединении, и читатель не будет ждать.
Размер файла изображения важнее, чем думает большинство маркетологов. Держите отдельные изображения до 200 КБ, а общий вес письма — до 800 КБ. Сжимайте все изображения перед загрузкой. Используйте TinyPNG или Squoosh для сжатия без потерь. Многие ESP изменяют размер изображений на лету, но не всегда сжимают их достаточно агрессивно.
Используйте веб-безопасные шрифты как основной стек. Нестандартные шрифты в письмах поддерживаются непоследовательно. Arial, Helvetica, Georgia и Verdana отображаются надёжно везде. Можно указать пользовательский веб-шрифт в качестве первого выбора и перейти к веб-безопасному шрифту для клиентов без поддержки, но знайте, что большинство ваших читателей увидят запасной вариант. Проектируйте с учётом запасного шрифта, а не основного.
Просматривайте письмо на реальных устройствах, а не только в браузере. Предпросмотр в браузере на десктопе вводит в заблуждение. Письмо, выглядящее идеально в Chrome, может иметь перекрывающийся текст на iPhone SE или обрезанные изображения в приложении Gmail на Android. Используйте Litmus, Email on Acid или как минимум отправьте себе тестовое письмо и проверьте его на телефоне перед отправкой.
Экраны Retina и высокого DPI требуют изображений 2x. Если столбец письма имеет ширину 600 пикселей, а вы используете изображение шириной 600 пикселей, на экранах Retina (которые есть у большинства современных телефонов и ноутбуков) оно будет выглядеть размытым. Экспортируйте изображения в 2 раза больше отображаемого размера (1200 пикселей для столбца 600 пикселей) и задавайте ширину в HTML, равную отображаемому размеру. Файл будет больше, поэтому сжатие становится ещё важнее.
Совместимость с почтовыми клиентами
Вот неудобная правда о разработке писем: вы всё ещё создаёте вёрстку с помощью таблиц. В 2026 году. Пока веб перешёл на CSS Grid и Flexbox, электронная почта по-прежнему привязана к HTML-таблицам для создания макетов.
Почему? Потому что Microsoft Outlook использует движок рендеринга Word (да, текстового процессора) для отображения HTML-писем. А у Outlook достаточно доли рынка, особенно в B2B, что его нельзя игнорировать. Таблицы рендерятся стабильно в движке Word. Современный CSS — нет.
Используйте встроенный CSS. Большинство почтовых клиентов удаляют внешние таблицы стилей, а многие — стили из <head>. Единственный надёжный способ гарантировать применение стилей — встраивать их непосредственно в каждый элемент. Каждый серьёзный инструмент для создания писем делает это автоматически при экспорте.
Адаптивный дизайн с медиазапросами работает в большинстве современных почтовых клиентов: Apple Mail, iOS Mail, приложение Gmail, Outlook Mobile, Yahoo. Веб-клиент Gmail на десктопе технически поддерживает медиазапросы, но поскольку письмо отображается в небольшом окне предпросмотра, а не в полной вьюпорт, запросы часто не активируются. Аналогично большинству веб-почты, хотя некоторые используют iframe для отображения письма — в этом случае медиазапросы будут сработают. Создание писем по принципу mobile-first помогает: эти медиазапросы будут активированы. Для более широкой совместимости гибридный дизайн — ваша страховочная сеть.
Гибридный дизайн (также называемый «губчатым») — ваш запасной вариант. Он использует гибкие макеты, ширины в процентах и условные комментарии для создания писем, адаптирующихся к размеру экрана без медиазапросов. Применимо с таблицами и без. Марк Роббинс обычно рекомендует использовать div с таблицей-призраком, что позволяет избежать многих каскадных проблем, которые вызывают таблицы. Письмо хорошо выглядит при любой ширине, потому что базовая структура гибкая по умолчанию.
Марк Роббинс (ныне Developer Advocate по Email Experience в Customer.io) стал пионером CSS-only техник для писем, раздвигающих границы возможного без JavaScript (который заблокирован во всех почтовых клиентах). Его работа по CSS-only интерактивным компонентам, улучшению доступности и прогрессивному улучшению значительно продвинула эту область. Если вы создаёте письма на техническом уровне, изучите его работы.
Типичные различия в рендеринге почтовых клиентов для тестирования:
Outlook для десктопа (2019/2021/365) использует движок рендеринга Word, что означает: нет поддержки CSS-фоновых изображений, ограниченный контроль отступов и непредсказуемые интервалы в таблицах. VML (Vector Markup Language) традиционно рекомендовался для фоновых изображений в Outlook, но Марк Роббинс указал, что VML вызывает серьёзные проблемы с доступностью и рекомендует его избегать. Вместо этого рассмотрите использование сплошного цвета фона для Outlook.
Gmail для веба удаляет все стили из <head>, если они превышают определённый порог размера (около 16 КБ, увеличенный с предыдущего лимита ~8192 символа). Если ваш CSS сложный, некоторые стили будут молча удалены. И хотя Gmail технически поддерживает медиазапросы, размер окна предпросмотра означает, что они редко активируются в веб-клиенте — именно поэтому важен гибридный дизайн.
Apple Mail — наиболее соответствующий стандартам почтовый клиент, поддерживающий практически всё: медиазапросы, CSS-анимации и @supports. Это идеальный клиент для разработки, но не позволяйте ему ввести вас в заблуждение, что другие клиенты будут вести себя так же.
Yahoo Mail и AOL значительно улучшились за последние годы, но по-прежнему имеют особенности в поддержке медиазапросов и обработке отступов. всегда тестируйте.
Инструменты для дизайна писем
Экосистема инструментов для дизайна писем значительно созрела. Вот что я бы рекомендовал в 2026 году, разбив по сценариям использования.
| Инструмент | Тип | Лучше всего для | Ключевая функция |
|---|---|---|---|
| Beefree (BEE) | Конструктор без кода | Команды маркетинга | Drag-and-drop, сохранённые модули |
| Stripo | Без кода + код | Команды, которым нужен AMP | AMP for Email, 1400+ шаблонов |
| Chamaileon | Совместная работа | Enterprise-команды | Управление брендом, рабочие процессы согласования |
| Litmus | Тестирование + создание | QA-ориентированные команды | 90+ предпросмотров почтовых клиентов |
| Email on Acid | Тестирование | Команды с ограниченным бюджетом | Рендеринг клиентов + тестирование на спам |
| MJML | Кодовый фреймворк | Разработчики | Адаптивный язык разметки для писем |
| Maizzle | Кодовый фреймворк | Разработчики Tailwind CSS | Tailwind для писем, пайплайн сборки |
| React Email | Кодовый фреймворк | React-разработчики | На основе компонентов, экосистема npm |
| Parcel | Кодовая IDE | Разработчики писем | Предпросмотр в реальном времени, подсказки CSS |
| Figma to Email | Рабочий процесс | Дизайн-команды | Дизайн в Figma, экспорт в HTML |
Рассмотрим их подробнее.
Конструкторы без кода для команд маркетинга:
Beefree (бывший BEE) — моя главная рекомендация для команд, которым нужно быстро создавать письма без программирования. Интерфейс drag-and-drop действительно хорош, а функция сохранённых модулей позволяет создать библиотеку многократно используемых компонентов. Stripo — лучший вариант, если вам нужна поддержка AMP for Email или доступ к обширной библиотеке шаблонов (1400+). Chamaileon создан для enterprise-команд, которым необходимо управление брендом и рабочие процессы согласования прямо в процессе создания писем.
Платформы тестирования:
Litmus по-прежнему остаётся золотым стандартом, предлагая предпросмотр в более чем 90 комбинациях почтовых клиентов и устройств. Не дёшево, но если вы отправляете разнообразной аудитории (а вы, вероятно, так и делаете), то видеть, как письмо отображается в Outlook 2019 на Windows, Apple Mail на macOS и Gmail на Android — необходимо. Email on Acid предлагает аналогичные предпросмотры рендеринга плюс тестирование на спам по более низкой цене. Для команд с ограниченным бюджетом — сильная альтернатива.
Кодовые фреймворки для разработчиков:
MJML — язык разметки, компилируемый в адаптивный HTML для писем. Вы пишете чистую семантическую разметку, а MJML генерирует сложный вывод на основе таблиц. Самый популярный фреймворк для разработчиков писем. Maizzle привносит Tailwind CSS в разработку писем с пайплайном сборки, который обрабатывает встраивание стилей, удаление неиспользуемого CSS и генерацию готового к продакшену HTML. React Email позволяет создавать шаблоны писем с использованием React-компонентов в экосистеме npm. Если ваша команда уже мыслит компонентами, это естественное решение. Parcel (не веб-бандлер, а IDE для писем) обеспечивает предпросмотр в реальном времени и подсказки о поддержке CSS в процессе написания кода.
Рабочие процессы дизайн-в-код:
Рабочие процессы Figma to Email становятся всё более распространёнными. Дизайн-команды создают шаблоны писем в Figma с библиотеками компонентов, затем экспортируют в HTML через плагины или передают дизайны разработчикам, которые реализуют их в MJML или Maizzle.
Дизайн писем с применением ИИ
Ландшафт инструментов дизайна значительно изменился в начале 2026 года, и дизайн с поддержкой ИИ больше не является теоретическим. Вот что реально применимо сегодня.
Figma MCP + Claude Code ("Code to Canvas") — самое значимое достижение. Объявленная в феврале 2026 года, MCP-интеграция Figma создаёт двунаправленное соединение между дизайн-файлами и инструментами ИИ-кодирования. Claude инспектирует дизайны Figma семантически — понимая системы дизайна, иерархии компонентов, токены отступов и намерения, а не только пиксели. Для писем: опишите, что вам нужно ("создай hero-секцию письма в соответствии с нашим брендом, с изображением на всю ширину, заголовком, подзаголовком и кнопкой CTA") и получите дизайн, уважающий вашу существующую дизайн-систему в Figma. В сочетании с MJML или React Email этот рабочий процесс переходит от брифа к готовому шаблону письма за минуты, а не часы.
Paper.design — это MCP-совместимый дизайн-холст с 24 инструментами, нативный для HTML и CSS. В отличие от Figma, которая выводит векторы, требующие конвертации, Paper работает в той среде, которую электронные письма действительно используют. Двунаправленный с Claude Code и Cursor — ИИ-агенты могут инспектировать артборды, изменять макеты, писать HTML и обновлять стили. Токены дизайна синхронизируются из Figma, реальные данные API наполняют интерфейсы, вывод конвертируется в React или Tailwind. Бесплатный план (100 MCP-вызовов в неделю) и Pro ($20 в месяц, 1M вызовов в неделю). Для дизайнеров писем, желающих ИИ-поддержку дизайна без выхода из нативной HTML-среды, Paper устраняет целый этап конвертации из рабочего процесса.
Cursor для разработки писем заслуживает упоминания, поскольку стал де-факто средой ИИ-кодирования, а шаблоны писем — это код. Дизайнеры, использующие MJML или React Email, могут итерировать в Cursor в 10 раз быстрее, чем в традиционном редакторе. Опишите желаемое изменение на естественном языке, Cursor напишет код, вы увидите результат в предпросмотре. Для команд, перешедших на разработку писем в виде кода (что, как показывает раздел о фреймворках выше, является направлением развития), Cursor сжимает петлю обратной связи между "я хочу это" и "вот оно".
Рабочий процесс design-from-Claude в Nitrosend позволяет разрабатывать шаблоны писем полностью с помощью естественного языка — как через MCP-сервер в Claude, так и через встроенный ИИ-чат Nitrosend. "Создай двухколоночную витрину товаров с нашим логотипом в шапке, тремя карточками товаров с изображениями и ценами, и зелёной кнопкой CTA" создаёт готовый шаблон, который можно итерировать в режиме диалога. Для соло-основателей и небольших команд без дизайн-ресурсов это полностью устраняет узкое место дизайна. В настоящее время в закрытом бета-тестировании.
Другие ИИ-инструменты дизайна, за которыми стоит следить:
Mailmodo предлагает комплексное создание писем с ИИ: опишите нужное письмо, и оно генерирует полноценное интерактивное письмо с поддержкой AMP. EmailCanvasAI создаёт шаблоны писем по текстовым запросам. Генератор шаблонов ИИ от Mailjet создаёт стартовые дизайны по кратким описаниям. Это инструменты на ранних стадиях, но они сигнализируют о направлении: дизайн писем переходит от "создайте визуально" к "опишите в диалоге".
Практическая рекомендация: Если ваша команда уже использует Figma, исследуйте рабочий процесс Figma MCP + Claude Code для вашей дизайн-системы. Если вы ориентированы на разработчиков, Cursor с MJML или React Email — самый быстрый путь к ИИ-поддержке разработки писем. Если вы небольшая команда без специальных ресурсов дизайна или разработки, подход Nitrosend или Mailmodo полностью устраняет узкое место. А если вы хотите максимального контроля над нативным HTML-дизайном с ИИ-поддержкой, Paper.design стоит оценить.
Шаблоны без кода vs кодированные шаблоны
Это не решение "или-или". Речь идёт о выборе подхода под конкретный сценарий.
Инструменты без кода в 3–5 раз быстрее для разовых кампаний. Когда нужно создать одно рекламное письмо, конструктор drag-and-drop справится за 30 минут вместо 3 часов. Используйте Beefree, Stripo или встроенный конструктор вашего ESP.
Кодированные шаблоны лучше для повторяющихся сценариев, контроля версий и дизайн-систем. При создании welcome-серии, которая будет рассылаться тысячам подписчиков месяцами или годами, инвестиция в правильно написанный шаблон окупает себя. Кодированные шаблоны могут храниться в системе контроля версий (Git), проходить проверку в pull request и систематически обновляться по всему сценарию.
Большинство зрелых email-программ используют оба подхода. Кодированные шаблоны для автоматизированных сценариев (приветствие, брошенная корзина, после покупки) и инструменты без кода для разовых кампаний (запуски продуктов, сезонные акции, объявления). Такой гибридный подход даёт последовательность там, где это важно, и скорость там, где она нужна.
Системы дизайна шаблонов писем
Если вы рассылаете более нескольких типов писем, вам нужна дизайн-система. Не шаблон. Система.
Токены бренда определяют константы: основные и дополнительные цвета, стек шрифтов, стандартные единицы отступов (8px, 16px, 24px, 32px), радиус скругления для кнопок и другие визуальные константы. Задокументируйте их однажды и используйте повсюду.
Библиотека компонентов содержит строительные блоки: шапка (логотип, навигация), hero-секция (изображение, заголовок, CTA), текстовый блок (заголовок, основной текст, ссылка), карточка товара (изображение, название, цена, кнопка), кнопка CTA (основная, второстепенная, текстовая ссылка) и подвал (ссылки на соцсети, юридический текст, отписка). У каждого компонента определено адаптивное поведение, обработка тёмного режима и требования доступности.
Шаблоны макетов объединяют компоненты в стандартные типы писем: рекламное письмо, рассылка, транзакционное уведомление, приветственное письмо, письмо о брошенной корзине. Это ваши отправные точки, не ограничения.
Руководство по использованию объясняет команде, когда что применять, сколько текста включать, какие компоненты обязательны (подвал, отписка), а какие необязательны, и любые правила бренда относительно изображений, тона или расположения CTA.
На создание дизайн-системы требуется время. Для типичного e-commerce бренда ожидайте 40–60 часов начальной разработки. Но эта инвестиция быстро окупается. После того как система выстроена, создание нового письма сокращается с 3–4 часов до 30–60 минут. И каждое отправленное письмо автоматически соответствует бренду и доступно для всех.
Если вы небольшая команда без ресурсов на полноценную дизайн-систему, начните с одного хорошо построенного мастер-шаблона для вашего наиболее распространённого типа письма (обычно рекламного). Сделайте его как следует один раз: с поддержкой тёмного режима, функциями доступности и мобильной оптимизацией. Затем адаптируйте его для каждой рассылки. Это не дизайн-система, но это решает 80% задачи.
Доступность
Пол Эйри долгие годы является ведущим экспертом по доступности электронных писем, и его ключевая мысль заслуживает повторения: доступные письма — не только правильное решение, они показывают лучшие результаты для всех.
По оценкам, 15–20% людей имеют какую-либо форму инвалидности. Это включает нарушения зрения, двигательные расстройства, когнитивные особенности и ситуативные ограничения (например, чтение письма одной рукой, держа ребёнка). Проектирование с учётом доступности означает проектирование для всех них, и в процессе письмо становится лучше и для остальных 80%.
Требования WCAG 2.1 для писем:
Контраст цвета должен соответствовать соотношению 4,5:1 для обычного текста и 3:1 для крупного. Используйте инструмент проверки контраста. То, что хорошо выглядит на вашем качественном мониторе, может быть нечитаемым на дешёвом экране при ярком солнце.
Все изображения должны иметь описательный alt-текст. Не "image1.jpg" или "баннер". Опишите, что показывает изображение и что нужно знать читателю. Если изображение чисто декоративное, используйте пустой атрибут alt (alt=""), чтобы скринридеры его пропускали.
Соблюдайте логический порядок чтения. Скринридеры следуют порядку исходного HTML, а не визуальной компоновке. Убедитесь, что содержимое осмысленно при линейном чтении сверху вниз.
Включите атрибут языка (lang="en") и атрибут направления (dir="ltr") в HTML-элемент, чтобы скринридеры использовали правильную модель произношения и направление текста.
Ссылки должны быть понятны по одному тексту. "Нажмите здесь" бессмысленно вне контекста. "Скачайте отчёт Email Benchmark 2026" точно сообщает, куда ведёт ссылка.
Не полагайтесь только на цвет для передачи информации. Если цена показана красным для обозначения скидки, добавьте также текст "Цена по акции" или используйте зачёркивание оригинальной цены.
Используйте масштабируемый текст. Никогда не задавайте размеры шрифта в пикселях, которые нельзя переопределить настройками пользователя.
Обеспечьте навигацию с клавиатуры. Все интерактивные элементы должны быть доступны и управляемы с клавиатуры.
В макетных таблицах добавляйте role="presentation" — это сообщает скринридерам, что таблица используется для компоновки, а не данных. Без этого атрибута скринридеры будут пытаться интерпретировать макет как таблицу данных, создавая запутанный опыт.
Область касания не менее 44×44 пикселей — это не только лучшая практика для мобильных. Это требование доступности. Пользователям с двигательными нарушениями необходим достаточный размер цели.
Доступность — это не контрольный список, выполняемый однажды. Это практика, которую вы поддерживаете в каждом письме. Добавьте проверку доступности в QA-процесс. Перед каждой рассылкой проверяйте: у каждого изображения есть alt-текст? Логичен ли порядок чтения? Достаточны ли размер и контраст всех кнопок и ссылок? Понятно ли письмо, если прищуриться и читать только заголовки и тексты ссылок? Если хоть один ответ — нет, исправьте до отправки.
Тестирование со скринридером — золотой стандарт. Если вы хотите по-настоящему понять, насколько ваши письма доступны, протестируйте их с реальным скринридером. VoiceOver на Mac и iOS, NVDA на Windows и TalkBack на Android — все бесплатны. Прослушивание письма, зачитываемого скринридером вслух, выявит проблемы, которые при визуальной проверке никогда не обнаружатся. Старайтесь делать это не реже одного раза в квартал для ваших наиболее используемых шаблонов.
Тёмный режим
Не менее 33% получателей просматривают письма в тёмном режиме, и этот процент растёт. Тёмный режим может разрушить дизайны писем, не рассчитанные на его обработку.
Почтовые клиенты по-разному справляются с тёмным режимом. Одни инвертируют цвета. Другие меняют фоны. Некоторые делают и то, и другое. Результатом может быть чёрный текст на чёрном фоне (невидимый), тёмно-синие ссылки на тёмно-сером фоне (почти невидимые) или логотипы с белым фоном, вокруг которых теперь резкий белый прямоугольник.
Тестируйте письма в тёмном режиме в Apple Mail, Gmail и Outlook. Эти три клиента по-разному обрабатывают тёмный режим и вместе охватывают большинство пользователей тёмного режима.
Используйте прозрачные PNG для логотипов. Логотип с белым фоном на белом письме выглядит нормально. Тот же логотип в тёмном режиме получит белый прямоугольник вокруг. Прозрачные фоны решают эту проблему.
Избегайте чисто белого фона. Используйте слегка кремовый цвет (#F5F5F5 или похожий) для фона тела письма. В тёмном режиме чистый белый (#FFFFFF) может создавать ослепляющую вспышку. Кремовый адаптируется изящнее и приятнее для глаз в обоих режимах.
Используйте CSS-медиазапрос @media (prefers-color-scheme: dark) там, где поддерживается, чтобы задать явные стили тёмного режима. Это даёт контроль над тем, как выглядит письмо в тёмном режиме, а не оставляет догадки почтовому клиенту. Поддержка хорошая в Apple Mail и Outlook. Gmail игнорирует это и применяет собственные трансформации тёмного режима.
Практические советы по дизайну для тёмного режима:
Используйте рамку или лёгкую тень вокруг изображений с белым или светлым фоном, чтобы они не "плавали" в тёмном режиме. Добавьте тонкую рамку 1px в цвете бренда вокруг логотипов как меру предосторожности.
Для цветов текста избегайте чисто чёрного (#000000) в светлом режиме. Используйте тёмно-серый (#333333 или #222222). В тёмном режиме почтовые клиенты нередко инвертируют чистый чёрный в чистый белый, что выглядит резко. Слегка отличающийся от чёрного текст инвертируется в слегка отличающийся от белого — его читать удобнее.
Тестируйте кнопки CTA в обоих режимах. Хорошо заметная на белом фоне кнопка может исчезнуть на тёмном. Рассмотрите добавление рамки к кнопкам, чтобы они оставались видимыми независимо от цвета фона.
Если вы используете цвета фона в секциях содержимого (например, в выделенном блоке советов или цветном баннере), в тёмном режиме эти цвета могут быть изменены или удалены. Всегда убеждайтесь, что содержимое читаемо даже если фон вернётся к стандартному тёмному фону почтового клиента.
Интерактивное письмо
Интерактивные элементы в письмах могут существенно повысить вовлечённость. Показатели кликов после открытия растут в среднем на 31,7% при наличии интерактивных элементов.
Но интерактивность в письмах имеет принципиальную оговорку: поддержка сильно различается между почтовыми клиентами. Всегда проектируйте с учётом принципа прогрессивного улучшения, который отстаивал Джейсон Родригес. Ваш интерактивный элемент — это бонус для клиентов, поддерживающих его. Запасной вариант для остальных должен представлять собой полностью рабочее, хорошо выглядящее письмо.
Эффекты CSS hover имеют широкую поддержку и дают прирост вовлечённости на 5–10%. Простые вещи: изменение цвета кнопки при наведении, оверлеи на изображениях, анимации подчёркивания. Дополнения с низким риском и высокой отдачей.
Аккордеоны на CSS имеют умеренную поддержку и могут дать прирост на 10–15%. Хорошо работают для писем с большим количеством контента: рассылок или сравнений товаров, позволяя читателю раскрывать только интересующие разделы. Не работают в веб-клиенте Gmail и Outlook, поэтому запасной вариант должен показывать весь контент развёрнутым.
Анимированные GIF поддерживаются повсеместно и дают на 5–8% больше вовлечённости. Каждый почтовый клиент поддерживает GIF (кроме некоторых версий Outlook для десктопа, показывающих только первый кадр). Это самый безопасный интерактивный элемент. Хорошо работают демонстрации продуктов, ненавязчивые анимации и визуальный интерес.
AMP for Email предлагает наиболее мощную интерактивность с приростом вовлечённости на 20–30%: карусели, формы, меню-аккордеоны и даже актуальный контент прямо в письме. Но поддержка ограничена Gmail и Yahoo, требует регистрации отправителя у Google, и распространённость остаётся низкой. Если ваша аудитория преимущественно в Gmail и есть ресурсы разработчиков, AMP может быть мощным инструментом. Для большинства отправителей это пока не стоит инвестиций.
Таймеры обратного отсчёта — популярный интерактивный элемент для акционных писем и предложений с ограниченным сроком. Они генерируются на сервере в виде анимированных GIF с живым обратным отсчётом. Сервисы Sendtric и Mailmodo предлагают бесплатные и платные генераторы таймеров. Работают в практически любом почтовом клиенте. Важная оговорка: используйте реальные таймеры обратного отсчёта только для реальных дедлайнов. Таймер, отсчитывающий время до акции, которая потом тихо продляется, приучает подписчиков игнорировать срочность.
Встроенные опросы и голосования могут значительно повысить вовлечённость, превращая письмо из монолога в диалог. Такие инструменты, как Typeform и SurveyMonkey, создают встраиваемые однотипные голосования, работающие в большинстве почтовых клиентов. Для клиентов без поддержки встроенной версии запасной вариант — ссылка на опрос. даже однотипный опрос в рассылке может увеличить показатели кликов на 15–20%.
Золотое правило интерактивного письма: всегда сначала создавайте запасной вариант. Проектируйте письмо так, словно ни один интерактивный элемент не будет работать. Затем добавляйте интерактивность поверх для поддерживающих клиентов. Так каждый подписчик получит работающее письмо, а те, у кого современные клиенты, получат кое-что дополнительно.