На старте любого проекта я первым делом собираю один файл. Ещё до лендинга, до первого поста и первой презентации. В нём записано, какими цветами мы говорим, какими шрифтами и чего нельзя ни при каких условиях, — пять‑шесть экранов текста в 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 и Дзен по brand-system.md.
Тёмная тема. Обещание статьи, не термины из середины.
Три цифры из текста — моноширинным.

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

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

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

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

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

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

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

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

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

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

С чего начать

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

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

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

---

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