Дизайнеру никто не скажет, ведь не критично, но неприятно.
Привет, Хабр! Бывало ли у вас так: дизайнер выкатывает потрясающий, концептуальный, невероятно эстетичный интерфейс и все там внутри хорошо. НО… После переноса его в код разработчик начинает испытывать душевный дискомфорт, любые последующие касания с макетом нарушают тонкое ментальное равновесие и запускают избегающее поведение? И вроде как ИИ может помочь, но по грязному макету выходит грязный код. Верстальщику неприятно чистить это.
Если взять грязный и чистый макеты одного и того же скрина — прогнать через Claude Design с одним и тем же промптом (чистый HTML, CSS по BEM, JavaScript без библиотек, без сокращений в названиях классов, функций, переменных; переключение состояний классами, а не инлайн‑стилями), который закрывает фронтовой минимум, то получим следующее: код с грязного макета — это кромешный ад для разраба, чертыхания и стрелы проклятий в дизайнера. ИИ распарсил, многое интерпретировал — дальше либо домысливать самому в спорных кейсах, либо идти к дизайнеру, куча вопросов. Каждый <div> — спотыкание на ровном месте: что там имелось в виду и как точно это должно работать. Код со второго макета, который собран по описанным в статье правилам, — это адекватный код, он структурирован, понятен для разработки и ИИ. На сгенерерированной странице верстальщик видит, как это должно работать, есть однозначное понимание логики и всей специфики макета — это огромная (ну нормальная) помощь для всего фронта.
Внедрение этих правил и подсказок сильно сократило количество обращений разработки с уточняющими вопросами. Если ориентироваться на треки в Jira, да и просто по ощущениям — подобные коммуникации практически исчезли.
Дальше требования и советы по макету для дизайнера. Фронт и QA читают как чек‑лист. Это база знаний для них: понятно, как должно быть, а что считать багом.
➀ Архитектура и структура макета
1.1 — Auto Layout* — гайд от Figma
* Фрейм, в основе механики которого лежат принципы, аналогичные CSS Flexbox и CSS Grid в веб‑разработке.
Забываем про хаотично раскиданные элементы. Все, абсолютно все, должно быть обернуто в Auto Layout (Shift+A). Допускается абсолютное позиционирование отдельных элементов, только если это оправдано дизайном и без этого, ну никак… Например, фоновое изображение/видео логического блока. Auto Layout — не эстетство, а способ передать разработчику отступы и поведение без слов.
1.2 — Frame* — гайд
* Холст/артборд — аналог тега <div>
Фреймы без Auto Layout используем в крайних случаях. При этом фрейм должен быть правильно назван, спозиционирован и обладать предсказуемым и описанным в сопроводительной документации поведением.
1.3 — Groups* (Cmd/Ctrl+G) — забыть в контексте архитектуры и структуры макета
* Способ объединить несколько слоев или объектов вместе, чтобы перемещать, масштабировать и трансформировать их как единое целое, но это никак не самостоятельный юнит для верстки. Это пассивная обертка.
Для черновика, иллюстраций, логотипов — на здоровье.
В макете, который уходит разработке, группа — черный ящик: у нее нет паддингов, нет Hug/Fill, и при растяжении она ведет себя как захочет, внутри нее происходит непредсказуемое. Нужно что‑то подобное и никак иначе? Оборачиваем в Auto Layout и/или Frame и обязательно выносим отдельно для экспорта.
1.4 — Layout guides* — гайд
* Система координат, помогает визуализировать структуру макета
Используем сетки строго как направляющие на уровне страницы/контейнера. Позиционировать отдельные элементы вручную — табу, такой макет сложно/долго редактировать/масштабировать.
1.5 — Строгая вложенность
Собираем элементы логически. Визуальная иерархия макета должна на 100% совпадать со структурой слоев. Разработчики (и тем более ИИ) считывают макет последовательно, сверху вниз, как дерево объектов. Если структура слоев нарушена, верстка «поплывет».
1.6 — Гигиена сама по себе
Все пустые фреймы, неиспользуемые элементы и скрытый «на всякий случай» мусор — должны удаляться без сожалений. Никто, кроме вас, не должен о них знать.
➁ Нейминг и семантика
В названиях слоев и компонентов должны быть, прежде всего, логика плюс тотальное единообразие.
2.1 — Функция прежде всего
Название слоев строго по их функции: Header, ButtonPrimary, CardArticle, InputEmail. Разработчик не должен гадать, что находится внутри. Варианты Frame 112, Rectangle 4, Group 14 — в топку.
2.2 — PascalCase
Главное — единообразие с принятым в команде стеком, а не сам выбор регистра. В СВОЙ Тех предпочтение отдали стилю PascalCase (например, UserFirstName, CalculatorContainer) непосредственно в названиях слоев. Почему? Потому что Педро Паскаль — хороший актер, и он точно симпатичнее верблюда (camelCase). А еще разработка сказала: «Нам так удобнее».
На этом и договорились. Главное — не смешивать Педро с верблюдом в одном проекте и чтобы имена слоев в макете совпадали с именами компонентов в коде. UserFirstName в макете совпадает с UserFirstName в коде — это договоренность. ИИ по осмысленному дереву генерит осмысленный код — по Frame 112 он генерит Frame 112.
➂ Графика, экспорт
3.1 — Vector/image
Иконки, логотипы должны быть помещены в отдельный фрейм с системным названием (Icon, Img, BG).
3.2 — Сохраняем исходники
Если флатим вектор (Outline stroke + Flatten), то обязательно оставляем редактируемый оригинал в мастер‑компоненте на отдельной странице для коллег.
3.3 — Эффекты
Заводим свойства эффектов в переменные и не злоупотребляем. Все новое и прекрасное обсуждаем сначала с разработкой — готовы ли они это реализовывать и дадут ли им на это квоту.
3.4 — Унификация изображений
Все картинки для одного компонента должны быть одинаковыми: идентичный размер, позиционирование и поведение (Fill/Crop).
3.5 — Отдельный фрейм для экспорта
Разработчик не должен искать нужный слой среди десятков других. Выносим все, что пойдет на экспорт, на отдельный фрейм.
➃ Спецификация
4.1 — Есть макет — есть спека
Появилось что‑то новое — пишем спецификацию/аннотацию и описываем поведение, плюс генерим то, как оно должно быть, чтобы разработка не придумывала и не ходила спрашивать: «А как…?».
4.2 — Кейсы
Закрываем все кейсы: показываем, как ведет себя макет во всех «положениях» — будь то Hero Headline из 300 символов (и такое может быть), ошибка загрузки, состояние пустой страницы, в общем все, что может случиться на проде — все есть в макете и все знают, где оно сидит/стоит/лежит/не прячется. Избегаем Lorem ipsum. Не дали контент — генерим через ИИ от Figma или накидываем самостоятельно.
4.3 — Есть компонент — есть спека
Сопровождаем компоненты описанием внутри него самого — это лучшая инструкция для ИИ, разработчика и других дизайнеров вашей команды.
➄ Текст и типографика
Это сильно бесячая тревожная история для всех, мы намеренно свели количество допустимых значений к минимуму — остальное обсуждаем.
5.1 — Правила текстовой гигиены:
5.1.1 — Text styles ONLY
Есть стиль. Нужен другой вес или размер? Создаем новый системный стиль. Проект с 10–20 стилями — будет отлично, увеличение количества стилей — должно быть обосновано.
5.1.2 — Letter Spacing
Желательно 3 значения на весь проект. Используем проценты (%). Значения в процентах из Figma конвертируются в CSS напрямую: -2% в Figma = -0.02 em в CSS.
Для крупных заголовков — отрицательные значения, для мелкого текста — положительные. Базовый текст — 0%. Пример рабочей триады: 0%, -1%, 1%.
5.1.3 — Line Height
Забываем про значение Auto! Идеальное соотношение высоты строки к размеру текста: 1.2–1.5. Если используем точные пиксели (px), то без дробей (например, 24px, 32px).
Но лучшая практика — проценты (%) (например, 150%, 120%). Это прямая совместимость с кодом, экономия переменных в дизайн‑системе, проценты адаптивны и предсказуемы при изменении размера текста.
По‑хорошему не более 2–3 процентных значений высоты на все стили.
5.1.4 — Paragraph spacing
Никаких двойных нажатий Enter для создания отступа между абзацами. Используем Paragraph spacing — заводим в переменные и пишем в спеке, чтобы все знали. Либо разносим по контейнерам с Auto Layout + gap.
5.2 — Контентные правила:
5.2.1 — Перенос строки через Enter
Не переносим текст на конкретной ширине кнопкой Enter “чтобы было красиво” — это прям боль… Потому всегда проверяем, сидит перенос строки в текстовом блоке или все хорошо.
5.2.2 — Неразрывные пробелы и дефисы — база
Не оставляем «сирот» и висячих предлогов в конце строк. С помощью непереносимых пробелов и дефисов настраиваем логичные переносы там, где разрыв строки может убить смысл фразы при адаптиве. Тыкаем аналитиков, тестировщиков и разработку, чтобы те в свою очередь тоже сохраняли бдительность…
5.2.3 — Текст = текст
Никогда не конвертируем шрифт в векторные кривые (Outline), если только это не уникальный логотип или что‑то такое, что можно уже назвать векторным изображением, на котором изображены буквы.
5.2.4 — Единый текст (содержание) на все разрешения
Текст один на все разрешения. Если на мобилке нужна короткая версия — это не «чтобы влезло», а контентное правило с описанием обоих вариантов в спеке.
5.2.5 — Ручные оверрайды
Допускаем изменение веса, цвета или «декораций» внутри одного текстового блока, но задаем эти изменения строго через стили.
5.2.6 — Склейка сущностей
Цифры и валюты пишем неразрывной сущностью (24 000 ₽).
➅ Компоненты, переменные
Базовая база, но проговариваем
6.1 — Нет сырым HEX‑кодам!
Никаких вручную выставленных цветов (привет, #FF0000), свойств шрифтов или теней.
6.2 — Styles/Variables
Абсолютно все должно быть привязано к системным Styles и/или Variables. Используем Variables — настраиваем Modes для удобного переключения тем (например, Dark/Light).
Все, что может быть завязано на переменных, завязываем. Это мощнейший колоссальный инструмент для упрощения, стандартизации, масштабирования. Для разработки это гарантия, что макет в бо́льшей своей части будет строгой типизированной технической спецификацией, которая полностью избавляет от неопределенности. Для ИИ это инструкция, правила, которые с большой вероятностью он будет соблюдать.
6.3 — Component и Variants
Если элемент используется в макетах более одного раза — это Component. Настраиваем все состояния (Focus, Hover и так далее) и вариации (Neutral, Positive и так далее) внутри одного компонента/сета.
6.4 — Booleans
Настраиваем видимость элементов внутри компонентов через логические переменные (Boolean).
➆ Адаптивность
7.1 — Любой макет должен тянуться
Забываем про Fixed width. Для веба макеты должны покрывать все ширины (Desktop, Tablet, Mobile) — не забываем про экстремальные ширины, поведение элементов адекватное, адаптивное и логичное. По приложениям помним про планшеты — среди Android уже есть раскладушки. У Apple — вопрос времени. И макет должен вести себя корректно везде.
7.2 — Тест на растяжение
Разработчик должен иметь возможность скопировать макет и потянуть за край фрейма, чтобы увидеть, как ведут себя элементы.
7.3 — Min /Max Width & Height
Где необходимо, обязательно настраиваем эти величины, чтобы интерфейс не ломался, например карточка продукта с изображением не должна быть меньше заданной ширины, чтобы изображение выглядело адекватно, а сопроводительный текст не превращался в нечто нечитаемое.
7.4 — Auto Layout/Frame
Уделяем время поведению при изменении ширины экрана (Hug, Fill, фиксация отступов).
Устраиваем краш‑тест!
Тянем
репкумакет
Текст переносится на новые строки, а не обрезается?
Карточки складываются в колонку?
Отступы не ломаются/согласуются?
Логические блоки влезают в один экран?
На любой ширине ваш макет ведет себя адекватно?
Учтены моменты, когда ширина экрана может быть более 1920 и до бесконечности?
Есть фавиконки, Open Graph Image, 404, меню, модалки, сеты иконок, все возможные кейсы, в общем все, что относится и применяется к вашему макету?
Написано сопроводительное, если есть нюансы по макету, поведению, отображению, анимации и так далее?
Контраст текста проходит (4.5:1 — основной текст, 3:1 — крупный)?
Тач‑таргеты соответствуют норме вашей платформы (iOS HIG — 44×44 pt, Material — 48×48 dp, WCAG 2.2 — минимум 24×24 CSS px)?
Вам нравится, как это выглядит?
Если ответ «Да» –
вы готовы, макет готов. Лиду не будет стыдно перед разработкой. Вам — перед лидом. Он не будет тратить время на ревью элементарного.
Как внедряли
Мы не изобретали велосипед — просто добавили в процесс точку, где разработка может аргументированно и по пунктам отправить макет обратно на доработку, а дизайнер обосновать, почему задача делается не сию минуту.
Право развернуть
Ключевое — право разработки вернуть макет теперь опирается на документ. Один прогон через ИИ вкупе с этими правилами плюс краш‑тест — и все понятно. Ребята сами смотрят: косяки существенные или можно все же забрать. Спорное мелкое — сходить в личку к дизайнеру, перетереть. Но всегда есть аргументация, ведь фронты потратят существенно больше времени, чем дизайнер. Да, это тема для спекуляции, саботажа, но ревью на груминге закрывает это окно возможностей.
Право на время
Дизайнер же в свою очередь теперь обладает доводами, почему макеты не готовы вчера. Горящие задачи есть всегда, без этого никак — тут спасают уже существующие дизайн‑системы с чистыми компонентами, которые по определению прошли проверку, и ими достаточно легко и быстро жонглировать. Для дизайнера сборка макета — уже мелкая моторика: пара кликов мышкой. Часто — считаные минуты. Руками собрать быстрее, чем писать промпт, тем более ждать, пока оно все нагенерится и сожрет кучу токенов, ну только если нет цели погрызть печеньки, попить кофе, пожечь токены (нравиця як воно горить). Появилось в разы больше времени на действительно важное. Именно в рамках жестких дедлайнов этот принцип и спасает.
Вери ургант асап хот таски — что делаем
Иногда бывает, что у всех все горит и пылает ярким пламенем, сделаем сейчас на коленке — потом допилим, но это «допилим» потом лежит, пылится и любое касание — это страдания дизайнеров, фронта, QA, BA и других. И, конечно же, допиливать нет моральных сил, а чаще времени, потому что — новые задачи, новые горизонты. Потому если что‑то новое и срочное — договариваемся между собой, ведь в итоге это будет либо общая заслуга, либо общая боль. Бизнес принял эту арифметику и особо не кошмарит. Где‑то выделяется сразу адекватное время на макеты, где‑то договариваемся, что одновременно пилят покомпонентно и дизайнеры, и фронт с прогонами на соответствие. Иногда на бэклоге — дизайнер доделывает, ориентируясь уже на то, что и как реализовано на проде (ну а что делать?!).
Было тяжело начать — начать чистить за собой макет, ведь привыкли отдавать быстрее, мол, фронты разгребутся, не в первый и не в последний раз. Теперь же нужно сконцентрироваться, поиграться с макетом, потягать, найти косяки, а потом их еще поправить. Да, дизайнеры стали тратить больше времени на настройку и описание, но исчезли возвраты и коммуникации про «а что тут имелось в виду». Внутри Figma есть масса инструментов для организации чистоты — один агент чего стоит, да пока это бетка и никто не знает, что будет потом. Но и без агента никто не убирал ИИ‑тулы, которыми можно закрыть почти все проблемы. Идет в оборот все, что удобно и что закрывает «надобности» дизайнера, например Design Lint, Clean Document, органайзеры стилей, переменных, дизайн‑систем. В итоге: то на то выходит по времени, но качество несопоставимо выше, лучше, быстрее.
В зависимости от объема и запущенности проекта процесс организации чистоты занимал/занимает где‑то пару часов, а где‑то пару месяцев, но если сделал — потом снимаешь сливки. Начиная работу над чем‑то новым, уже стартуешь с пониманием: потратив время сейчас — получишь в уже следующей итерации экономию времени, унификацию, масштабирование и ощутимо лучшее качество всего того, что отдаешь на фронт.
Грязный макет может уйти дальше, разработчик заберет и даже группу заверстает, но это не значит, что так и должно быть. Чистый макет — уважение.
Времени разработчика на каждое «а что тут имелось в виду» — жалко. За чистый макет — разработка будет готова целовать вас в уста.
