Быстрый старт для дизайнера

DFC Bridge — договорённость о том, как читать макет. Figma хранит раскладку и внешний вид, а стабильные имена и короткие теги объясняют недостающий смысл. Другой человек должен находить эти решения без вопросов к автору.

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

Зачем команде эти сведения? Визуальный экскурс связывает вопросы передачи с решениями и настоящими снимками Figma.

На какие вопросы должен отвечать файл

В макете должно быть понятно:

1. какую страницу и состояние мы видим;
2. какие подготовленные ширины относятся к этой странице;
3. какие слои обозначают один и тот же элемент;
4. что делает каждая ссылка или кнопка;
5. что остаётся редактируемым, что является декором и что нужно экспортировать.

Один небольшой пример

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

Было: без звонка не разобраться

desktop
  frame-42
    heading
    button

mobile-final-2
  group-91
    title

По таким именам нельзя понять, одна ли это страница, какие элементы совпадают и что делает кнопка.

Стало: файл объясняет себя

Текст перед скобками — имя слоя. Тег в скобках добавляет смысл: [page=home] обозначает страницу, а [action=modal:contact-modal] — действие кнопки и его цель. Теги входят в имя слоя, а не в видимый текст интерфейса.

home [page=home] [bp=1440] [view=default]
  hero [section=home-hero]
    hero-title
    contact-button [action=modal:contact-modal]
  contact-modal [modal=contact-modal]

home [page=home] [bp=375] [view=default]
  hero [section=home-hero]
    hero-title
    contact-button [action=modal:contact-modal]
  contact-modal [modal=contact-modal]

Сокращённое дерево: на обеих ширинах сохранены кнопка и настоящая цель. Нативную раскладку и поведение окна нужно подготовить отдельно.

Одна page/view, две нативные ширины. bp — не порог CSS; URL задаёт route.

Подготовьте файл за пять шагов

1. Назовите страницу

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

home [page=home] [bp=1440] [view=default]

Добавляйте [route=/real-path], только если рабочий маршрут уже известен. Не придумывайте адрес ради заполнения тега.

2. Используйте стабильные имена слоёв

Используйте короткие английские имена в kebab-case:

hero-title
product-grid
contact-button

Один логический элемент должен иметь одно имя на всех подготовленных ширинах. Найдите hero-title на каждой ширине: соответствие должно быть понятно без сравнения внешнего вида. Не добавляйте к имени -mobile, -desktop или ширину.

3. Покажите важные ширины

Подготовьте широкую и узкую версии, которые команда будет реализовывать. Сохраните одинаковые [page] и [view], а в [bp] укажите подготовленную ширину.

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

4. Опишите ссылки и действия

Используйте [href] для перехода и [action] для изменения интерфейса:

email-link [href=mailto:sales@example.com]
contact-button [action=modal:contact-modal]

Для локального действия подготовьте соответствующую цель в заявленной области. Здесь читатель может проследить связь от действия кнопки до [modal=contact-modal]. Если адрес или действие ещё неизвестны, используйте черновую отметку [link] или [control] и запишите открытый вопрос с ответственным; не придумывайте цель.

5. Проверьте передачу

Попросите человека, который не готовил файл, ответить:

• что это за страница и состояние;
• какие ширины к ней относятся и какие слои соответствуют друг другу;
• что делает каждый интерактивный элемент;
• что нужно оставить редактируемым или экспортировать.

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

Добавляйте только смысл, которого нет в Figma

Задавайте раскладку, внешний вид и свойства компонентов средствами Figma; не повторяйте их тегами. Стабильному имени вроде hero-title не нужен дополнительный тег, если смысл уже понятен.

Схемы данных, сложные адаптивные преобразования и подробное поведение относятся к структурированному контракту bridge, а не к выдуманным тегам или длинным именам слоёв.

Подробнее см. в разделе правила подготовки макета и в руководстве по именам слоёв.

Если вы работаете внутри существующего продукта

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

Дальше

• Примеры DFC Bridge
• Чеклист дизайнера
• Полная проверка