Дизайн-система: как я руководила командой

Контекст

Тут я расскажу, как я вела дизайн-систему интернет-банка БСПБ: 60+ компонентов, две темы, один язык на всю продуктовую команду.

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

Самая частая ошибка, как по мне, — начинать с кнопок. В системе четыре группы переменных: Palette, Colors, Spacing и Corner radii. Каждый токен описан сразу в двух значениях — PWA Day и PWA Night. Отдельной «тёмной версии макета» не существует: если дизайнер собрал экран на токенах, тёмная тема у него уже есть.

Самое важное открытие за время работы с системой: у документации не один пользователь, а два. Дизайнер и разработчик приходят в библиотеку за разным. Поэтому у нас каждый раздел явно помечен: for designers, for dev, for dev / designers.

Как устроена палитра

Первый слой Palette. Это просто цвета бренда, закодированные числами: 100, 200, 300 и так далее, где 100 — самый светлый оттенок. Всё, что меньше 100, — цвета с прозрачностью.

Зачем? Чтобы дизайнер никогда не держал в голове #245077. Человек не должен запоминать хексы — он должен запоминать логику. Dark blue/700 читается и проверяется глазами за секунду, а #10385C — нет.

Второй слой Colors. И вот здесь принципиальное решение: палитра разбита не по компонентам, а по сущностям — text, icon, bg, button, border.

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

Переименование, которое всё починило

Отступы и скругления у нас построены на модульной единице: 1 модуль = 8 × 8 px. Размеры получаются умножением модуля на целые числа и на кратные 0,5: 8 × 2 = 16 px, 8 × 0,5 = 4 px.

Изначально токены назывались футболочными размерами: XS, S, M, L, XL, 2XL. Выглядит знакомо — и работает плохо. «XL» ничего не говорит о величине: чтобы понять, что это 20 px, надо лезть в таблицу. А ещё футболочная шкала заканчивается: после 5XL начинается фантазия.

Мы перешли на модульные имена: XS теперь 0,5m, L теперь 2m, 3XL теперь 4m. Теперь имя токена — это и есть его математика. 3m — значит три модуля, значит 24 px. Шкалу можно продолжать бесконечно, и она остаётся предсказуемой.

Та же логика — в радиусах. Но здесь я пошла дальше и зафиксировала зависимость радиуса от высоты компонента:

Это моя любимая часть системы, и вот почему. Хорошая дизайн-система не просто даёт набор значений — она снимает с дизайнера решение, которое не нужно принимать. Вопрос «какое тут скругление?» больше не обсуждается на ревью. Есть высота — есть ответ.

Компонент — это документ

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

• Атомы — мельчайшие базовые строительные блоки
• Спецификация — все состояния, структура и варианты использования
• Темизация — то, как компонент выглядит в тёмной теме
• Карточка A11y — атрибуты доступности

Паттерны: формат чисел

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

Проблема

В банке цифры повсюду: цены, суммы транзакций, бонусы, проценты, статистика. Пока правила не описаны, каждая команда придумывает своё оформление:

• где-то всегда показывают две копейки — 200,00 ₽
• где-то дробную часть для целых сумм скрывают — 200 ₽
• плюсы и минусы ставят по-разному — +200 ₽ и 200+ ₽
• проценты пишут с тремя знаками 3,000% или совсем без них 3%

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

Что я сделала

1. Разобрала сценарии. Нашла все точки, где в продукте появляются числа: поля ввода, отчёты, уведомления, графики. Выделила типы: валюта (₽, $, €), проценты, целые количества бонусов и очков, технические метрики и статистика.

2. Описала правила для каждого типа.

3. Довела до кода. Вместе с разработчиком мы подготовили пресеты форматирования — конфиги Intl.NumberFormat для каждого типа числа. И вот это, на мой взгляд, ключевой момент всего кейса. Задокументировала в гайде в дизайн-системе: таблицы пресетов и примеры «до/после».

Итог: числа перестали быть вопросом вкуса конкретной команды. Дизайнер не выбирает формат — он выбирает тип числа.

Что я вынесла

Хорошая система убирает решения, а не добавляет опции. Таблица «высота → радиус», одна тень, ограниченный список типов токенов. Каждый раз, когда я закрываю вопрос правилом, команда получает обратно немного внимания на действительно сложные задачи.

И да! Быть одновременно владельцем и пользователем системы — лучший режим отладки. Я вела лояльность и накопления на этой же библиотеке.