Дизайн-системы: почему большинство из них проваливается и как построить ту, которая работает

Каждая команда, достигая определённого размера, в какой-то момент произносит одно и то же: «Нам нужна дизайн-система». Потом большинство из них тратит полгода на создание того, чем никто не пользуется, а через год всё возвращается к той же несогласованности, с которой всё началось.

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

Что такое дизайн-система на самом деле

Дизайн-система не является библиотекой компонентов. Библиотека компонентов: папка с переиспользуемыми элементами интерфейса. Дизайн-система: полный набор стандартов, документации и инструментов, которые управляют тем, как продукт проектируется и разрабатывается.

Она включает:

• Дизайн-токены. Атомарные значения (цвета, отступы, типографика, тени), на которые ссылается всё остальное.
• Компоненты. Переиспользуемые элементы интерфейса, построенные на токенах.
• Паттерны. Задокументированные решения повторяющихся дизайн-задач (формы, навигация, состояния ошибок).
• Руководства. Правила того, когда и как использовать каждый элемент.
• Управление. Кто владеет системой, как предлагаются изменения и как принимаются решения.

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

Почему большинство дизайн-систем проваливается

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

Провал 2: Слишком жёсткая с самого начала. Система запускается со строгими правилами для каждого сценария. Дизайнеры и инженеры, сталкивающиеся со случаем, который система не предусмотрела, имеют два варианта: бороться с системой или обойти её. Большинство выбирает обходной путь. Система превращается в справочник, которым никто не пользуется.

Провал 3: Нет выделенного владельца. Система была создана во время спринта. Никто не назначен для её поддержки. Токены расходятся с кодовой базой. Компоненты отстают от продукта. Документация устаревает. Через полгода система представляет собой снимок того, как выглядел продукт в прошлом году.

Провал 4: Мышление «компоненты прежде всего». Команда создаёт 47 компонентов, не определив ни одного токена и не написав ни одного руководства. Компоненты работают в Figma, но ломаются в продакшене, потому что базовые значения так и не были систематизированы.

Провал 5: Паралич перфекционизма. Команда пытается решить каждый крайний случай до запуска чего-либо. Система так и не выходит. Тем временем продукт выпускается ежедневно без неё.

Что объединяет выжившие системы

После изучения систем, которые действительно держатся (Shopify Polaris, Atlassian Design System, IBM Carbon, GitHub Primer), выделяются три паттерна:

Они начинали с малого и росли. Ни одна из них не запускалась с 200 компонентами. Они запускались с токенами, несколькими основными компонентами и чёткой документацией. Затем расширялись на основе реальных потребностей продукта, а не теоретической полноты.

У них есть выделенные команды. Не один человек. Команда. Дизайн-системы в масштабе требуют как минимум дизайнера, инженера, технического писателя и продакт-менеджера. У Shopify над Polaris работают десятки людей. Десятки не нужны, но нужно больше нуля.

Они воспринимают вклад как функцию. Лучшие системы делают так, чтобы продуктовым командам было легко предлагать дополнения, сообщать о проблемах и вносить компоненты. Система растёт с краёв, а не только из центра. Система, которая растёт только на основе решений одной команды, всегда будет отставать от продукта.

Дизайн-токены: настоящий фундамент

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

Уровни токенов:

Глобальные токены определяют необработанные значения. Семантические токены присваивают смысл (основной, опасный, поверхность). Компонентные токены привязывают эти значения к конкретным элементам интерфейса. Эта трёхуровневая структура позволяет сделать ребрендинг, изменив семантические токены, не затрагивая ни одного компонента.

Типы токенов, которые нужно определить в первую очередь:

• Цвета (фон, текст, граница, интерактивные состояния)
• Отступы (сетка 4px: 4, 8, 12, 16, 24, 32, 48, 64)
• Типографика (семейство, шкала размеров, насыщенность, межстрочный интервал)
• Радиус скругления (нет, маленький, средний, большой, полный)
• Тени (уровни возвышения)
• Анимация (длительность, кривые плавности)

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

Построение компонентов, которые выдерживают проверку временем

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

Правила для компонентов, которые выживают:

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

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

Документируйте «когда», а не только «что». Документация по кнопке не должна просто показывать, как она выглядит. Она должна объяснять, когда использовать основную кнопку, когда вторичную, а когда кнопку-призрак. Система принятия решений важнее визуального справочника.

Паттерны решают то, что не могут компоненты

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

Паттерны для ранней документации:

• Макеты форм. Расположение меток, отображение ошибок, обозначение обязательных полей, многошаговые потоки.
• Навигация. Когда использовать вкладки вместо боковой панели или хлебных крошек. Поведение сворачивания мобильной навигации.
• Пустые состояния. Что показывать, когда данных нет. Иллюстрация? Призыв к действию? Обучающий контент?
• Состояния загрузки. Скелетные экраны, спиннеры или прогрессивная загрузка. Когда каждое из них уместно.
• Обработка ошибок. Встроенная валидация, всплывающие уведомления или состояния ошибок на весь экран.

Эти паттерны предотвращают проблему «мы построили одну и ту же форму пятью разными способами», которая преследует команды без системы.

Управление решает судьбу принятия

Дизайн-система без управления: просто предложение. Управление отвечает на три вопроса:

1. Кто решает? Есть ли ревью-борд? Единственный владелец? Демократическое голосование? Что бы вы ни выбрали, сделайте это явным.
2. Как происходят изменения? RFC-процесс? GitHub issue? Тред в Slack? Определите путь от «я думаю, нам нужен новый компонент» до «он есть в системе».
3. Какова стратегия версионирования? Семантическое версионирование для пакета токенов? Changelog для каждого релиза? Политика критических изменений?

Команды, которые пропускают управление, в итоге получают разветвившуюся систему. Дизайн использует версию 2.3. Инженерия использует версию 1.8. Маркетинговый сайт использует версию 2.0 с локальными переопределениями. В этот момент у вас три дизайн-системы и ноль согласованности.

FAQ

Сколько времени занимает построение дизайн-системы?

Первоначальный фундамент (токены, 10-15 основных компонентов, базовая документация) занимает 2-4 месяца при наличии выделенной команды. Но дизайн-система никогда не бывает «завершена». Планируйте постоянные инвестиции в размере 15-25% мощности дизайн-инженерной команды.

Нужна ли маленьким командам дизайн-система?

Да, но соразмерная. Команде из трёх человек не нужен Polaris. Им нужна общая библиотека Figma с токенами, 8-10 основными компонентами и одностраничным руководством по принятию решений. Начните с того, что причиняет наибольшую боль (обычно несогласованные отступы и использование цвета) и развивайте дальше.

В чём разница между дизайн-системой и библиотекой компонентов?

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

Начните с боли, а не с амбиций

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