Вступление

Статья является результатом моей лекции на Дизайн Коммуналке 2025. Спасибо всем организаторам за столь уникальный для Самары фест и возможность выступить на нём.

Ответственность за результат

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

Чтобы довести наши идеи к их полной реализации на проде, нам нужно понимать три вещи:

• Как проектируются наши идеи
• Как поставить техническое задание разработке
• Как донести техническое задание разработке

Пройдёмся по пунктам.

1. Как проектируются наши идеи

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

Лучше задать другой вопрос: какой из этих языков легче понять?

Я думаю, что код.

Язык абстракции субъективен. Он формируется за счёт тенденций и насмотренности, двух абсолютно хаотичных и неподдающимся систематизации факторов.

Язык кода, в отличие от абстракций, объективен. Он имеет чёткую систему, набор инструментов, а главное — явный список знаний, которые нужны, чтобы его использовать.

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

Изучая код, мы также узнаём и его ограничения. Как эффекты наложения влияют на производительность браузера, какие есть ограничения в базовых анимациях CSS, как работает адаптив. Эти и другие ограничения браузеров должны лежать в нашей голове с первых макетов.

Научиться языкам программирования можно в разных источниках. К примеру, есть прекрасный курс от Жени Арутюнова, дизайнера, который уже давно пропагандирует изучение кода коллегам. Я же учусь программированию в Purple School. Отличное место с системной подачей информации и углубленным изучением каждой темы.

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

• Эмиль Ковальски↗
• Джей Томкинс↗
• Jakub Krehel↗
• Рауно Фрайберг↗

2. Как поставить техническое задание разработке

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

Ниже ряд инструментов, которые мы используем при формировании технического задания, т.е. Фигма-файла, на проектах в Сирене:

• Работа с Pages — даёт возможность легко ориентироваться по ТЗ

• Дизайн-система проекта — позволяет перевести разработке элементы в код-компоненты и css-root-стили

• Экраны, расставленные в порядке User-flow — дают явное понимание проекта и возможные флоу и приоритезацию разработке

• Семантическое наименование экранов — в элементах используем только Figma Layout Autonaming

• Текстовое описание поведения элементов на экране

Отдельно отмечу последний пункт, который позволяет детальнее погрузить в макет и описать его интерактивную составляющую внутри статики Фигмы.

Первый случай использования: когда нужно описать динамично меняющийся контент. Пример:

В момент захода через спортсовскую авторизацию, даём рандомный ник юзеру и помещаем его в плашку. Там помещается +-23 символа с учётом пробелов.

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

В данных блоках мы также используем сторонние инструменты — Codepen↗, библиотеку уже анимированных кодом элементов, и Easing Graphs↗ , библиотеку изингов.

В нашей команде мы ввели чек-лист, по которому мы перепроверяем макет на наличие основных моментов.

3. Как донести техническое задание разработке

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

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

Заключение

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