Дизайн-система в одном markdown-файле: как я задаю правила визуала, которые читает и человек, и нейросеть

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

Дальше файл работает молча. Нужен лендинг — он в основе, нужна презентация для партнёров — оттуда же, нужно поправить экран в продукте и отдать разработчику — я ссылаюсь на файл вместо «сделай посимпатичнее». Карусель в соцсети? Тот же файл.

Сразу скажу, откуда я на это смотрю. Я маркетолог, не дизайнер и не разработчик. Айдентику мне помогал собирать живой человек, код по этим правилам пишет Claude Code, а моя часть — записать правила и принять результат. Так что теории дизайна дальше не будет. Будет формат документа, который переживает исполнителей и читается нейросетью без напоминаний.

Почему разнобой выглядит дешевле плохого вкуса

Знакомая картина: по отдельности всё нормально. Лендинг нормальный, презентация нормальная, посты тоже. А вместе выглядит так, будто продукт склеили из трёх разных.

И дело почти никогда не в том, что кто-то выбрал некрасивый цвет. Просто цвет каждый раз выбирали заново.

Что именно разъезжается на практике:

Оттенки размножаются. На лендинге синий #4338CA. В презентации «ну, синий» из шаблона, вышло #4F46E5. В сторис третий, его подбирали на глаз на телефоне. По отдельности разницы не видно, а рядом это читается как неряшливость.

Отступы дышат случайно. Между заголовком и текстом где-то 16 пикселей, где-то 22, где-то 30, потому что о шаге никто не договорился. Пиксели глаз не считает. Ритм ловит.

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

Цифры разъезжаются. Колонка чисел, где 1 200 и 15 набраны шрифтом с пропорциональными цифрами, и аккуратная таблица получает рваный край.

Акцент перестаёт быть акцентом. Яркий цвет задуман, чтобы выделить одно главное. Выделили им пять вещей на экране, значит, не выделили ничего.

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

И ещё практическое. Раньше разнобой стоил времени дизайнера. Сейчас визуал часто собирает нейросеть, и без файла с правилами она каждый раз выдаёт свою версию «красивого». Двадцать картинок — двадцать разных продуктов. Догадаться о вашем стиле модель не может, вкуса у неё нет, есть только ваши правила. Записали правила — получили повторяемость.

Дизайн-система, брендбук и UI-кит: где граница

Три слова, которые вечно путают. Разница при этом простая.

Брендбук — про смысл и айдентику: кто мы, как выглядит логотип, что нам нельзя. Часто это PDF на сто страниц.

UI-кит — набор готовых элементов: кнопки, поля, карточки. Библиотека деталей.

Дизайн-система — правила, по которым всё это собирается, плюс сами элементы. Там написано не просто «вот кнопка», там «вот кнопка, вот когда она такая и вот почему отступ именно такой».

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

Чего в моём файле нет, тоже скажу сразу. Нет проработанной библиотеки компонентов на все состояния, нет токенов в коде, нет версионирования и человека, который всё это поддерживает. Когда над продуктом работает команда дизайнеров и экранов десятки, всё это правда нужно, и подменять полноценную систему одним markdown-файлом я не предлагаю. Но если вы делаете продукт один или вдвоём, дизайн-система по всем канонам — это месяц работы, который не окупится. А файл на пять экранов окупается уже на первом лендинге.

Как правила пишут те, у кого на это уходят годы

Полезное упражнение — посмотреть на публичные системы. Копировать незачем, смотреть стоит на логику, и она везде одна: сначала принципы, потом конкретные значения, потом примеры «так — да, так — нет».

Apple Human Interface Guidelines — тут интересны не столько компоненты, сколько то, как объясняются принципы: почему элемент ведёт себя именно так. Раздел про цвет полезен отдельно, там про доступность и поведение в тёмной теме.

Material Design 3 — самая подробная публичная система. Унести оттуда стоит идею токенов, то есть именованных значений. Пишется не «синий», пишется «цвет основного действия», и тогда цвет меняется в одном месте.

Atlassian Design System и IBM Carbon — на этих двух хорошо видна словесная часть: как сформулировать правило, чтобы его нельзя было понять двояко. У обеих загляните в раздел Foundations, там ровно то, из чего будет состоять ваш файл: цвет, типографика, отступы. Carbon к тому же живёт из открытого кода.

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

Сборка файла: промт и порядок шагов

Понадобится только чат с нейросетью, платные сервисы не нужны.

Шаг 1. Собрать референсы, а не описывать словами

Главная ошибка — начинать с «хочу современно и дорого». Эти слова ничего не значат: под «дорого» один представляет чёрный минимализм, другой — золото на бордовом.

Соберите 5–10 примеров того, что нравится: скриншоты сайтов, обложки, фотографии, упаковку. И к каждому одну строку, что именно нравится. «Красиво» не подойдёт, нужно что-то вроде «фон не белый, тёплый» или «цифры крупные и моноширинные».

Этот шаг единственный нельзя делегировать. Что вам нравится, знаете только вы.

Бывает, что нравится что-то конкретное, а из чего оно складывается, непонятно. Тогда референс можно взять уже разобранным: есть каталоги, где настоящие сайты расписаны по параметрам — палитра, шрифты, отступы, радиусы. Про них у меня есть отдельная статья, про дизайн в Claude Code и про то, как переносить приём, не копируя чужой стиль целиком.

Если продукт уже есть: собрать систему из скриншотов

Всё, что выше, — про старт с нуля. Чаще бывает наоборот: продукт работает, лендинг сделан, интерфейс живёт, а записанных правил нет. Они разбросаны по макетам и по голове того, кто это рисовал.

Тогда шаг с референсами можно пропустить. Референс — ваш собственный продукт.

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

Вот скриншоты моего продукта (лендинг и ключевые экраны).
Собери по ним дизайн-систему — вытащи правила, по которым это сделано.

Что нужно:
1. Палитра — назови каждый цвет с экрана, укажи HEX и роль
   (фон, текст, акцент, границы, состояния).
2. Типографика — какие шрифты, какие размеры и начертания,
   какая между ними иерархия.
3. Отступы и радиусы — определи базовый шаг сетки и набор радиусов.
4. Правила — как эти элементы применяются: где акцент, где подложка,
   как выглядит главная кнопка против второстепенной.

Важно: не улучшай и не придумывай своё. Твоя задача — описать то,
что УЖЕ есть, даже если видишь непоследовательность.

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

На выходе черновик, готовой системой он ещё не стал. Дальше два шага ваши.

Первый — пройти список противоречий и по каждому решить, какой вариант правильный. Именно здесь разнобой перестаёт множиться: вы один раз выбираете «вот этот синий», и дальше синий один.

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

А потом правила, вытащенные из продукта, начинают работать за его пределами. Карусели и сторис, обложки статей, презентации, баннеры — всё выглядит продолжением продукта, отдельной историей это уже не смотрится.

Шаг 2. Промт

Вот промт, которым пользуюсь я. Вставляется в любой чат (Claude, ChatGPT, Gemini), к нему прикладываются референсы.

Ты — дизайн-директор, который собирает дизайн-систему для продукта.
Твоя задача — не нарисовать красиво, а записать правила так, чтобы по ним
любой человек и любая нейросеть повторили визуал один в один.

О ПРОДУКТЕ
- Что это: [одно предложение: что за продукт и для кого]
- Кто аудитория: [кто эти люди, что для них важно]
- Какое впечатление должен производить: [3 прилагательных]
- Чем НЕ должен выглядеть: [от чего бежим: «не как банк», «не как
  детский сад», «не как инфобизнес»]
- Где будет применяться: [сайт, презентации, соцсети, интерфейс, PDF]

РЕФЕРЕНСЫ
[приложи 5-10 картинок и к каждой строкой — что именно нравится]

ЧТО НУЖНО СОБРАТЬ (в таком порядке)

1. КОНЦЕПЦИЯ — 2-3 предложения: какая идея держит визуал вместе.
   Не «современно и стильно», а конкретный образ.

2. ПАЛИТРА — таблица, в каждой строке: роль | название | HEX.
   Обязательные роли: основной фон · фон-подложка · основной текст ·
   второстепенный текст · границы и линии · ОДИН акцентный цвет ·
   цвет успеха · цвет ошибки.
   Правила: акцентный цвет ровно один; для каждого цвета укажи,
   на каком фоне его можно ставить, а на каком нельзя.

3. ТЁМНАЯ И СВЕТЛАЯ ТЕМА — обязательно обе, парами.
   Для каждой роли из палитры дай два значения: светлая тема / тёмная.
   Тёмная тема — это НЕ инверсия: чистый чёрный #000 не использовать,
   брать глубокий тёмный с оттенком; насыщенность акцента в тёмной теме
   поднимать, иначе он гаснет; тени в тёмной теме не работают —
   вместо них разделять поверхности светлотой.
   Проверь контраст текста к фону: не ниже 4.5:1 для обычного текста
   и 3:1 для крупного. Посчитай и напиши значения.

4. ТИПОГРАФИКА
   - шрифт заголовков и шрифт текста (максимум два семейства);
   - ОБЯЗАТЕЛЬНО: оба шрифта должны поддерживать кириллицу — проверь
     и напиши, поддерживает ли;
   - для каждого шрифта — системная замена, если он недоступен;
   - шкала размеров: 5-6 ступеней с конкретными px и межстрочным;
   - отдельное правило для цифр: каким шрифтом набираются числа
     в таблицах и на графиках (моноширинным или tabular-nums).

5. СЕТКА И ОТСТУПЫ
   - базовый шаг (4 или 8 px) и шкала на его основе;
   - радиус скругления: 2-3 значения и где какое;
   - правило теней: либо их нет, либо 2 варианта с параметрами.

6. ПРЕДОХРАНИТЕЛИ — 5-7 жёстких запретов в форме «никогда не».
   Это самая важная часть: именно запреты держат систему.
   Выведи их из пункта «чем НЕ должен выглядеть».

7. ПРИМЕНЕНИЕ ПО МАТЕРИАЛАМ — таблица: материал | фон | что на нём.
   Строки: лендинг · презентация · пост в соцсети · сторис ·
   PDF-документ · экран продукта.

8. РАЗМЕРЫ МАКЕТОВ — под каждую площадку из списка применения.

ФОРМАТ ОТВЕТА
Один markdown-файл, который можно сохранить и давать другим нейросетям
как инструкцию. Каждое значение — конкретное (HEX, px, название шрифта).
Никаких «примерно», «на ваш вкус», «можно поэкспериментировать».
Если чего-то не хватает для решения — сначала задай мне вопросы,
не выдумывай.

В конце отдельным списком: что в этой системе самое хрупкое —
где её проще всего случайно нарушить.

Основную работу в этом промте делают две вещи.

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

Вторая — раздел с запретами. Правила вида «делай так» модель трактует свободно, а запрет «никогда не ставь два акцентных элемента на одном экране» нарушить сложнее. У меня в файле этот раздел называется «предохранители», и держит систему он лучше всего остального.

Требование про кириллицу в промте тоже не случайно. У меня Fraunces (шрифт заголовков на сайте) кириллицу не поддерживает, поэтому в документах вместо него стоит Georgia. Не проверила бы на старте — поймала бы это на первом же PDF.

Шаг 3. Проверить руками и придраться

Файл на выходе выглядит убедительно. И всё равно три вещи стоит проверить.

Контраст. Попросите посчитать и посмотрите сами: светло-серый текст на белом в промте выглядит элегантно, а на телефоне под солнцем не читается.

Тёмную тему живьём. Пусть модель соберёт одну простую страницу с переключателем тем. Таблица с кодами тут мало что скажет, смотреть надо на результат: гаснет ли акцент, видны ли границы карточек.

Придирку к хрупкости. Ответ на последний пункт промта (что тут самое хрупкое) — самый полезный из всех. Оттуда и берутся будущие предохранители.

И ещё. Первую неделю править файл каждый день — нормально. Ошибётесь в паре оттенков, поправите. Главное, чтобы правки шли в один файл и не расползались по десяти макетам.

Как выглядит результат

Чтобы не звучало абстрактно, покажу свой. Система называется «Песок и ночь» и живёт в одном markdown-файле.

Вот два материала, сделанных по этому файлу в разное время и под разные задачи:

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

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

Несколько выдержек из него.

Палитра — с ролями, не просто список цветов:

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

Типографика: заголовки — Fraunces, вне веба Georgia (кириллицы у Fraunces нет). Текст — Inter. И отдельное правило, самое полезное из всех: цифры и факты всегда моноширинным шрифтом, колонки чисел выравниваются по одной вертикали, с обязательным tabular-nums. Рваный край в цифрах запрещён везде — в слайдах, каруселях, PDF.

Предохранители — тот самый раздел запретов:

1. Никаких акварелей, мягких градиентов, тонких рукописных шрифтов — только плоские заливки и чёткие формы.

2. Акцент — ОДИН на материал. Два акцентных элемента на карточке = ошибка.

3. Цифры — моноширинным, факты — конкретные.

4. Примерно треть материалов — тёмные. Беж-бренды не бывают тёмными.

Четыре строки, а держат больше, чем всё остальное вместе. Мой личный риск — уехать в «бежевого коуча», и запреты написаны как раз против него. У вашего продукта риск другой, значит, и запреты будут другие.

Отдельно про дизайнера: после этого он не становится ненужным. Айдентику — знак, характер, идею — мне помогали собирать насмотренность и правки живого человека. Модель хорошо записывает правила и точно их повторяет, а вот придумать, что должно стать вашим лицом, не может. Файл просто хранит уже придуманное и не даёт ему расползтись.

Где хранить файл, чтобы его читали без напоминаний

Файл, который надо не забыть приложить, обязательно забудут приложить. Поэтому задача — сделать так, чтобы ассистент брал его сам.

Устроено это так. У AI-ассистентов, которые работают с папками на компьютере (Claude Code, Cursor, Codex и похожие), есть договорённость: они читают файл с инструкциями в корне проекта. У Claude Code это CLAUDE.md, у многих других AGENTS.md. Всё, что там написано, попадает в контекст автоматически.

Отсюда схема:

мой-проект/
├── CLAUDE.md              ← читается всегда, здесь ссылка на систему
├── brand/
│   ├── brand-system.md    ← сама дизайн-система, источник правды
│   └── assets/            ← логотип (SVG+PNG), шрифты, иконки
├── landing/
└── content/

В CLAUDE.md — короткая врезка на несколько строк:

### Визуал — обязательно к прочтению

Перед созданием ЛЮБОГО визуала (лендинг, презентация, карусель,
баннер, PDF, экран продукта) читать `brand/brand-system.md`.
Это единственный источник правды по цветам, шрифтам и правилам.
Свои цвета и шрифты не придумывать. Нужного правила нет в файле —
спросить меня, а не решать самостоятельно.

Работает это благодаря трём деталям, без них врезка так и останется декорацией.

Ссылка, а не копия. В CLAUDE.md только путь. Скопируете туда палитру — получите две версии правды, и через месяц они разъедутся.

Указан момент, когда читать. Фраза «у нас есть бренд-система» ассистенту ничего не даёт. Ему нужен триггер: «перед созданием любого визуала — читать файл».

Прямой запрет на самодеятельность. Строчка «своих цветов не придумывать, нужного правила нет — спросить» экономит массу правок. Без неё модель в непонятной ситуации додумает сама, вежливо и мимо.

Честная оговорка: гарантии это не даёт, только повышает шансы. Инструкция из CLAUDE.md попадает в контекст, но жёстким ограничением не становится, иногда файл всё равно приходится назвать в задаче явно. Убирать из процесса пятый шаг «проверь результат по правилам из файла» пока рано.

Если вы работаете в обычном чате в браузере, а не в папке, принцип тот же, меняется механика. У ChatGPT есть проекты с инструкциями, у Claude — проекты, куда файл кладётся один раз и виден во всех диалогах внутри.

Бытовое, но важное: файл должен быть обычным текстом (markdown). Документ в облаке или PDF не подойдёт. Текст читают все модели, он лежит рядом с проектом, и у него видна история правок. Картинки (логотип, шрифты) — рядом в папке, с понятными именами.

Как файл не превращается в памятник

Дизайн-система живёт, пока её правят. Весь вопрос в том, чтобы правки шли в файл, а не в макеты.

У меня три правила, и все выросли из собственных грабель.

Правило первое: поправили руками дважды — значит, дыра в файле.

Если я второй раз объясняю модели одно и то же («подписи серым», «цифры моноширинным»), модель тут ни при чём. Просто правила нет в файле. Один раз — случайность. Два — пора дописать правило и больше к этому не возвращаться.

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

Правило второе: у файла есть шапка — когда читать и когда обновлять.

В начало файла я ставлю несколько строк служебной информации:

---
purpose: Единственный источник правды по визуалу продукта
read-when:
  - перед созданием любого визуала
  - перед генерацией картинок для соцсетей
update-when:
  - утверждено изменение палитры, шрифтов или правил
  - правило пришлось объяснять руками второй раз
---

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

Правило третье: новое решение дописывается сразу, пока помнится почему.

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

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

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

Как это выглядит на задачах

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

Карусели и посты для соцсетей

Без системы запрос выглядел бы так: «сделай карусель на 7 слайдов про [тему], фон тёплый бежевый #EBDCBE, заголовки шрифтом с засечками, акцент терракотовый #B44E2C, но только на одном слове, цифры моноширинным, размер 1080×1350, логотип справа внизу, и не делай градиентов…» — и так каждый раз, с риском что-нибудь забыть.

С системой:

Сделай карусель на 7 слайдов про [тему] по brand-system.md.
Драматургия: первый слайд светлый, финальный тёмный.
Главную цифру — на слайд 4.

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

Баннер к статье в медиа

У каждой площадки свои размеры, и держать их в голове бессмысленно. В файле у меня таблица размеров с оговорками: для VC 1200×675, для Дзена 1920×1080, причём у Дзена в подборках режутся края, так что всё смысловое держится в центре.

Запрос:

Обложка к статье «[заголовок]» под VC и Дзен по brand-system.md.
Тёмная тема. Обещание статьи, не термины из середины.
Три цифры из текста — моноширинным.

Одну проверку я делаю всегда: смотрю обложку в размере примерно 170 пикселей. Такой её видно в мобильной ленте. Если там не читается, не работает вообще.

Что даёт по совокупности

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

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

Ограничения метода — честно

Серебряную пулю продавать не хочу, поэтому вот четыре места, где подход не даёт того, чего от него ждут.

Файл не заменяет дизайн-систему в коде. Markdown задаёт значения словами, а не токенами, которые компилируются в CSS-переменные. Когда есть команда дизайнеров и десятки экранов, нужны именно токены с версионированием, и файл там останется смысловым слоем, источником для сборки он не будет.

Инструкция в CLAUDE.md — не жёсткое ограничение. Шансы, что файл прочитают до работы, она повышает, но не гарантирует. Финальная проверка результата остаётся ручной.

Файл не придумывает айдентику. Он хранит решения, которые уже приняты. Что станет лицом продукта, решает человек.

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

С чего начать

Если из всей статьи делать одно действие, то такое: соберите 5–10 референсов с пометкой, что в них нравится, прогоните промт выше и сохраните результат как brand-system.md в папку проекта. Потом добавьте в CLAUDE.md (или в инструкции проекта в чате) три строки: перед любым визуалом читать этот файл, своих цветов не придумывать.

Полчаса работы. С первого раза файл идеальным не выйдет, и не надо. Важно, чтобы он был один.

В спор о том, как правильно устроить дизайн-систему по канону, я не полезу. Моя часть работы другая — записать правила так, чтобы по ним собиралось одинаково, и принять результат. Если у вас есть свой формат такого файла или места, где markdown не тянет, расскажите в комментариях, заберу и проверю на своём.

Автор: Надя Пак, AI-native PMM, автор курса по AI-маркетингу — строю маркетинг на AI-агентах: реклама, аналитика, контент.