DESIGN.md — открытый текстовый формат для описания визуальной системы проекта. Он помогает людям и AI-агентам одинаково понимать назначение цветов, типографику, сетку, форму компонентов и другие правила интерфейса.

По состоянию на 4 сентября 2026 года Google публикует формат как черновую спецификацию (draft specification) со статусом alpha. Файл уже можно использовать как переносимый источник визуального контекста, но его поддержка и способ подключения зависят от конкретного инструмента.

Содержание

  1. Какую проблему решает DESIGN.md
  2. Как устроен актуальный формат
  3. Целевая архитектура
  4. Как внедрить файл в проект
  5. Эталонный шаблон
  6. Чеклист быстрой проверки
  7. Готовые примеры в awesome-design-md
  8. Ограничения
  9. Источники

Какую проблему решает DESIGN.md

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

DESIGN.md фиксирует единый контекст для таких решений. В нём можно указать:

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

Google Stitch позволяет импортировать и экспортировать правила между проектами. Открытая спецификация также рассчитана на обмен дизайн-контекстом между разными агентами и инструментами.

Как устроен актуальный формат

Файл остаётся читаемым Markdown-документом, но утверждение «никаких схем и структурированных данных» устарело. В текущей спецификации описана необязательная YAML-часть в начале файла (front matter) со структурированными токенами; это не означает, что документ обязан содержать такой блок.

Текущий формат предусматривает две части:

  1. Необязательный YAML-блок с машиночитаемыми дизайн-токенами.
  2. Markdown-разделы с объяснением визуальной логики и правилами применения.

При наличии YAML-токенов их точные значения считаются нормативными, а текст поясняет их назначение. В YAML можно описать группы colors, typography, spacing, rounded и components, а также ссылаться на другие токены через синтаксис {path.to.token}.

Спецификация задаёт порядок Markdown-разделов:

  1. Overview или Brand & Style;
  2. Colors;
  3. Typography;
  4. Layout или Layout & Spacing;
  5. Elevation & Depth;
  6. Shapes;
  7. Components;
  8. Do's and Don'ts.

Ненужные разделы разрешено пропускать. Намеренно отсутствующие группы токенов можно перечислить в поле omitted, чтобы линтер не считал их случайно забытыми.

Целевая архитектура

Практичная схема выглядит так:

Реальная дизайн-система
        ↓
DESIGN.md: токены + объяснение правил
        ↓
Инструкция для конкретного инструмента
        ↓
Сгенерированный интерфейс
        ↓
Визуальная и техническая проверка

Источником истины остаются утверждённые правила продукта. DESIGN.md переносит их в форму, понятную агенту. Сам файл не гарантирует, что модель применит каждое правило, поэтому результат нужно проверять.

В экосистеме проектных инструкций он может соседствовать с другими файлами:

ФайлОсновной читательНазначение
README.mdЛюди и инструментыНазначение проекта, запуск и обзор
AGENTS.mdАгенты, работающие с кодомПравила сборки, тестирования и работы с кодом
DESIGN.mdЛюди и агенты, работающие с дизайном или кодомВизуальная система и правила интерфейса
CLAUDE.mdClaude CodeПроектные инструкции для Claude Code

Порядок обнаружения и применения таких файлов задаёт конкретный инструмент. Если автоматическая поддержка DESIGN.md не заявлена, явно укажите агенту прочитать файл перед работой над интерфейсом.

Как внедрить файл в проект

1. Соберите исходные правила

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

2. Создайте DESIGN.md

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

3. Подключите файл к рабочему процессу

В Google Stitch правила можно переносить через импорт и экспорт DESIGN.md. Для других инструментов добавьте явную инструкцию, например:

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

4. Начните с одного проверяемого экрана

Попросите агента собрать небольшой экран с основными элементами: заголовком, текстом, кнопками, полем ввода и карточкой. Сравните результат с правилами файла и исправьте неоднозначные формулировки.

5. Добавьте проверку

Проверяйте токены в коде, контраст текста, состояния компонентов и поведение на разных размерах экрана. В черновой спецификации описана работа с цветами и проверкой контраста, но фактические возможности зависят от потребителя файла.

Эталонный шаблон

Минимальный рабочий каркас можно оформить так:

---
version: alpha # Текущая версия черновой спецификации.
name: Product Design System
colors:
  primary: '#2457D6' # Основной цвет приоритетных действий.
  surface: '#FFFFFF' # Основная поверхность интерфейса.
  on-surface: '#1B1B1F' # Основной цвет текста на поверхности.
typography:
  body-md:
    fontFamily: Inter # Семейство шрифта основного текста.
    fontSize: 16px # Размер основного текста.
    fontWeight: 400 # Обычный вес.
    lineHeight: 1.5 # Безразмерный множитель относительно размера шрифта.
spacing:
  sm: 8px # Малый шаг шкалы отступов.
  md: 16px # Базовый внутренний отступ.
  lg: 32px # Крупный отступ между группами.
rounded:
  sm: 4px # Малый радиус.
  md: 8px # Базовый радиус.
components:
  button-primary:
    backgroundColor: '{colors.primary}' # Ссылка на основной цвет.
    textColor: '{colors.surface}' # Ссылка на цвет текста кнопки.
    rounded: '{rounded.md}' # Ссылка на радиус кнопки.
    padding: 12px # Внутренний отступ кнопки.
---

# Product Design System

## Overview
Спокойный, функциональный интерфейс с ясной иерархией и умеренной плотностью.

## Colors
Основной цвет используется для главного действия. Нейтральные поверхности отделяют группы содержимого.

## Typography
Основной текст рассчитан на продолжительное чтение. Заголовки создают иерархию без чрезмерного контраста размеров.

## Layout
Используйте базовую шкалу отступов 8 пикселей и ограниченную ширину текстовых блоков.

## Elevation & Depth
Разделяйте уровни фоном и тонкими границами. Тени применяйте только для плавающих элементов.

## Shapes
Используйте единый набор радиусов. Не смешивайте резко разные формы на одном экране.

## Components
Опишите кнопки, поля ввода, карточки и их состояния: обычное, наведение, нажатие, фокус, ошибка и недоступность.

## Do's and Don'ts
- Используйте основной цвет для приоритетного действия.
- Поддерживайте контраст не ниже требований доступности WCAG для выбранного типа текста.
- Не вводите новые значения вне утверждённых шкал без объяснения.

Это отправная точка. Для рабочего проекта добавьте реальные токены, адаптивное поведение, доступность и правила предметно-специфичных компонентов.

Чеклист быстрой проверки

Файл описывает конкретный продукт, а не абстрактный «современный интерфейс».
У каждого ключевого цвета указана функциональная роль.
Токены совпадают с кодом или утверждённым макетом.
Типографика содержит размеры, веса и межстрочные интервалы.
Определены шкала отступов и принципы сетки.
Зафиксированы радиусы, поверхности и правила глубины.
Описаны основные компоненты и их состояния.
Указано адаптивное поведение важных элементов.
Есть правила доступности и проверки контраста.
Противоречия между токенами и поясняющим текстом устранены.
Агенту явно сказано, когда читать DESIGN.md.
Тестовый экран визуально проверен перед массовой генерацией.

Готовые примеры в awesome-design-md

Репозиторий VoltAgent awesome-design-md содержит курируемые файлы, составленные по публично видимым дизайн-системам и сайтам. В коллекции есть примеры для Stripe, Vercel, Linear, Notion, Figma, GitHub и многих других продуктов.

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

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

Ограничения

  • Спецификация пока черновая. Статус alpha означает, что структура и поддержка компонентов могут меняться.
  • Поддержка зависит от инструмента. Универсальное автоматическое обнаружение файла спецификацией не гарантировано.
  • Один документ не охватывает всю реализацию. Сложным продуктам дополнительно нужны библиотека компонентов, токены в коде, тесты и документация состояний.
  • Следование правилам зависит от модели и задачи. Даже подробный файл не отменяет проверку результата.
  • Заимствованный стиль требует адаптации. Готовый пример может конфликтовать с брендом, доступностью или существующей архитектурой продукта.

Источники

Следующий шаг

Продолжите с руководства Как на самом деле проектировать дизайн с ИИ, чтобы встроить визуальный контекст в более широкий процесс проектирования.

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov