Контакт

Передача дизайна в разработку: от макета до кода без потерь

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

Дизайн-системы Обновлено

Коротко

Передача в разработку — момент, когда макет становится кодом, и именно здесь происходит большая часть потерь между дизайном и разработкой. Хорошая передача — это не ссылка на файл со словами «там всё есть», а токены в репозитории с теми же именами, что в макете, компоненты со всеми состояниями, раскладки для трёх ширин, крайние случаи — длинные заголовки, пустые списки, ошибки — и короткая спецификация на каждый компонент. Тогда разработчик не гадает, дизайнер не находит на сайте «почти то же самое», а новые страницы собираются из частей, которые уже есть с обеих сторон.

Путь одного решения: от макета до страницы

Когда эта цепочка работает, цвет, изменённый в макете, попадает на сайт через сборку, а не через письмо.

  1. 01Макетпеременные Figma
  2. 02Токеныtokens.json в репозитории
  3. 03СборкаStyle Dictionary
  4. 04CSSпеременные и темы
  5. 05Компонентыкод со всеми состояниями
  6. 06Страницасобрана из компонентов

Что входит в полную передачу

Десять вещей, которые нужны разработчику помимо картинки главного экрана.

ЧтоВ каком видеБез этого
Токены JSON-файл с теми же именами, что в макете цвета переписывают на глаз
Компоненты библиотека с вариантами и всеми состояниями наведение и фокус придумывают
Три ширины телефон, планшет, десктоп телефон собирают наугад
Крайние случаи длинные тексты, пустые списки, ошибки вёрстка ломается на настоящих данных
Настоящие тексты не «Lorem ipsum» заголовки не помещаются
Движение длительности и кривые из токенов, короткое видео анимацию делают на ощупь
Изображения пропорции, кадрирование, форматы фото растянуты и тяжёлые
Значки SVG на одной сетке и с одной толщиной линии значки разного размера и стиля
Доступность проверенный контраст, порядок фокуса, alt проблемы всплывают после запуска
Спецификация на компонент несколько строк: токены, состояния, ширины вопросы в чатах неделями

Карточка глазами разработчика

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

Дубовый стол

Массив дуба, 160 × 90 см

В корзину
space.5 · 24 space.2 · 8 space.5 · 24
  • card.bg → color.surface
  • card.radius → radius.lg · 16
  • title → font.step-2 · 600
  • text → font.step-0 · color.text-muted
  • button → Button / primary / md
  • image → 4 : 3 · object-fit: cover

Инструменты, которые связывают макет и код

  1. Переменные Figma

    Токены внутри макета, с режимами для тем.

  2. Режим разработчика

    Разработчик видит имена переменных, а не сырые числа.

  3. Tokens Studio

    Синхронизирует токены между макетом и репозиторием.

  4. Style Dictionary

    Собирает файлы для CSS, iOS и Android из одного набора токенов.

  5. Storybook

    Каталог свёрстанных компонентов со всеми состояниями.

  6. Визуальные тесты

    Снимки компонентов сравниваются после каждого изменения.

Передача в файлах: 2 примера

Сборка токенов для сайта и iOS-приложения и короткая спецификация одного компонента.

Один источник, две платформы

Style Dictionary берёт токены и пишет CSS-переменные и файл для Swift.

sd.config.json 
{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "build/css/",
      "files": [{ "destination": "tokens.css", "format": "css/variables" }]
    },
    "ios": {
      "transformGroup": "ios-swift",
      "buildPath": "build/ios/",
      "files": [{ "destination": "Tokens.swift", "format": "ios-swift/class.swift" }]
    }
  }
}

Спецификация компонента

Восемь строк отвечают на вопросы, которые иначе задавали бы в чате.

card.spec.txt 
# Карточка / товар — что разработчик получает вместе с макетом
Токены       фон color.surface · радиус radius.lg · поля space.5
Фото         4:3, object-fit: cover, ленивая загрузка ниже первого экрана
Заголовок    font.step-2, 600, не больше 2 строк, дальше многоточие
Текст        font.step-0, color.text-muted
Кнопка       Button / primary / md — состояния из библиотеки
Состояния    наведение: shadow.md · фокус: кольцо вокруг всей карточки
Ширины       1 колонка до 600 px · 2 до 1024 px · 4 от 1024 px
Крайние      нет фото: заглушка · цена по запросу: текст вместо числа

Чек-лист перед передачей макета

  1. 01

    Имена совпадают

    Переменные в макете и в коде называются одинаково.

  2. 02

    Никаких сырых значений

    Каждый цвет и расстояние в макете привязаны к токену.

  3. 03

    Нарисованы все состояния

    Наведение, фокус, нажатие, недоступность, загрузка, ошибки.

  4. 04

    Три ширины

    375, 768 и 1440 px — и что происходит между ними.

  5. 05

    Настоящее содержимое

    Самый длинный заголовок, пустой список, отсутствующее фото.

  6. 06

    Контраст проверен

    Каждая пара текста и фона читается.

  7. 07

    Движение описано

    Длительности и кривые из токенов плюс вариант без движения.

  8. 08

    Сверка после вёрстки

    Дизайнер проверяет свёрстанную страницу до выпуска, а не после.

Где дизайн теряется по дороге в код

  1. Только десктоп

    Большинство посетителей приходит с телефона, а его версию собирают наугад.

  2. Идеальное содержимое в макете

    Настоящие заголовки длиннее, а фото другой пропорции.

  3. Ссылка вместо передачи

    «В файле всё есть» — и пятьдесят вопросов в чате.

  4. Разные имена

    В макете «Primary/500», в коде «--blue-main» — никто не знает, что это одно и то же.

  5. Дизайн заканчивается на передаче

    Без сверки свёрстанной страницы мелкие расхождения копятся.

  6. Правки только в макете

    Сайт живёт дальше, макет отстаёт, и следующая передача начинается с неправды.

Вопросы о передаче дизайна в разработку

Что нужно разработчику от дизайнера?

Токены, компоненты с состояниями, три ширины, крайние случаи, настоящие тексты и короткая спецификация на компонент.

Достаточно ли режима разработчика в Figma?

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

Как держать макет и код синхронными?

Токены в одном репозитории, одинаковые имена с обеих сторон и сборка, которая генерирует код.

Кто проверяет результат?

Дизайнер сверяет свёрстанную страницу до выпуска; визуальные тесты ловят откаты после.

Сколько ширин должно быть в макете?

Три: телефон, планшет и десктоп — плюс пометка, как раскладка ведёт себя между ними.

А если дизайн и код делает один человек?

Потерь меньше, но те же правила всё равно помогают: токены и состояния держат порядок по мере роста проекта.

Форма

Дизайн и код
в одних руках

Я сама проектирую и верстаю, поэтому по дороге от макета до сайта ничего не теряется, — а для вашей команды готовлю передачу по тем же правилам. Расскажите о проекте — отвечу в течение рабочего дня.

Или пишите на [email protected]