Дизайн-система для маленькой команды

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

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

Начни с токенов

Токены — это именованные значения: цвета, отступы, радиусы, размеры шрифта, тени. Вместо #6B7280 в коде пишется --text-muted, вместо 12px — --space-3.

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

Что заводить в первую очередь:

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

:root {
  --bg: #ffffff;
  --surface: #f6f6f7;
  --text: #111113;
  --text-muted: #6b6b73;
  --border: rgb(0 0 0 / 0.08);
  --accent: #111113;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --radius-sm: 4px;
  --radius-md: 8px;
}

Тёмная тема и смена акцента после этого обходятся почти бесплатно.

Десяток компонентов, а не сотня

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

Остальное заводи, когда что-то встретилось в третий раз. Первый раз — сделай на месте. Второй — заметь. Третий — вынеси в компонент.

Состояния важнее вариантов

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

Именно состояния чаще всего забыты в сгенерированном коде: на демо всё загружается мгновенно, и ошибок не бывает.

Как не дать дизайну и коду разойтись

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

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

Если пишешь код с ИИ, положи ему в контекст файл с токенами и список компонентов и попроси пользоваться только ими. Нового серого станет заметно меньше.

Чего не делать

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

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

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