Работа дизайнера не заканчивается в Figma: что происходит до и после передачи макетов
Опубликовано: 10.08.2026
Существует стойкое заблуждение, что задача дизайнера — нарисовать красивые экраны, сгруппировать слои и отправить ссылку в чат разработчикам. На практике отрисовка макетов — лишь часть работы. Существенное время уходит на то, что происходит до неё и после неё: постановку задачи, сценарии, согласования, передачу и проверку реализации. И именно эти этапы определяют, будет ли продукт работать так, как задумывалось.
До первого прямоугольника
Прежде чем открывать Figma, дизайнер должен понять, для кого делается продукт и какую конкретную проблему решает. Без этого этапа макеты превращаются в декорацию — симпатичную, но бесполезную для бизнеса и пользователя.
Сбор контекста
Дизайнер изучает задачу: читает техническое задание, задаёт вопросы продакт-менеджеру, смотрит конкурентов. Цель — понять ограничения и возможности. Например, если продукт рассчитан в том числе на пожилых пользователей, это повод заранее проверить читаемость, контрастность, размеры интерактивных элементов и сложность навигации на реальных сценариях. Без этого знания можно потратить неделю на изящные микроанимации, которые потом придётся выбросить. Передача макета становится спокойнее, когда она встроена в общий рабочий цикл. В полном разборе можно проследить, как этапы от постановки задачи до релиза связаны между собой.
Структура до визуала
Следующий шаг — информационная архитектура и пользовательские сценарии. Дизайнер рисует флоу: какие экраны нужны, как пользователь перемещается между ними, где происходят ключевые действия. Часто это делается в виде схем на бумаге или в простых инструментах. Ошибка здесь — сразу прыгать к визуальному дизайну, не проверив логику. Проблему, найденную на этапе схемы, обычно исправить проще и дешевле, чем после вёрстки, когда изменение уже затрагивает работу нескольких специалистов.
Соглашения с разработчиками
До начала отрисовки имеет смысл свериться с командой разработки. Вопросы простые, но критичные: какая сетка используется на проекте, есть ли готовая UI-библиотека, какие ограничения по шрифтам, поддерживаются ли нужные анимации на целевых платформах. Дизайнер, который узнаёт о таких ограничениях после сдачи макетов, вынужден переделывать значительную часть работы.
Внутри Figma: не просто рисование
Сама работа в редакторе — это не чистое творчество, а конструирование с учётом того, что макет будет разобран на компоненты. Несколько практических принципов:
- Автолейауты вместо ручного позиционирования. Если элементы расставлены произвольно, верстальщику приходится угадывать намерения. Автолейаут явно показывает, как блок должен вести себя при изменении содержания.
- Единая типографика и отступы. Размеры шрифтов, высота строк и отступы стоит подчинять принятой в проекте системе. Если дизайн-система использует шаг 4 или 8 пикселей, важно соблюдать его последовательно, а не придумывать новые значения для каждого экрана. Это не прихоть, а условие для стабильной вёрстки.
- Состояния элементов. Кнопка в покое, при наведении, в нажатом состоянии, неактивная — всё это нужно отрисовать. Разработчик не будет додумывать, как выглядит неактивная кнопка.
- Стилевые переменные. Цвета, скругления, тени — через переменные, а не через произвольные значения в каждом элементе. Это упрощает поддержку и масштабирование.
Макет, подготовленный по этим правилам, читается разработчиком как технический документ. Макет без этих правил — как рукопись с почерком, который разгадывают по контексту.
Передача: момент, когда начинаются проблемы
Сдача макетов — это не событие, а процесс. Просто скинуть ссылку и написать «всё готово» — гарантия недопониманий.
Презентация макетов
Дизайнер проводит встречу с разработчиками и проходит по ключевым экранам. Объясняет не то, какого цвета кнопка, а логику: почему здесь именно такой паттерн, как работает форма при ошибке валидации, что происходит при пустом состоянии списка. Без такого разбора макетов разработчики вынуждены интерпретировать макет самостоятельно, и их интерпретация не всегда совпадает с замыслом.
Документирование неочевидного
Не всё можно выразить визуально. Поведение при длинных текстах, логика показа тултипов, порядок таба между полями — такие вещи требуют текстового пояснения. Где-то достаточно комментария прямо в Figma, где-то — отдельного документа с описанием взаимодействий.
После передачи: сопровождение
Когда разработчики берут макеты в работу, дизайнер не исчезает. Начинается этап, который часто недооценивают — дизайн-сопровождение разработки.
Ответы на вопросы
Вопросы почти неизбежно появятся по ходу разработки. «А что если текст не влезет в эту карточку?», «Какой отступ здесь — 12 или 16?», «Эта иконка из библиотеки или кастомная?». Чем быстрее команда снимает такие неопределённости, тем меньше риск накопить расхождения. Если дизайнер недоступен, разработчику приходится принимать часть решений самостоятельно, и позже их может потребоваться сверять с исходным замыслом.
Проверка вёрстки
Дизайнер смотрит реализованные экраны и сравнивает с макетом. При этом важен фильтр: не каждая разница — это баг. Пиксельное совпадение на разных экранах, браузерах и операционных системах не всегда достижимо и обычно не является самоцелью. Дизайнер, который требует идеального совпадения каждого пикселя, тормозит процесс и теряет доверие команды. Критерии проверки должны быть практичными: сохранена ли логика, читаем ли текст, корректны ли отступы в пределах допустимой погрешности, работают ли состояния и анимации.
Корректировки по результатам реализации
Иногда в процессе вёрстки выясняется, что задуманное решение не работает так, как ожидалось. Анимация тормозит на слабых устройствах, определённый паттерн не поддерживается платформой, или просто в живом виде взаимодействие ощущается иначе, чем на статичном макете. Дизайнер должен быть готов оперативно предложить альтернативу, а не защищать изначальное решение ради принципа.
Типичные ошибки, которые удорожают проект
| Ошибка | Последствие |
|---|---|
| Начать рисовать без понимания задачи | Переделка макетов после получения обратной связи от стейкхолдеров |
| Не согласовать ограничения с разработчиками заранее | Макеты, которые невозможно или слишком дорого реализовать |
| Отрисовать только идеальное состояние | Разработчик импровизирует на пустых состояниях, ошибках, лоадерах |
| Передать макеты без совместного разбора | Недопонимание логики, множественные итерации правок вёрстки |
| Исчезнуть после передачи | Задержки из-за неотвеченных вопросов, отклонения от замысла |
| Требовать пиксель-перфект на всех устройствах | Потеря доверия команды, искусственное замедление разработки |
Чем заканчивается работа дизайнера
Формально — приёмкой реализованного интерфейса. Практически — когда продукт выходит к пользователям и начинает собирать обратную связь. Дизайнер анализирует, как люди реально используют то, что было спроектировано: где путаются, где нажимают не туда, где ожидания не совпали с реальностью. Эти наблюдения становятся входными данными для следующего цикла — и всё начинается снова.
Зрелая дизайнерская практика — это не только умение собирать сильные экраны, но и способность видеть процесс целиком: от понимания задачи до проверки того, как решение живёт в реальном продукте. Figma в этом процессе — инструмент, а не предел.
