Меня очень расстраивает тот мизер полезного контента про автоматизацию дизайна, который есть в сети. Такие доклады и статьи чаще всего где-то на пересечении продуктового дизайна и разработки. Дизайн-системы, версионирование прототипов, систематизация стилей и все в этом духе. Про графический дизайн — ничего.

Не буду сильно рефлексировать по этому поводу, а просто попробую рассказать о нашем удачном опыте минимизации дизайнерской рутины в маркетинговых задачах и принципе «дизайн без дизайнера», который я очень люблю.

Этот лонгрид я держал в голове уже больше полугода, с момента, когда я посмотрел пару редких видео и прочитал пару еще более редких статей про создание собственного плагина для Figma. В тот момент я загорелся идеей, что это тот самый неизведанный нами мир с возможностями, которые решат все проблемы, связанные с дизайнерской рутиной.

Вооружившись VSCode, остаточными навыками что-либо программировать на JS (а главное — находить нужные мне куски в чужом коде) и описанием Figma API, я за ночь запилил простенький плагин. Он клонирует шаблон с дизайном на холсте и подставляет в клоны выделенные изображения. Не буду вдаваться в подробности результата, главное, что я самостоятельно пощупал возможности API и в голове собрал картинку, как мы это сможем использовать. И практически сразу нарисовал прототипы будущего плагина для Figma, который автоматизирует огромный кусок задач дизайнера в нашей компании и решит проблему, которая всем мозолила глаза уже года два.

Есть такая штука, называется Open Graph. Это разметка, которая контролирует, как будет выглядеть ссылка на вашу страницу в ленте постов или сообщений в мессенджерах и социальных сетях. Там можно настраивать заголовок, короткое описание, но сейчас нас интересует только изображение или его еще называют превью страницы. У каждого доклада на наших конференциях есть страница с описанием, которую мы шарим примерно везде.

И у каждой такой страницы — уникальная превьюха, на которой обязательно есть имена всех спикеров, с указанием компаний, в которых они работают, их лицами, а также непосредственно название доклада. Все это в новом для каждого сезона дизайне конференции. Нюансом является еще то, что для англоязычной версии страницы в OG мы используем изображение с надписями на английском языке.

Какой объем. Если говорим только о картинках-превью, то в осеннем сезоне 2022 около 700 штук на русском и английском языках для разных версий сайта. И это только OG. А есть еще баннеры для рекламы, эфирная графика, разные печатные носители — и все это в разном виде содержит плюс-минус одни и те же данные о докладе: имена спикеров, их фотки и название доклада. И каждой отдельной картинке не требуется быть уникальной, они делаются по шаблону.

Вообще забавно, что для описания дизайнерской фичи я должен рассказать о том, как заявка от спикера идет по бизнес-процессу и превращается в публикацию на сайте. Но я верю в принцип, что любой дизайн должен быть осмысленным и разумно встраиваться в процессы, будь то UX какого-то сервиса или внутренние процессы в компании.

Попробую остановиться только на самом важном. Для конференций мы собираем заявки на выступления. Спикер заполняет форму Call For Papers, и у нас запускается бизнес-процесс, который завершится либо выступлением спикера, либо нет (по разным причинам). Нас интересует первый вариант, когда Программный комитет принимает заявку спикера и выбирает его доклад для участия в программе конференции. С этого момента заявка становится ценным активом конференции, и с ней начинают работать маркетологи.

Дальше следите за руками. Чтобы продать билеты, нам нужно как можно больше опубликованных докладов в программе. Ведь участники принимают решение, идти или не идти на конференцию, чаще после изучения программы. Для наших рекламщиков тоже нужны доклады в программе, чтобы было что рекламировать через таргет, хабропосты и рассылки.

Чтобы опубликовать доклад на сайте, у него должен появиться контекст: биография и фото спикера, описание доклада и, внимание, изображение для Open Graph. Потому что без него любые публикации в соцсетях и телеге будут выглядеть уныло.

Подготовкой всего контекста занимается редактор. Он проверяет описания доклада и биографию спикера, следит за правильностью написаний имен и компаний, допереводит непереведенные куски на английский, все это сохраняет в CMS и переводит заявку в статус «Опубликовано» в Jira. В результате, на сайте конференции появляется страница с описанием доклада на двух языках, а фото спикера появляется в галерее с другими выступающими — теперь все это можно активно рекламировать. И для всех в дальнейшей цепочке продвижения очень важно, чтобы кусок бизнес-процесса, связанный с выкладкой принятых в программу докладов, занял как можно меньше времени. Потому что чем раньше начнем рекламировать, тем больше заработаем.

«Так, а что там с картинками для Open Graph?» — спросите вы. А это как раз узкое место текущего процесса. Потому что в нем принимает участие еще и дизайнер, который должен эту картинку подготовить. То есть буквально: доклад не опубликуется, пока дизайнер не сделает типовую картинку по шаблону, даже если вообще все остальное уже готово. И любой дизайнер вам скажет, что ему гораздо удобнее получить пакет из нескольких ТЗ на однотипный дизайн, чтобы сделать всёкакое-то количество макетов за один раз, нежели каждый раз отвлекаться на одну новую картинку несколько раз в течение дня. Получаем некоторый лаг в процессе между готовностью к публикации и непосредственно публикацией.

Этот лаг может удлиняться в выходные, во время сезонной загрузки, болезни дизайнера итд. Поэтому так важно вообще исключить дизайнера из этого процесса. Подготовкой изображений превью для Open Graph должен заниматься редактор, потому что это очень естественно и устраняет узкое горлышко в бизнес-процессе. Но тогда нужен инструмент, который позволит получать готовую картинку сотруднику без компетенций дизайнера.

Вы можете мне сказать, что эти изображения легко автоматически рендерить с помощью чего угодно, от джаваскрипта до калькулятора. И я не стану здесь спорить, это правда очень просто. Но такой вариант нам не очень подходит и вот почему:

• Большая вариативность шаблонов в рамках одного сезона. Только для каждой конференции нужно 6 шаблонов по количеству спикеров. А у каждой конференции — свой визуал.
• Названия докладов, имена спикеров всегда разные по длине, любую автоматическую верстку может раздалбывать, нужно иметь возможность это редактировать.
• Старые конференции уходят в архив, и страницы должны сохранять превью. Чтобы не копить скриптовое легаси, лучше, чтобы эти изображения лежали в CMS вместе с остальным контентом.

Идея отсутствия дизайнера в процессе публикации доклада не моя, и она успешно была реализована перед ковидом. У нас есть собственный сервис работы с заявками на доклады, который называется JEvent. В нем есть функционал создания изображений для Open Graph, которым раньше пользовался редактор перед публикацией доклада. И на мой взгляд, это крутая штука. Дизайнер через встроенный редактор готовил шаблон перед сезоном и возвращался только через полгода, чтобы обновить шаблон. А редактор выбирал нужные доклады из списка принятых в программу, для которых создавались картинки на русском и английском языках. Можно выбрать или несколько докладов, или сразу весь список и скачать картинки одним зипом. Звучит прекрасно! Но, как обычно, есть нюансы.

OG Builder, как называется этот инструмент, может создавать картинки только для докладов с одним спикером. И это совсем не проблема для доковидной истории наших конференций, когда парных докладов были единицы. В онлайне доклады с несколькими спикерами стали нормальностью. Например, в весенней конференции Heisenbug, только 29 активностей из 50 были с одним спикером. То есть OG Builder не смог бы удовлетворить 42% техзаданий.

Плюс к этому, у инструмента ограниченные возможности по кастомизации шаблонов. Никаких тебе масок, фотка только прямоугольная, 6 шрифтов. И вроде как и пофиг, но с такими ограничениями единства всей визуалки уже не достичь. Мы или деградируем на всех остальных макетах в рекламе, или у нас будет выбивающийся из общего стиля гадкий утенок оупенграф.

Еще нет автоскейла текста. И вот это по-настоящему больно. Потому что в шаблоне должен быть выбран такой кегль шрифта, чтобы одновременно было и не слишком мелко, и чтобы название доклада не уезжало за пределы макета. А для этих макетов очень важно делать размер текста максимально крупным.

Почему не стали дорабатывать этот инструмент? Дорого. Сама идея построить свой ограниченный фотошоп над какой-то моделью данных, чтобы переваривать и выдавать эти данные в графическом виде — интересно, но слишком оптимистично. Потому что любой исключающий кейс будет требовать дорогой доработки инструмента. И когда этих кейсов стало критически много, то стало понятно, что стоит по-новому взглянуть на проблему и поискать другое решение.

Чем изобретать свой велосипед фотошоп, лучше взглянуть на существующие фотошопы и найти тот, который мы сможем доделать под себя. И, конечно, в этом месте нет равных Figma, которая еще не испортилась под влиянием Adobe.
Итак, в чем идея. Мы используем Figma как площадку с достаточными для нас графическими возможностями, простой организацией рабочего пространства, а самое главное API и инструментарием для создания плагинов и расширением базового функционала.

Дизайнер включается в работу единожды перед сезоном на этапе подготовки. Нужно сделать шаблоны макетов и организовать пространство с файлами для каждой конференции. Создаются шаблоны по некоторым правилам. Среди них нет размеров, количества слоев, используемых шрифтов — никаких ограничений для дизайнерской мысли. Все, что требуется соблюдать, — корректное название текстовых слоев и фреймов для изображений. Потому что именно по этим названиям плагин будет искать места для подстановки переменных данных. Например, фрейм с названием активности должен всегда называться «activityName». У нас может быть от 1 до 6 спикеров в докладе, поэтому делаем 6 таких шаблонов и правильно называем каждый фрейм. Всё, от дизайнера больше ничего не нужно, можно идти заниматься более важными вещами, например, в очередной раз переделывать UI расписания на сайте.

Дальше заниматься макетами будет только редактор. В тот момент, когда нужно опубликовать новый доклад на сайт, он открывает файл с нужными шаблонами, запускает плагин, авторизуется и получает список всех принятых в программу докладов. Этот список со всеми данными про доклады подгружается через наш API и сохраняет актуальность в случае любых изменений на стороне работы с заявками. Выбираем нужные доклад и шаблон — готово. Плагин проверит, были ли созданы в этом документе макеты для выбранных докладов. Если макеты уже были, он их обновит, а если нет, то просто создаст страницы для каждого доклада. И еще назовет их так, чтобы удобно было искать.

Редактору не обязательно прощелкивать страницы с макетами и экспортировать картинки с помощью стандартных инструментов Figma. В самом плагине можно нажать на «Экспорт», чтобы выгрузить все новые изображения в одном архиве.

Главная фича — автоскейл текста. Плагин выбирает размер шрифта в текстовом фрейме таким образом, чтобы он был вписан в область, которую определил дизайнер, с максимальной крупностью шрифта. В итоге, редактору не нужно вообще ничего делать нативными инструментами Figma. Все было сделано до него, остается только запустить плагин и выбрать доклад, для которого нужно сделать изображения.

Прошедший сезон стал первым, когда мы все превью для страниц докладов делали по новому процессу с новым инструментом. Можно считать, что эксперимент оказался удачным, и мы выключили дизайнера из процесса создания и передачи макетов для превью страниц. Возникали некоторые проблемы с автоскейлом текста, когда длинные слова в коротких названиях переносились посреди слова, иногда нужно было отскейлить фотографию спикера, чтобы лучше было видно лицо. Все эти минорные исправления были уже на стороне редактора, который справлялся с ними без глубоких компетенций в дизайнерском ПО.

Я ранее упомянул, что помимо изображений для Open Graph есть еще целый набор похожих макетов, где используются те же самые данные про доклады. Я собрал почти все на картинке ниже.

Все это также делалось вручную. Хорошая новость, что решение с плагином не зациклено только на создании OG. Шаблоны и сам плагин не привязаны друг к другу цепями, поэтому можно сделать шаблоны для всех этих макетов и без каких-либо проблем массово создавать макеты и для рекламных баннеров, и для эфирной графики.

Например, если нам нужно сделать рекламный баннер для VK с изображением одного конкретного спикера, мы выбираем доклад, где участвует докладчик, выбираем подготовленный шаблон, и все готово. Можно отправлять в рекламу.

Таким образом, плагин масштабируется и на автоматизацию создания большого количества макетов, помимо превью страниц.

Тема с такими решениями для нас новая, но опытным путем мы выяснили, что разработка плагинов для Figma может идти разными дорожками. В начале пути нужно было решить узкую проблему по созданию превью страниц докладов. Закрывая лишь эту боль, мы могли выбрать тупиковый путь, который не предусматривал масштабируемость. Но увидев потенциал этого решения, иногда даже не понимая, а что еще мы от него хотим, мы выбрали избыточный стек технологий, который полностью себя окупил, когда фича-реквесты к плагину стали разнообразнее. Архитектура плагина устроена таким образом, что мы можем легко внедрять новые функции без особой боли.

Как и все веб приложения, наш плагин состоит из двух частей. Это клиентская часть (frontend) и северная часть (backend). Серверную часть мы брали готовую, которую использует Speaker Relationship Management System — наш большой внутренний продукт для контроля и движения заявок на доклады и формирования программы конференции. В Figma нам надо было реализовать только клиентскую часть.

Для простых плагинов, Figma разрешает вообще не делать интерфейс, а просто исполнять JS--код при запуске плагина. Или можно было реализовать первоначальный интерфейс на нативном HTML, без использования дополнительных библиотек и фреймворков. Так как плагины для Figma это не совсем классический веб, то это был бы самый простой, но неверный путь.

При разработке плагина, тип архитектуры пал на одностраничное приложение или SPA (Single Page Application) с использованием библиотеки React. Как грамотно подружить React и Figma API — вопрос, который пришлось изучать, но затраченное время окупилось удобством разработки и возможностью к масштабированию приложения.

В итоге получилось на 100% автоматизировать создание изображений для Open Graph. А еще сделали инструмент универсальным, чтобы автоматизировать создание тысяч других маркетинговых макетов. А еще благодаря тому, что уже была база в виде бэка и API, а с другой стороны мощная Figma, продумать концепцию, сделать прототипы и накодить фронт оказалось не очень большой инвестицией.
Честно говоря, я не знаю похожие кейсы такой автоматизации графического дизайна внутри других компаний — но, возможно, просто потому что ими мало делятся. Может быть, этот текст будет не просто интересным описанием нашей реализации, но еще и станет основанием для идеи инвестировать в создание похожего решения в вашей команде.