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

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

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

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

Что именно едет на практике:

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

Отступы дышат случайно. Между заголовком и текстом где-то 16 пикселей, где-то 22, где-то 30 — потому что никто не договорился о шаге. Глаз не считает пиксели, но ритм ловит. Именно рваный ритм даёт то самое ощущение «сделано на коленке».

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

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

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

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

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

Что такое дизайн-система и чем она отличается от брендбука и UI-кита

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

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

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

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

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

Отдельно скажу, чего в моём файле нет. Там нет проработанной библиотеки компонентов на все состояния, версионирования и человека, который всё это поддерживает. Это правда нужно, когда над продуктом работает команда дизайнеров и десятки экранов. Если вы делаете продукт один или вдвоём, полноценная дизайн-система по всем канонам — это работа на месяц, которая не окупится. А вот файл на пять экранов окупается на первом же лендинге.

Примеры дизайн-систем: гайдлайны Apple, Google и IBM, которые можно открыть прямо сейчас

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

Все ссылки ниже я проверила, они открываются без регистрации.

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

Material Design 3 от Google — самая подробная публичная система. Главное, что стоит унести: идея токенов, то есть именованных значений. Не «синий», а «цвет основного действия» — и тогда цвет можно поменять в одном месте.

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

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

Как создать дизайн-систему с нуля за 0 рублей: промт и пошаговый порядок

Теперь по шагам, как это делаю я. Нужен только чат с нейросетью, никаких платных сервисов.

Шаг 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 — только путь. Скопируете палитру туда — получите две версии правды, и через месяц они разойдутся.

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

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

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

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

Как обновлять дизайн-систему, чтобы она не устарела через месяц

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

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

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

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

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

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

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

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

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

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

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

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

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

Как использовать дизайн-систему в работе: карусель и баннер

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

Задача 1: карусель для соцсетей

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

С системой:

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

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

Освободившееся внимание уходит в качество: я думаю про смысл слайдов, а не вспоминаю, какой там был оттенок.

Задача 2: баннер к статье в медиа

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

Запрос:

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

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

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

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

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

С чего начать сегодня

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

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

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

Частые вопросы

Что такое дизайн-система простыми словами? Это записанные правила, по которым собирается весь визуал продукта: какими цветами вы говорите, какими шрифтами, с каким шагом отступов и чего не делаете никогда. Плюс готовые элементы, если они есть. Смысл в том, чтобы решение принималось один раз и потом просто применялось, а не придумывалось заново на каждом макете.

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

Можно ли собрать дизайн-систему без дизайнера? Записать правила и потом безупречно их повторять нейросеть может — и это большая часть работы. А вот придумать, что именно должно стать лицом продукта, она не умеет: у неё нет вкуса, у неё есть только ваши правила. Поэтому реалистичная схема такая: айдентику придумываете вы (или дизайнер), а файл с правилами и всё повторяющееся применение — нейросеть.

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

Где хранить файл, чтобы нейросеть его учитывала? В папке проекта обычным markdown-файлом, а ссылку на него — в файле инструкций, который ассистент читает всегда (CLAUDE.md или AGENTS.md). Важно указать не только «файл есть», но и момент: перед созданием любого визуала — прочитать. Работаете в браузерном чате — положите файл в проект с инструкциями, чтобы не прикладывать его каждый раз.

Как называется дизайн-система Apple? Она называется Human Interface Guidelines (HIG) — публичный документ, открытый без регистрации. У Google аналог называется Material Design (актуальная версия — Material 3), у Atlassian и IBM — свои системы, Atlassian Design System и Carbon. Смотреть их полезно не ради копирования, а ради логики: как формулируют правило, чтобы его нельзя было понять двояко.

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

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

Я собираю такие рабочие штуки под свои задачи постоянно — маркетинг, аналитику, контент веду на AI-агентах. Если хочется научиться так же, у меня есть курс по AI-маркетингу, первые два модуля бесплатные.