Figsight #16: The Kit Testament

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

Фигма — инструмент для дизайнера. Не для разработчика, не для технического перфекциониста, не для библиотекаря. Для дизайнера. И, кажется, мы об этом начали забывать.
Фраза «компонент должен быть сделан так, как в коде» звучит почти как догма. Но если вдуматься — кому от этого действительно лучше? Компонент собирается один раз. Десятки дизайнеров потом используют его в сотнях макетов. И если кто-то должен подстраиваться — точно не они.

В стремлении к единообразию, кит часто превращают в карающий меч системности: одна библиотека — один компонент, все состояния в одном месте, технические названия, мусор из переменных, системные компоненты, которые никто не трогает. Всё во имя порядка. А это вообще удобно? Сколько дизайнеров реально благодарили вас за такие библиотеки?
Все должны говорить на одном языке — но пусть это будет язык здравого смысла и UX. Документация — пусть будет строгой. Но фигма — пусть будет человечной.

Атомарный подход — это прекрасно. В теории. На практике он слишком часто мешает. Кнопка для дизайнера не может быть на разных уровнях иерархии при различном наполнении. Дропдаун — это такой же базовый элемент интерфейса как и поле ввода. Эта методика направленна прежде всего на проектирование и на разработку в коде. Дизайнеры мыслят интерфейсами, не атомами.

Дизайнеру не нужно знать про спецификации псевдо-классов, названия токенов или про ограничения стейтов. Компонент должен быть простым и удобным. Нужен loading? Держи loading! Хочешь другой цвет? Если палитра не даёт дизайнеру сделать это, то это плохая палитра, хоть она и вылизана по OKLCH. И если дизайнер детачит ваш технически безупречный компонент — может быть, проблема не в дизайнере?

Работа разработчиков кита не менее важна, но с ними всегда можно договорится — собрать все состояния компонента отдельно, упростить структуру, описать в документации, всё что им понадобится. Но не ломать удобные компоненты для дизайнеров. Если можно сделать удобно и правильно — делайте. Если нельзя — выберите сторону дизайнера.

Дизайнер не использует все состояния компонента? Так и не надо их втискивать в него. Оставьте их в документации или соберите технический компонент в запас. Называйте элементы понятно, теггируйте, если нужно, и скрывайте всё, что не помогает работать: системные палитры, технические токены, лишние шрифты, неиспользуемые состояния.

Всё, о чём мы говорили выше — это не призыв отказаться от порядка или системности. Это напоминание: фигма — в первую очередь про людей, а не про технику. И ответ для чего вообще нужен Figsight.