Маркетолог отдает бриф на баннер, получает макет — и комментирует, что «это не мы». Не та подача, не тот тон, цвета вроде бы из палитры, но макет всё равно визуально отличается. Заказчик делает вывод, что агентство не понимает бренд. Но чаще всего проблема в брифе и базе знаний: нет важных составляющих, без которых дизайнер физически не может угадать стиль. Наша компания работает с крупными брендами, оказывая услуги дизайн-поддержки, и в этой статье мы расскажем, как избегаем такой ситуации. В тексте обобщили опыт команды и собрали наши кейсы, чтобы всё показать на примерах.
Когда у клиента нет формализованной базы знаний бренда, дизайнер агентства восстанавливает гайдлайны по обрывкам: старым ТЗ и макетам; референсам из переписки. Часть деталей в таком процессе теряется, просто потому, что сам клиент считает их очевидными и не фиксирует.
Ещё одна проблема — бриф. Нередко он описывает, что нужно сделать, но не указывает, по каким критериям задачу примут. В результате правки всплывают на финальной стадии, когда макет уже готов, и исправить их на этом этапе значительно дороже, чем в процессе работы.
Эффект масштабируется с нагрузкой. Если дизайн-команда закрывает десятки макетов и ресайзов в неделю, любой пробел в методологии проявляется быстрее; одна ошибка в трактовке стиля повторяется во всем потоке задач, а не остается единичным случаем.
База знаний бренда — это не только цвета, шрифты и сетки. Это еще и образцы (референсы), а также контекстные правила: какие форматы коммуникации недопустимы, какие визуалы считаются слишком смелыми, а какие, наоборот, стандарт для бренда.
Понятная логика расположения материалов внутри базы данных очень важна: дизайнер на стороне исполнителя должен быстро находить всё нужное. Мы советуем структуру базы строить не по типам активов (логотипы, шрифты, иконки отдельными разделами), а по сценариям использования. Например, баннеры для соцсетей — пример конкретного и часто применяемого сценария. А значит, и референсы, и макеты, и шрифты для них должны храниться в одном разделе. Такой подход сокращает подготовку на старте каждой новой задачи, потому что дизайнер сразу видит контекст, а не собирает его, задавая уточняющие вопросы.
База работает только если это живой и постоянно пополняющийся банк примеров, а не статичный документ, который открыли один раз при онбординге. Поэтому логично организовать её в виде хранилища файлов, разложенных по папкам и разделам; дать возможность сортировки по дате добавления и назначить ответственных, которые будут добавлять в хранилище все новые проекты. Не бойтесь больших объемов: если структура понятна, дизайнер сам найдёт нужные материалы.
Так, в нашем сотрудничестве с «Купером» мы создавали товарные и фуд-иллюстрации с помощью нейросетей, и это потребовало большой базы изображений: чем больше референсов, тем точнее ИИ «попадает в стиль». Мы использовали для генерации и доработки несколько моделей, включая Nano Banana, Krea, Midjourney. От дизайнера требовалась оценка иллюстраций, которую тоже нельзя корректно сделать без «насмотренности» — глубокого погружения в материалы, собранные заказчиком. И, конечно, мы внимательно дорабатывали и корректировали каждый макет вручную. Что получилось, показали в описании кейса.
Ответственный за базу знаний на стороне клиента — не дизайнер и не арт-директор агентства, а маркетолог или бренд-менеджер, то есть эксперт, хорошо знакомый со стилем бренда. Его задача продумать структуру и регулярно дополнять базу новыми материалами, при этом удаляя то, что уже не актуально.
Чек-лист приемки переводит субъективную оценку «не похоже на нас» в проверяемые пункты: соответствие цветовой палитре, типографике, тону коммуникации (Tone of Voice), формату для конкретного канала. Без всего этого дискуссия о стиле переходит в область личного вкуса и ощущений каждого участника процесса, а о вкусах, как мы знаем, не спорят.
Без формализованного чек-листа количество итераций на задачу растет непредсказуемо: где-то хватает одной правки, где-то макет переделывают пять раз, и заранее не угадать, какой случай выпадет. Выстроенный процесс с понятными чек-листами выглядит совсем иначе: так, работая над иллюстрациями для «Купера», мы сократили среднее количество правок до 0–1 на задачу, при этом 90% задач закрывались за 1–2 рабочих дня.
Чек-лист должен быть готов до передачи задачи в работу, а не после получения макета, чтобы дизайнер мог с самого начала учитывать все важные критерии. Если они формулируются постфактум, то такой чек-лист будет не помощником и навигатором для дизайнера, а лишь инструментом для критики результата.
Процесс должен включать промежуточный этап ревью у арт-директора до того, как макет попадет на приемку клиенту, а также этап внесения правок и финальное ревью. Это распределяет ответственность за соответствие гайдлайну между агентством и клиентом — иначе клиент остается единственным фильтром качества.
Стандартный шаблон Jira (и большинства других таск-трекеров) для разработки не подходит для дизайн-задач. Нужны поля, которых там по умолчанию нет: ссылка на актуальную версию гайдлайна, чек-лист приемки прямо в карточке задачи, статус ревью арт-директора как отдельный этап рабочего процесса.
Мы разработали и проверили в деле удобный порядок постановки и выполнения задач, работая над кейсом «Мегамаркета»: созданная нами цепочка позволила отгружать 400+ ресайзов в день и держать срок выполнения до 2 рабочих дней. О том, как это удалось, рассказали в описании кейса.
Выстроенная структура процесса дает еще один эффект — взаимозаменяемость дизайнеров. Новый исполнитель онбордится за 1–2 дня, потому что вся информация о стиле бренда зафиксирована в карточке задачи и в базе знаний, а не в переписке и не в голове конкретного человека.
Чек-лист и база знаний фиксируют правила на момент создания. Но стиль бренда меняется: появляются новые форматы, новые каналы и обновления в продуктах. Могут возникнуть и внешние факторы, которые влияют на позиционирование. Без регулярной ретроспективы (раз в 2–4 недели) все эти расхождения между зафиксированными правилами и реальной практикой накапливаются незаметно, а потом проявляются массово, сразу в нескольких макетах.
На ретроспективе стоит разбирать не только явные отклонения от стиля. Важнее пограничные случаи — макеты, которые формально прошли чек-лист, но вызвали сомнение у кого-то из команды. Именно такие случаи становятся материалом для уточнения гайдлайна: чек-лист по определению не покрывает то, что еще не описано.
Ретроспектива должна быть не встречей для отчетности, а инструментом, который помогает снизить общее число правок через разбор спорных случаев, а также удачных и неудачных визуалов. В этом отличие «ретро» от чек-листа, который работает точечно, на уровне одной задачи.
Прежде чем передавать дизайн на аутсорс, на стороне клиента должны быть готовы четыре артефакта.
Без этих четырех пунктов любое агентство, даже с опытными дизайнерами, будет восстанавливать стиль бренда заново на каждой задаче. С ними онбординг занимает дни, а не месяцы, и количество правок заметно снижается.
Если внутри команды нет ресурса собрать базу знаний и выстроить процесс самостоятельно, дизайн-поддержка Uplab закрывает эту методологию вместе с командой дизайнеров: от настройки Jira и базы знаний до регулярных ретроспектив. Напишите нам через форму «Обсудить проект», и мы расскажем подробнее.
Комментарии к статье
Комментарии: 0