Привет! Меня зовут Алексей Песоцкий, я фронтенд-тимлид в AGIMA. Противостояние дизайнеров и разработчиков носит уже почти легендарный характер. Этой теме посвящены десятки статей, видосов и докладов. А отношения отделов ставят в один ряд с другими фундаментальными конфликтами: кошки и собаки, кому дует и кому душно, Хельга и Арнольд. Но мы в компании уверены: чтобы лучше понимать друг друга, нужно просто следовать элементарным правилам.
Я провел небольшой аудит статей по теме, понаблюдал, как эта коммуникация устроена у нас — и решил напомнить всем, почему для дружбы фронтендера и дизайнера нет никаких препятствий.
Корни «конфликта»
А начну с того, что никакого серьезного конфликта между фронтенд-разработчиками и дизайнерами на самом деле нет и быть не может. Мы все отличные ребята, которым зачастую легко общаться друг с другом вне работы. Но вот внутри производственного процесса некоторое недопонимание случаться может.
Его причины лежат в разнице подходов и целей. Если задача дизайнера — сделать удобный и красивый интерфейс, то задача фронта — сделать этот интерфейс производительным. А все вместе мы хотим сделать классный продукт и улучшить пользовательский опыт.
Объясню на примере. Бывает, что дизайнеры хотят какую-то красивую анимацию на главной странице, которая не будет работать в мобильной версии или на которую у отдела фронтенда банально нет времени — сроки в заказной разработке всегда горят. Тогда мы говорим: «Нет, ребят, это мы сделать, к сожалению, не сможем». И с этого момента начинаются торги: мы просим коллег найти другое визуальное решение, а они просят нас реализовать имеющееся.
Другими словами, главная причина любых пробуксовок в коммуникации между фронтендом и дизайном — в отсутствии общения и слаженности. А выход из любого тупика, как известно, там же, где и вход. Поэтому предлагаю настроить некоторые процессы, которые позволят это общение и слаженность вернуть.
1) Начинаем больше общаться. Буквально
Если не хватает общения, то самое ясное и явное решение — начать общаться больше и интенсивнее. Для этого можно внедрять любые доступные механики, но самые базовые и самые очевидные такие:
Кросс-функциональные встречи — например, дизайн-ревью с участием разработчика. Если подключать фронтендера на этапе разработки прототипа, он сразу сможет подсказать, что будет сделать легко, а что проблематично. Единое информационное поле — всегда хорошая идея.
«Дежурные» по взаимодействию. Слово «дежурный» выбрано произвольно, но суть такая: нужны ответственные люди от разработки и от дизайна, которые будут время от времени срезаться и сверять часы — всё ли по плану, какие вопросы есть между командами.
Добавлю по второму пункту. Да, в большинстве компаний за такое общение отвечает проджект-менеджер, но рано или поздно это превращается в сломанный телефон. Поэтому лучше, если, например, арт-директор и тимлид могут обсудить текущие вопросы лично.
Необходимость такого решения я то и дело замечаю на работе: разработчики приходят ко мне с вопросами, ответить на которые могут только дизайнеры. И когда в календаре есть встреча для подобных уточнений — мне не приходится фантазировать. Я просто выясняю всё у арт-директора.
Кроме того, на таких встречах проще актуализировать статус макетов. Часто дизайн работает в нескольких файлах: один рабочий, другой клиентский. И изменения между этими версиями не всегда своевременно обновляются. Уточнить всегда можно на синке — чтобы не верстать лишнего.
2) Следим за актуальностью UI-кита
Чтобы всем было удобно работать, в макете должен быть UI-кит. Разработчик сразу будет видеть, какие шрифты и UI-элементы возникнут в проекте. И конечно, важно, чтобы макет соответствовал UI-киту на каждом этапе. Его нужно оперативно обновлять и давать об этом знать отделу фронтенда.
В продуктовых командах, которые развивают продукт годами, лучше использовать плагины для Figma, которые позволяют синхронизировать компоненты с кодом. Если говорить проще, то таким образом можно создать собственную, уже запрограммированную версию UI-кита — удобно.
В заказной разработке на такие штуки, как правило, не хватает времени. Но если бы хватало, было бы круто. Благодаря этой функции UI-киты и все макеты можно поддерживать в актуальном состоянии всегда. Это сокращает риск ошибок, переделок и необходимых встреч.
Еще здорово, когда правила использования UI-элементов задокументированы для обеих команд. Нам важно видеть не только дизайн кнопки, но и примеры ее использования. Это позволяет разработке внедрять полу-автоматические правила в коде, чтобы, скажем, заголовки сразу были в нужных стилях.
Бонус. Лучше использовать тесты для проверки соответствия верстки дизайн-гайдлайнам. Например, скриншот-тестирование, которое всегда покажет, если что-то в сверстанной странице не соответствует макету. Это полезно и нам, и дизайнерам, которые участвуют в приемке фронта, и тестировщикам.
3) Вводим стройный процесс. На всех уровнях
Тут вариантов может быть несколько:
Настраиваем взаимное ревью. Скажем, когда страница готова, дизайнер может ее провалидировать на предмет соответствия гайдлайнам и макетам. Но и когда дизайн готов, разработчик тоже может его оценить по своим критериям: озвучить сомнения относительно каких-то элементов, задать вопросы, если не понимает, как должны работать отдельные решения.
Внедряем чек-листы. Макет не может быть передан дальше, пока не отрисованы все состояния и разрешения. Мы, например, для начала внедрили подобные чек-листы по самым базовым разрешениям, чтобы разработчикам не приходилось самим придумывать, как будет выглядеть дизайн на разных устройствах.
Проводим ретроспективы по итогам проектов. Команды фронтенда и дизайна вместе отслеживают, в каких моментах сотрудничество состоялось, а в каких были сложности. Повторяющиеся ошибки обсуждаем и вносим в те же самые чек-листы, чтобы впредь быть внимательнее.
Кроме того, для некоторых проектов актуально создание глоссариев, чтобы все команды называли элементы одинаково. В продукте это, как правило, фиксируется в базе знаний. Скажем, все договариваются, что спиннер — это колесо загрузки, как на YouTube. А лоадер — это полоса загрузки, как при скачивании файлов. На некоторых еком-проектах важно закрепить разницу между каталогом и разводящей страницей. И вообще чем больше UI-элементов, тем выше потребность в глоссарии.
Также на этапе планирования спринта стоит оценивать стоимость реализации каждого решения. Даже если фронтенд может его реализовать, это еще не значит, что успеет. Иногда нам приходится двигаться итерационно: для MVP мы подбираем более простое решение, в том числе визуально. А позже внедряем всё то, о чем договаривались с дизайном.
4) Ищем компромиссы всегда и во всем
Мне кажется, важно, чтобы обе команда понимали: между идеалом и реальностью есть небольшой зазор. Любой проект можно сделать очень хорошо, но всегда найдутся те, кто скажет: «Это не идеально». Поэтому иногда каждая из сторон должна идти на уступки, без этого сделать классный сайт и уложиться в срок почти не реально.
Недавно наш дизайн придумал для одного из заказчиков очень классную анимацию. На экране должна была появляться капелька, которая бы реагировала на мышь. Выглядело это очень реалистично и красиво. Но это решение начало тормозить на слабых устройствах. Капельку пришлось убирать. В итоге получилось тоже симпатично, но уже без капельки, в которую влюбились все. Мораль: да, иногда красотой приходится поступаться ради производительности.
На мой взгляд, в большинстве случаев пойти на компромисс проще дизайнерам. Но только потому, что возможности разработки ограничены техникой. На нас влияет быстродействие устройств, скорость загрузки страниц. Некоторые аспекты важны для SEO, потому что для поисковиков важно, чтобы сайт грузился быстро.
>> Если вы дизайнер, напишите в комментариях: как вы думаете, кому проще пойти на компромисс?
Но в целом важно внедрять в компании культуру взаимного уважения. Чем шире и глубже диалог между фронтендом и дизайном, тем меньше спорных тем. Мы всегда готовы пойти навстречу и попробовать сделать то, что на первый взгляд сделать невозможно. А коллеги-дизайнеры всегда внимательны к нашим ограничениям. Если в коммуникации на первом месте стоит желание помочь и поддержать — консенсус точно найдется.
Делитесь своим мнением о том, как должны взаимодействовать фронтенд и дизайн. Что вам помогает? Что мешает? Какие процессы есть в вашей компании? Готов ответить на вопросы и комментарии. Также можем обсудить статью в нашем телеграм-канале для тимлидов.