Figma открыла Code Layers и запустила Specs: что это меняет для ревью дизайна
На первой конференции Config в Индии 14–15 октября Figma вывела Code Layers из закрытой беты в открытую, запустила редактор Specs для описания дизайн-языка и встроила свою headless CMS Payload в Figma Make. Об этом сообщили TechCrunch и официальный блог Figma. Для команд, которые собирают и согласовывают правки, главное здесь вот что: на ревью теперь чаще будут приходить не статичные кадры, а живые прототипы с настоящим кодом внутри.
Code Layers позволяют держать на холсте интерактивные прототипы, собранные на коде. Слой можно получить из готового фрейма, загрузить из локальной папки, импортировать из репозитория GitHub или снять с живого сайта. Открытая бета доступна на всех тарифах. Specs — это отдельный редактор на Markdown, где команда описывает правила своего дизайна и прямо в тексте ссылается на макеты, диаграммы FigJam и те же код-слои. Specs работают через MCP-сервер Figma, так что на эти правила могут опираться и встроенный Figma Agent, и сторонние ИИ-агенты. Specs вышли в открытую бету на всех платных тарифах.
Третье объявление касается Figma Make: туда подключили Payload, и теперь в Make можно собирать сайты, которые берут данные из базы, и управлять их контентом без доступа к исходникам. Для маркетингового лендинга этого может хватить. Для продукта с личным кабинетом, интеграциями и нагрузкой нужна полноценная архитектура, и такой проект обычно отдают студии разработки веб-приложений, а прототип из Figma остаётся отправной точкой.
Что ещё показали
Figma Agent вышел из беты и стал общедоступным, он работает прямо на холсте. Кроме того, MCP-сервер Figma получил 20 новых интеграций, среди них OpenCode, браузер Dia, Junie от JetBrains и Meta Muse. Интеграцию с Payload раскатят на все аккаунты в ближайшие недели, об этом пишет Techzine. Директор по дизайну Figma Лоредана Крисан объяснила, зачем всё это нужно: сегодня пишут в 17 раз больше кода, чем раньше, а релизов выходит лишь в 1,3 раза больше. По её словам, значительная часть этого кода пишется для того, чтобы найти, каким вообще должен быть продукт.
Что это значит для ревью и согласования
Если прототип собран на коде, ревьюер проверяет уже не только картинку. Он смотрит на состояния, переходы и поведение при реальных данных. Правок становится больше, и они точнее: «кнопка не реагирует на втором шаге» вместо «поправьте кнопку». Отсюда три следствия для студий и продуктовых команд.
Комментарий нужно привязывать к состоянию, а не только к кадру. Скриншот статичного фрейма уже не показывает, где сломалось. Удобнее всего собирать правки там же, где живёт прототип или собранная страница. Мы разбирали это в материале «Figma или готовый сайт: где собирать фидбек».
Specs становятся частью критериев приёмки. Когда правила дизайна записаны в одном документе, спор «так задумано или это баг» решается ссылкой на конкретное правило, а не созвоном. Это особенно полезно, если часть макетов генерирует агент: проверять придётся, соблюдает ли он правила из Specs.
Граница между прототипом и продуктом размывается, но не исчезает. Если Figma Make с Payload собирает сайт, клиент может решить, что продукт почти готов. Сразу проговорите, что именно сдаётся: макет, прототип на коде или рабочий сайт на тестовом домене. Иначе приёмка затянется. Подробнее о том, как не потерять правки на этом этапе, читайте в статье о согласовании макетов Figma.
Что делать сейчас
Попробуйте Code Layers на одном текущем проекте: соберите из ключевого экрана прототип на коде и проведите по нему обычный раунд ревью. Сравните, сколько правок пришло и насколько они конкретнее, чем по статичным кадрам. Параллельно перенесите в Specs хотя бы базовые правила (сетку, типографику, состояния кнопок), чтобы на следующей приёмке было на что ссылаться.
