Пока продукт состоит из десятка экранов, единый стиль держится на памяти команды. Когда экранов становится сотни, а над ними работают несколько дизайнеров и разработчиков, память перестаёт справляться: кнопки отличаются на два пикселя, оттенков серого набирается полтора десятка, одна и та же форма ведёт себя по-разному в двух разделах. Дизайн-система — это способ вынести договорённости из головы в общий и проверяемый набор правил. Разберём, из чего она состоит, как её собирать и что делает её живой, а не красивой презентацией.
Когда дизайн-система нужна, а когда достаточно UI-кита
Дизайн-система стоит времени, поэтому начинать её имеет смысл не всегда. Мы ориентируемся на несколько признаков: над интерфейсом работает больше одного дизайнера, продукт живёт дольше года и продолжает развиваться, есть несколько платформ или несколько продуктов одной компании, а на согласование мелких решений регулярно уходит больше времени, чем на сами решения.
Если продукт небольшой и меняется редко, хватает библиотеки стилей и набора готовых макетов. Разница простая: UI-кит отвечает на вопрос «как это выглядит», дизайн-система дополнительно отвечает на вопросы «когда это использовать», «как оно себя ведёт» и «кто и как вносит изменения».
Из чего состоит дизайн-система
Мы описываем систему уровнями, от нижнего к верхнему. Такой порядок удобен тем, что каждый следующий уровень опирается на предыдущий и не может существовать без него.
| Уровень | Что в него входит | Признак, что уровень не готов |
|---|---|---|
| Токены | Цвета, шрифты, размеры, отступы, радиусы, тени, тайминги анимаций | В макетах встречаются произвольные значения, подобранные на глаз |
| Компоненты | Кнопки, поля, переключатели, таблицы, модальные окна, уведомления | Один и тот же элемент собран заново в каждом макете |
| Паттерны | Формы, фильтры, пустые состояния, ошибки, загрузка, пагинация | В каждом разделе своя логика подтверждения и своя обработка ошибок |
| Правила | Тон текстов, работа с ошибками, доступность, поведение на узких экранах | Формулировки в интерфейсе противоречат друг другу |
| Процесс | Как вносятся изменения, кто согласует, как выходят версии | Компоненты правят напрямую, команда узнаёт об изменениях случайно |
Чаще всего проекты застревают на втором уровне: библиотека компонентов собрана, а правил и процесса нет. Через несколько месяцев такая библиотека расходится с продуктом и превращается в архив.
Аудит интерфейса: с чего мы начинаем
Первый шаг — не рисование, а инвентаризация. Мы собираем снимки всех экранов и раскладываем по группам: все кнопки в одну, все поля ввода в другую, все карточки в третью. На этом этапе обычно выясняется, что вариантов элемента в продукте гораздо больше, чем предполагала команда.
- Сколько на самом деле используется цветов, размеров шрифта и величин отступов.
- Какие элементы решают одну задачу разными средствами и могут быть объединены.
- Какие состояния нигде не проработаны: ошибка, загрузка, пустой список, длинный текст, отсутствие прав.
- Что из этого встречается на большинстве экранов, а что было сделано один раз под конкретную задачу.
Результат аудита — список кандидатов в базовые компоненты и понимание, где расхождения болезненны, а где ими можно пока пренебречь.
Токены: основа, с которой всё связывается
Токены — это именованные значения вместо конкретных чисел и кодов цвета. Вместо конкретного оттенка в макете стоит имя роли: цвет основного действия, цвет фона поверхности, цвет текста второго уровня. Такой подход даёт две вещи. Во-первых, смена оттенка перестаёт быть ручным перебором макетов. Во-вторых, появляется возможность собрать вторую тему — тёмную или брендовую — без переделки компонентов.
Мы советуем разделять токены на базовые и смысловые. Базовые описывают палитру и шкалу размеров, смысловые ссылаются на базовые и описывают назначение. Тогда изменение палитры не ломает смысл, а изменение смысла не требует новой палитры.
Компонентная библиотека: что включать и как описывать
Компонент попадает в библиотеку не потому, что он удачно выглядит, а потому, что он повторяется и его поведение можно описать. Для каждого мы фиксируем набор свойств, все состояния и границы применения.
- Назначение: какую задачу компонент решает и чем отличается от соседнего похожего.
- Свойства: размеры, варианты оформления, наличие иконки, ширина по содержимому или по контейнеру.
- Состояния: обычное, наведение, фокус, нажатие, отключено, загрузка, ошибка.
- Поведение на разных ширинах экрана и при длинном тексте.
- Требования доступности: контраст, размер зоны нажатия, работа с клавиатуры, подписи для программ чтения с экрана.
- Примеры уместного и неуместного применения — короткие, с пояснением почему.
Компоненты, у которых нет второго применения, в библиотеку не берём. Преждевременное обобщение вредит не меньше, чем его отсутствие: универсальный компонент с двумя десятками свойств никто не использует, потому что проще собрать свой.
Как связать макеты и код
Дизайн-система приносит пользу, когда одно и то же название означает одно и то же в макете и в разметке. Мы добиваемся этого простыми средствами: общий словарь имён для токенов и компонентов, выгрузка токенов в переменные стилей, отдельная страница с живыми компонентами, где их можно посмотреть в браузере во всех состояниях.
Полезно договориться и о том, что считается источником истины. Если это макеты, любое изменение в коде без правки макета — расхождение. Если код, дизайнер работает от того, что реально собрано. Оба варианта рабочие, плох только третий, когда источника истины нет вовсе.
Что поддерживает систему в рабочем состоянии
Система живёт, пока у неё есть владелец и понятный порядок изменений. Минимальный набор договорённостей выглядит так: изменения вносятся через запрос, у библиотеки есть версии, о заметных правках команда узнаёт из короткого списка изменений, а несовместимые правки выходят отдельно и с предупреждением.
- Регулярная сверка макетов с продуктом: раз в один-два месяца проверяем, не появились ли элементы вне системы.
- Автоматические проверки в сборке: контраст, использование токенов вместо произвольных значений, наличие подписей у интерактивных элементов.
- Визуальные тесты компонентов, чтобы правка базового элемента не ломала соседние экраны незаметно.
- Короткая инструкция для новых участников команды: где лежит система, как ей пользоваться, как предложить изменение.
Ошибки, из-за которых системы перестают работать
Самая частая — собрать библиотеку разом, силами отдельной команды, без участия тех, кто ей будет пользоваться. Такую систему обходят стороной. Мы предпочитаем расти от реальных задач: сначала токены и пять-шесть самых частых компонентов, затем то, что востребовано ближайшими задачами.
Вторая ошибка — считать систему документом. Документ устаревает через месяц, а система должна быть встроена в инструменты, которыми команда пользуется каждый день. Третья — запрещать всё, что в систему не входит. Продукту нужны исключения, важно лишь, чтобы они фиксировались и периодически пересматривались: часть из них со временем становится полноценными компонентами, а часть отменяется как случайность.
Если нужно навести порядок в интерфейсе продукта или собрать дизайн-систему с нуля, мы можем взять эту работу на себя — от аудита текущих экранов до библиотеки компонентов и правил её развития. Посмотрите, как мы делаем проектирование веб-интерфейсов, и расскажите нам о продукте.
