Дизайн-система, которая доживает до второго проекта

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

Дизайн-система — это продукт, а не папка

Главная ошибка — считать дизайн-систему складом компонентов. Склад не имеет пользователя, а продукт имеет. У дизайн-системы пользователь — это разработчик, который собирает из неё интерфейс. И если ему быстрее написать свою кнопку, чем найти и понять вашу, — система проиграла, сколько бы компонентов в ней ни лежало.

Из этого следует всё остальное. У продукта есть документация — поэтому Storybook или живая страница со всеми состояниями компонентов не приятный бонус, а условие выживания. У продукта есть обратная связь — поэтому система должна расти из реального использования, а не из фантазии о том, что когда-нибудь понадобится.

Компонент — единица смысла

Я придерживаюсь простого правила: компонент существует не потому, что «здесь нужен ещё один блок разметки», а потому что отвечает за конкретный смысл — карточка, поле, состояние загрузки. Это звучит банально, но именно нарушение этого правила убивает системы. Когда компоненты режутся по визуальному признаку («сделаем универсальный контейнер с двадцатью пропсами»), получается монстр, который невозможно ни понять, ни переиспользовать. Когда они режутся по смыслу — система остаётся читаемой по мере роста.

Хороший компонент честен про свои состояния. Загрузка, пустота, ошибка, успех — это не «крайние случаи, добавим потом», а часть его определения. Систему, в которой состояния заданы явно, не страшно собирать; систему, где каждый экран изобретает обработку ошибки заново, страшно трогать.

Где я ошибался

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

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

Путал «сделал» с «прижилось». Собрать библиотеку — половина дела. Вторая половина — чтобы команда в неё поверила и в неё пошла. Это работа не про код, а про людей: ревью, онбординг, готовность объяснять одно и то же. Систему принимают не тогда, когда она технически хороша, а тогда, когда ей доверяют.

Признак здоровой системы

Я для себя свёл его к одному: разработчику быстрее взять из системы, чем сделать самому, — и он это знает. Всё остальное — Storybook, токены, версии, документация — лишь средства добраться до этого состояния. Если средство не приближает к нему, оно лишнее.

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