Google открыла формат DESIGN.md для передачи дизайн-системы AI-агентам

Google опубликовала открытую спецификацию DESIGN.md — формат файла для описания визуальных правил, которые могут читать AI-агенты при создании интерфейсов. Как пишет DEV.to в материале от 4 октября 2026 года, спецификацию представила команда Stitch. Идея в том, чтобы агент опирался на заданные цвета, типографику и компоненты, а не пытался угадать их по просьбе «сделать современно». Формат пока находится в альфа-версии.

Что хранится в DESIGN.md

У файла два слоя. В начале — блок YAML с машиночитаемыми токенами: цветами, типографикой, отступами и скруглениями. Затем идёт текст на Markdown, который объясняет замысел и правила применения. Так агент получает не только значение цвета, но и указание, какую роль тот играет в оформлении.

Формат позволяет описывать компоненты. Для основной кнопки, например, можно задать фон, цвет текста, внутренние отступы и форму углов, а состояние при наведении вынести отдельно. Это конкретнее просьбы «сделай заметную кнопку»: после одного редизайна я бы вообще выдавала такие просьбы только вместе с определением слова «заметная».

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

В репозитории приведён пример Heritage: тёмные заголовки, тёплый светлый фон, отдельный цвет для интерактивных элементов. Он показывает, как описать характер интерфейса до написания кода, а не предлагает всем пользоваться одной палитрой.

Вместе с форматом доступна утилита командной строки. Команда npx @google/design.md lint DESIGN.md проверяет, в частности, некорректные ссылки между токенами и контрастность по WCAG. Результат выдаётся в структурированном JSON, с которым может работать агент. Есть и команда сравнения двух версий дизайн-системы: она помогает увидеть различия в токенах и текстовых правилах.

Что это меняет в работе над сайтом

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

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

Ограничения тоже есть. Спецификация пока в альфа-версии, а файл не создаст дизайн-систему там, где решения ещё не приняты. В материале упомянуты жалобы на тайм-ауты при подключении Stitch через MCP и на то, что Stitch кажется неинтуитивным. Эти замечания касаются опыта работы с инструментом; считать их итоговой оценкой формата было бы преждевременно.

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

Моё мнение: правила нужны не ради файла

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

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Why DESIGN.md Broke the Internet in Under 24 Hours dev.to

Об авторе

Элена Бронштейн

заказчица сайта для семейного гостевого дома

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

Все публикации автора