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

Зачем это нужно команде без штата дизайнеров

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

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

С чего начать: токены, а не компоненты

Соблазн — сразу рисовать красивые кнопки. Правильнее начать с основ, на которых всё держится. В Figma это переменные (variables) и стили:

  1. Цвета. Заведите палитру с осмысленными именами — не «синий-2», а «primary», «text», «surface». Это позволит позже добавить тёмную тему одним переключением.
  2. Типографика. Ограничьтесь несколькими размерами заголовков и тела текста. Меньше вариантов — меньше хаоса.
  3. Отступы и сетка. Договоритесь о шаге (например, кратном 4 или 8) и используйте только его.

Токены — это фундамент. Компонент, собранный на случайных значениях, придётся переделывать; компонент на токенах меняется централизованно.

Какие компоненты собрать первыми

Не пытайтесь покрыть всё. Соберите то, что встречается на каждом экране:

  • кнопки в основных состояниях (обычная, нажатая, неактивная);
  • поля ввода;
  • карточку контента;
  • навигацию или шапку.

Используйте варианты (variants) Figma, чтобы держать состояния одного элемента в одном компоненте, а не плодить копии.

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

Большая команда пишет подробные гайдлайны. Маленькой достаточно одной страницы в файле: палитра с названиями, шкала шрифтов, примеры компонентов и пара правил «как мы делаем». Этот лист открывают перед началом работы — и разнобой исчезает сам собой.

Как не дать системе устареть

Главная угроза маленькой дизайн-системы — её забрасывают. Чтобы этого не случилось:

  • назначьте одного человека ответственным за библиотеку;
  • правьте компонент в библиотеке, а не локально в макете;
  • раз в спринт сверяйтесь, не расползлись ли стили;
  • удаляйте то, чем перестали пользоваться.

Когда расширять

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

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