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

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

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

Что на самом деле представляет собой дизайн-система

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

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

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

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

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

Неудача 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 пропсами не является гибкой. Она хрупкая. Вместо того чтобы создавать мега-компонент, который обрабатывает каждый вариант через пропсы, создавайте небольшие компонуемые части, которые объединяются в паттерны. Карточка — это не один компонент. Это контейнер карточки, заголовок карточки, тело карточки и футер карточки, которые компонуются вместе.

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

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

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

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

Паттерны, которые следует документировать на ранних этапах:

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

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

Управление способствует или препятствует внедрению

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

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

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

Часто задаваемые вопросы

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

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

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

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

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

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

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

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