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

Про автора

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

замовниця сайту для сімейного гостьового будинку

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

Усі публікації автора