Дизайн-система — с чего начать, если интерфейсы теперь собирает ещё и ИИ

Дизайн-система — это записанные решения о том, как устроен интерфейс: цвета, шрифты, отступы, компоненты и правила, когда что применять. Заводить её стоит, когда экраны делают больше двух-трёх человек или продукт живёт сразу на сайте и в приложении. Начинать стоит с десятка токенов, десятка компонентов и одной страницы правил. Библиотека на двести компонентов подождёт. А в 2026 году всё это стало срочнее: интерфейсы теперь собирает ИИ, и если правил нет, он придумает свои.

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

Многое из того, что гордо называют дизайн-системой, на деле — UI-кит. Красивая страница в Figma: кнопки трёх размеров, поля ввода, карточки. Это полезно, но это словарь без грамматики. Слова есть, а как из них строить предложения — каждый решает сам.

Система устроена слоями. Внизу — дизайн-токены (design tokens): именованные значения вроде «фон страницы» или «цвет ошибки». Над ними — компоненты, собранные только из токенов. Ещё выше — паттерны: как из компонентов собрать форму, пустое состояние, таблицу. И на самом верху — правила: почему здесь модальное окно, а здесь отдельная страница.

Когда дизайн-система нужна, а когда рано

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

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

Проверьте, где вы сейчас:

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

Дизайн-система и ИИ: почему в 2026 её читает не только человек

Раньше читателем системы был дизайнер или разработчик. Теперь рядом с ними сидит модель — чат-ассистент в редакторе кода или ИИ-агент, который сам собирает экраны. Читает она быстрее, а понимает буквальнее.

По отчёту zeroheight за 2026 год, где опросили 147 специалистов по дизайн-системам, с ИИ экспериментируют уже 46% команд против 36% годом раньше, а не пользуются им 44% вместо 54%. Среди тех, кто пользуется, 71% генерируют с его помощью код, 60% — документацию. А больше всего практиков пугает генерация дизайна: её назвали 61%.

Страх понятный. Без контекста модель собирает «средний интерфейс из интернета». В отчёте Figma за 2025 год 78% опрошенных согласились, что ИИ ускоряет их работу, но полагаться на результат могут только 32%. Разрыв между скоростью и доверием закрывает контекст. А лучший контекст для интерфейса — дизайн-система.

Рынок это уже понял. MCP-сервер Figma отдаёт ИИ-агенту переменные, компоненты и связи макетов с кодом, чтобы тот собирал экраны из ваших деталей, а не из своих. Открытая дизайн-система Яндекса Gravity UI обзавелась файлом llms.txt и навыком для ИИ-ассистентов. А Nielsen Norman Group в статье об эпохе уборки за ИИ прямо советует дать модели дизайн-систему и утверждённые паттерны, чтобы она собирала интерфейс из «законных» деталей.

Есть и обратная сторона. Nielsen Norman Group в обзоре состояния UX на 2026 год предупреждает: дизайнера, который просто собирает экраны из компонентов системы, ИИ уже может заменить. Система снимает рутину, и тем заметнее становится работа, которую она не делает, — решения.

С чего начать дизайн-систему: первые шаги

1. Проведите опись. Сделайте скриншоты всех экранов продукта и разложите одинаковые элементы рядом: кнопки, поля, заголовки, цвета. Когда на одном листе лежат дюжина оттенков серого и пять разных кнопок «Отправить», команду не нужно убеждать презентацией.
2. Заведите токены. Цвета, шрифты, размеры, отступы, скругления — с именами по смыслу: «фон», «текст второстепенный», «ошибка». Что значит «серый 3», через год не вспомнит никто. Одни и те же имена в макетах и в коде.
3. Соберите десяток базовых компонентов. Кнопка, поле ввода, выпадающий список, чекбокс, карточка, модальное окно, уведомление, таблица. Только из токенов, со всеми состояниями — наведение, ошибка, загрузка, пустое.
4. Напишите страницу правил. Каждую кнопку описывать не нужно, запишите решения: когда основная кнопка, когда второстепенная; когда модалка, когда отдельный экран; как пишем ошибки. Короткими фразами, которые поймёт и новичок, и модель.
5. Свяжите макет и код. Компонент в Figma и компонент в коде должны называться одинаково и иметь одни и те же варианты. Без этого система раздваивается в первый же месяц.
6. Дайте системе исполнимые правила. Проверка кода, которая не пропускает цвет мимо токенов, и папка эталонных экранов, собранных правильно. Модели учатся на примерах лучше, чем на длинных текстах с правилами.
7. Назначьте владельца и порядок изменений. Кто решает, что новый компонент попадает в систему, и как об этом узнают остальные. Хватит одного человека на полставки — но он должен быть.

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

Шестой шаг выглядит инженерной мелочью, но для работы с ИИ он главный. В блоге Builder.io это сформулировали коротко: ваша кодовая база и есть ваш промпт. Агент повторяет то, что видит в коде, даже если документ с правилами говорит другое.

Как понять, что дизайн-система работает

Худшая метрика — число компонентов. Библиотека на триста элементов, которой никто не пользуется, стоит дороже, чем её отсутствие.

По тому же отчёту zeroheight полностью внедрена во всех командах система только у 7% опрошенных. Внедрение отслеживают 41%, а окупаемость считают всего 5%. То есть почти все строят системы, и почти никто не знает, окупились ли они.

Смотреть стоит на три вещи:

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

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

Договорённости, у которых появился читатель

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

Поэтому первый шаг к дизайн-системе делают ещё до Figma. Это вопрос: какие решения мы принимаем снова и снова и почему до сих пор принимаем их каждый раз заново?