Как дизайнеру подготовить Figma-макет к разработке: чек-лист от СВОЙ Тех

Грязный макет — грязный код. СВОЙ Тех опубликовал спецификацию по подготовке Figma-макетов к передаче в разработку. Разбираем правила, которые избавят команду от вопросов «что тут имелось в виду» и ускорят релиз.

Дизайнер отдаёт макет, разработчик начинает задавать вопросы: «А какой тут отступ?», «А что будет при наведении?», «А где состояния кнопок?». Знакомая картина? Компания СВОЙ Тех решила покончить с этим и опубликовала спецификацию, в которой описала, в каком виде желательно отдавать макеты в разработку. Это не просто рекомендации — это аргументация для возврата макета, если он не соответствует базовой гигиене.

Почему чистый макет — это адекватный код

СВОЙ Тех, российская IT-компания, специализирующаяся на разработке цифровых продуктов, выпустила статью, в которой подробно описала требования к Figma-макетам. Основная идея проста: грязный макет — грязный код. Когда разработчик получает макет, в котором не проставлены отступы, не названы слои, не описаны состояния элементов, он вынужден тратить время на уточнения, догадки и переделки. В итоге страдает и скорость, и качество.

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

Предыстория и контекст

Проблема передачи макетов в разработку существует столько же, сколько существует веб-дизайн. С появлением Figma процесс стал удобнее, но не автоматически чистым. Многие команды до сих пор работают по принципу «скинул макет — и ладно», перекладывая ответственность на разработчика. Это приводит к бесконечным уточнениям в мессенджерах, переделкам и, как следствие, к срыву сроков.

СВОЙ Тех, судя по публикации, столкнулась с этой проблемой в своей практике и решила систематизировать требования. Это не первый случай, когда компании публикуют подобные гайды — например, известны аналогичные регламенты от крупных студий и продуктовых команд. Но спецификация СВОЙ Тех интересна тем, что она написана с точки зрения разработчика, который устал от неоднозначностей, и предлагает конкретный чек-лист.

Что именно требует спецификация

Спецификация охватывает ключевые аспекты: структуру слоёв, называние элементов, размеры и отступы, типографику, цвета, состояния элементов (hover, active, disabled), адаптивность и даже поведение при ошибках. Например, рекомендуется называть слои осмысленно, а не «Frame 123», группировать элементы по смыслу, использовать авто-лейауты и констрейнты, чтобы макет был адаптивным. Также важно указывать все состояния кнопок и ссылок, чтобы разработчику не приходилось выдумывать их самостоятельно.

Особое внимание уделено деталям: тени, скругления, градиенты, иконки — всё должно быть описано или вынесено в отдельные компоненты. Иначе разработчик будет тратить время на «реверс-инжиниринг» макета, что противоречит принципу быстрой разработки.

Как устроена гигиена макета: технические подробности

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

Во-вторых, типографика. Должны быть заданы шрифты, размеры, межстрочные интервалы, отступы. Лучше использовать текстовые стили Figma, чтобы разработчик мог легко выгрузить их в код. В-третьих, цвета. Все цвета должны быть вынесены в палитру с понятными названиями, а не разбросаны по макету. Это особенно важно для поддержки тёмной темы и брендинга.

В-четвёртых, состояния. Для каждого интерактивного элемента (кнопки, ссылки, поля ввода) должны быть представлены все состояния: обычное, при наведении, при нажатии, неактивное. В Figma это делается через варианты компонентов. Если этого нет, разработчик вынужден либо спрашивать, либо придумывать сам — а это риск получить не тот результат.

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

Кого затронет и как

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

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

Что будет дальше

СВОЙ Тех, судя по публикации, намерена внедрить эти правила в свои процессы и, возможно, ожидает, что другие компании последуют примеру. Пока это разовая публикация, но такие гайды часто становятся основой для внутренних регламентов и даже публичных стандартов индустрии. Уже сейчас можно ожидать, что статья будет активно обсуждаться в профессиональных сообществах, и, возможно, появятся аналогичные спецификации от других компаний.

Вероятно, в будущем Figma и другие инструменты будут предоставлять всё больше возможностей для автоматической проверки гигиены макета, но пока это ручная работа. Поэтому дизайнерам стоит взять на вооружение чек-лист из статьи и внедрить его в свой процесс уже сейчас.

Итог

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