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

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

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

Когда дизайн-система действительно нужна

Не по размеру компании, а по симптомам. Пора, если вы узнаёте себя хотя бы в трёх пунктах:

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

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

UI kit или дизайн-система: в чём разница

Этот вопрос задают чаще всего, и граница между понятиями действительно размыта. Я различаю их так.

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

Хорошая новость: путь от первого ко второму эволюционный. Начните с UI kit, а правила и связь с кодом добавляйте по мере того, как команда на них упирается.

Минимальный набор: с чего начать

Главная ошибка начала — пытаться описать всё. Я собираю систему в три слоя: токены, базовые компоненты, состояния.

Токены: цвет, типографика, отступы

Токен — это именованное значение. Вместо «#2F5BFF» у вас «color/brand/primary». Название говорит о роли, а не о внешнем виде. Благодаря этому смена бренда или тёмная тема сводится к замене значений в одном месте.

• Цвет. Основной цвет, нейтральные (текст, границы, фоны) и системные: успех, предупреждение, ошибка. Для каждой пары «текст на фоне» проверяйте контраст: по WCAG 2.2 для обычного текста нужно не меньше 4.5:1, для крупного текста и границ элементов управления — 3:1.
• Типографика. Один шрифт, небольшая шкала размеров: заголовки двух-трёх уровней, основной текст, мелкий текст. Для каждого стиля заданы размер, межстрочный интервал и начертание.
• Отступы. Единая сетка кратных значений, например с шагом 4 или 8 пикселей. Я беру 4: он достаточно гибкий для плотных интерфейсов. Дальше все отступы и размеры берутся только из этой шкалы.
• Радиусы и тени. Два-три радиуса и одна-две тени. Больше обычно не нужно.

Базовые компоненты

Начинайте с того, что встречается почти на каждом экране:

• кнопки (основная, вторичная, текстовая, опасное действие);
• поля ввода, выпадающие списки, чекбоксы, переключатели;
• ссылки, теги, уведомления;
• карточки и модальные окна;
• навигация: меню, вкладки.

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

Состояния

Именно здесь «красивые макеты» превращаются в рабочий продукт. У каждого интерактивного компонента должны быть описаны:

• обычное, наведение, фокус, нажатие, отключённое;
• для полей: заполненное, ошибка, успех;
• для экранов и списков: загрузка, пустое состояние, ошибка загрузки.

Состояние фокуса часто забывают, а оно нужно всем, кто работает с клавиатуры. Пустые экраны и ошибки забывают ещё чаще, и разработчику приходится придумывать их самому. Многие из таких пробелов потом всплывают на UX-аудите.

Дизайн-система — это продукт для команды. У неё тоже есть пользователи.

Figma: библиотека и переменные

Если вы ищете, как сделать дизайн-систему в Figma, порядок у меня такой.

1. Отдельный файл для библиотеки. Не складывайте компоненты в файл с макетами. Библиотеку подключают к проектам как общий источник.
2. Переменные. Figma позволяет хранить цвета, числа, строки и булевы значения как переменные. Заведите коллекции: цвета, отступы, радиусы. Для цветов используйте режимы: светлая и тёмная тема переключаются одним действием.
3. Два уровня переменных. Сначала «сырые» значения (палитра), затем смысловые, которые на них ссылаются: «text/primary» указывает на конкретный оттенок. Компоненты используют только смысловые.
4. Стили текста. Соберите шкалу как текстовые стили, чтобы не задавать размеры вручную.
5. Компоненты с вариантами. Кнопка — один компонент со свойствами: тип, размер, состояние, наличие иконки. Не десятки отдельных копий.
6. Auto layout везде. Компонент должен корректно растягиваться под длинный текст, иначе в продукте он сломается на первой же реальной подписи.
7. Описания и порядок. Понятные названия, страницы по разделам, пометки о статусе: готово, в работе, устарело.

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

Связь с кодом

Дизайн-система, которая живёт только в Figma, работает наполовину. Реальная польза появляется, когда дизайнер и разработчик говорят об одном и том же.

Минимальная связь строится на трёх вещах:

• Одинаковые названия. Компонент «Button» в Figma — это «Button» в коде, свойства и варианты называются так же. Токен «color/text/primary» превращается в CSS-переменную с понятным соответствием.
• Токены как единый источник. В вебе их обычно выражают через CSS custom properties. Если токенов много и они часто меняются, помогает выгрузка из Figma через плагины или инструменты вроде Style Dictionary и Tokens Studio. Для маленькой команды можно начать вручную: таблица значений, которую поддерживают оба.
• Общий список компонентов. Простая таблица: что есть в дизайне, что реализовано в коде, чего нет. Она сразу показывает расхождения.

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

Документация, владелец и поддержка

Документация

Достаточно короткой. Для каждого компонента: зачем он нужен, когда использовать и когда нет, какие у него состояния, пример правильного и неправильного применения. Хранить можно прямо в Figma рядом с компонентом или в любой вики, которой команда уже пользуется. Главное, чтобы документ нашёлся за минуту.

Владелец

У системы должен быть один ответственный человек. Это не обязательно отдельная должность: часто это дизайнер с частью времени на поддержку. Его задачи простые: принимать запросы на новые компоненты, следить за порядком и решать спорные вопросы. Если ответственных «все», то на практике за систему не отвечает никто.

Как не утонуть в поддержке

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

Когда система не нужна

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

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

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

Частые ошибки

• Слишком большой старт. Дизайнер полгода собирает идеальную систему, а продукт тем временем живёт без неё. Начинайте с того, что используется чаще всего.
• Названия по внешнему виду. «Синяя кнопка» перестаёт быть синей после ребрендинга. Называйте по роли.
• Нет владельца. Система обрастает копиями и исключениями.
• Дизайн и код разошлись. В Figma одно, в продукте другое, и никто не знает, какой вариант считать эталоном.
• Нет состояний. Компонент нарисован только в «обычном» виде, остальное достраивается на лету.
• Компонент на каждый случай. Если у кнопки сорок вариантов, это уже не система. Лучше сократить число вариантов, чем описывать каждое исключение.
• Система делается ради системы. Если за ней нет понятной задачи (быстрее выпускать экраны, меньше правок после передачи в разработку), её перестанут использовать. Как объяснить пользу руководителю, я описывал в статье про разговор с бизнесом о дизайне.

Чек-лист: как создать дизайн-систему с нуля

1. Определите, зачем она нужна: какую проблему команды решаете.
2. Соберите существующие экраны и выпишите, какие элементы повторяются.
3. Выберите основной цвет, нейтральные и системные цвета, проверьте контраст.
4. Задайте шкалу типографики и шаг отступов.
5. Заведите переменные в Figma: палитра и смысловые токены.
6. Соберите базовые компоненты с вариантами и auto layout.
7. Нарисуйте состояния: наведение, фокус, ошибка, отключённое, загрузка, пустой экран.
8. Согласуйте названия с разработчиком.
9. Напишите короткую документацию для каждого компонента.
10. Назначьте владельца и договоритесь, как добавлять новое.
11. Перенесите в систему один живой экран и посмотрите, что не хватает.
12. Раз в месяц делайте ревизию.

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

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