Как автоматизировать дизайн-поддержку и превратить ее в конвейер

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

Мы в Uplab выстроили конвейер подготовки макетов — от стандартизированного брифа до автоматической отчетности — и обкатали его на проектах с сотнями задач в месяц. Ниже разбираем, как система работает и из чего собрана, на примере дизайн-поддержки для крупного маркетплейса.

Когда поток задач от партнеров обгоняет штат дизайн-команды

Маркетплейс работает с десятками и сотнями брендов-партнеров, и приток новых сложно прогнозировать — число может расти плавно, а может скачками. Каждый новый партнер — это карточки для акций, ресайзы креативов под форматы приложения и сайта, макеты для email-рассылок и соцсетей.

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

Анатомия конвейера: бриф, доска, роли, регламенты

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

Бриф как контракт

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

Работая над контентом для маркетплейса, дизайнер учитывает интересы и площадки, и компаний, размещающих там свои товары и услуги. Обязательный шаблон брифа помогает собрать требования обеих сторон в одном месте: материалы бренда, перечень нужных ресайзов, форматы.

Регламенты и база знаний вместо личной памяти команды

Документация фиксирует сроки, стандарты качества, процессы взаимодействия и согласований на проекте. Отдельный пункт — принципы работы с каждым форматом изображений. У баннера для рекламы и у email-рассылки разная специфика: свои размеры, технические ограничения, типичные ошибки.

Без таких требований дизайнер получает задачу и не понимает, что именно нужно. Приходится уточнять у менеджера, а тот дублирует одну и ту же информацию в каждой новой задаче. С базой знаний дизайнер сам находит параметры, а менеджер занимается чем-то более квалифицированным, чем объяснения по кругу.

Важно: любой регламент работает, только если его регулярно актуализируют. Документ, написанный один раз и забытый, через пару месяцев устаревает. Вот как было у нас: в ходе работы у дизайнеров возникали вопросы, команда клиента давала уточнения — всё это фиксировали в FAQ и базе знаний, чтобы не проговаривать заново с приходом каждого нового человека. Туда же попадали лайфхаки самих дизайнеров — приемы, которые ускоряли работу или повышали качество.

Схема от Uplab: как мы настроили доску задач

Для дизайн-поддержки маркетплейса мы выстроили конвейер — через него ежедневно проходили до 20+ макетов email-рассылок и до 400+ ресайзов. Работали в таск-менеджере Jira — там можно настраивать карточки, статусы и доски под свой процесс.

В нашей схеме жизненный цикл задачи шел по одной и той же цепочке статусов:

• Бэклог. Сюда падали все новые заявки от клиента.

• В работе. Менеджер назначал исполнителя, дизайнер готовил макет.

• Внутреннее согласование. Арт-директор проверял результат до того, как его увидит клиент.

• Доработка. При замечаниях задача попадала сюда, а после правок уходила на повторную проверку.

• Согласование клиента. В нашем проекте этот шаг был двухуровневым: сначала макет принимал постановщик задачи, затем — ЛПР. На каждом уровне могли появиться правки.

• Готово. Финальный статус после того, как все стороны приняли результат.

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

Кроме цепочки статусов, настроили саму карточку задачи — добавили кастомные поля:

1. Формат контента — тип задачи. Key visual (главный рекламный образ), ресайз, шаблон рассылки, анимация — клиент мог выбрать один формат на задачу, без исключений. Это убрало путаницу в переписках и упорядочило отчеты: форматы не смешивались в одной задаче, и можно было легко посчитать стоимость и объем для разных типов контента.

2. Тип KV — для key visual, у которых внутри формата есть деление на разновидности со своими требованиями.

3. Ссылка на макет в Figma — без этого поля результат работы потеряется в комментариях к задаче и его не получится быстро выгрузить для отчета.

4. Количество — клиент заполняет при постановке задачи, указывая число необходимых макетов.

5. Внутреннее количество — позволяет разделить большой объем однотипных макетов или ресайзов между несколькими дизайнерами.

6. Дата отгрузки — заполняется автоматически, используется для расчета скорости прохождения задачи.

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

Продакт-менеджеру на стороне заказчика из всего этого важнее две вещи: статус задачи в моменте и отчетность по итогам периода — сколько форматов, в каком количестве, на какую сумму. Система делает статусы прозрачными, а отчет — выгружаемым в нужном виде. Но об этом стоит позаботиться еще на старте.

Настраиваем отчеты, чтобы экономить время на выгрузку

Формат отчета нужно продумывать на этапе настройки доски, а не после запуска. В современных таск-менеджерах достаточно опций, чтобы сократить ручную работу.

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

Роли и маршрутизация: почему команда взаимозаменяема

У нас онбординг нового дизайнера в проект занимал 1–2 дня. Для сравнения: в некоторых крупных компаниях введение дизайнера в должность обычно длится около трех месяцев. Разница — в регламентах и базе знаний. Новый человек читает документацию, понимает, где искать нужные данные, и не ждет, пока у менеджера появится свободное время на объяснения.

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

Описанную систему постановки задач мы применили на двух крупных проектах. Метрики и примеры работ — в кейсах:

Где конвейерная модель не работает

Конвейер подходит для повторяемых, форматно однородных задач: ресайзов, баннеров, рассылок по единому брендбуку. Он проседает там, где каждая задача требует исследования, — например, при разработке айдентики или сложных цифровых продуктов.

Также модель не работает без встречного движения заказчика. Если компания не готова формализовать бриф и регламент, зафиксировать приоритеты — конвейер не соберется, сколько кастомных полей ни добавляй на доску. Отдельно важна оперативность: приемка задач и ответы на уточняющие вопросы должны приходить в разумные сроки, иначе макеты зависают на согласовании, не доходя до финального результата.

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