80
Переменные ради переменных не делают систему
Иногда открываешь файл в фигме и сначала кажется, что все окей. Стили есть, переменные есть, компоненты собраны, где-то даже UI kit лежит. То есть визуально проект как будто сделан не на коленке. Но потом начинаешь менять что-то простое и понимаешь, что вся эта система работает только пока ее не трогают.
Вот это, по-моему, главный маркер. Не количество переменных и не то, насколько красиво названы страницы в файле. А можно ли спокойно внести изменение и заранее понимать, что именно оно затронет. Условно, в системе есть цвет для border, но по ходу проекта его начали использовать не только на бордерах, а еще на иконках, фонах, да и вообще где попало, сроки же горят. И конечно же наступает момент, когда прилетает маленькая правочка, что-то в духе “а давайте бордер у инпутов сделаем чуть поярче”. И дергаешь ты такой за ниточку, а у тебя ломается абсолютно всё.
Поэтому переменная или стиль должны появляться не из логики “пусть будет, вдруг пригодится”, а из понимания, какую роль она будет выполнять в интерфейсе. Есть примитивы вроде условных gray/100, gray/500, blue/600. Они просто хранят значения. А есть семантические токены, которые описывают роль: фон, текст, бордер, иконка, кнопка и тд. Состояние при этом не отдельная сущность в вакууме, а уточнение внутри роли или компонента: default, hover, pressed, disabled, error. Тогда название не просто красивое, а реально объясняет, где этот токен можно использовать и что произойдет, если его поменять.
Эта же проверка быстро чистит текстовые стили. Если в файле лежит Body/M в пяти начертаниях, но в интерфейсе реально используются два, остальные стили не делают систему сильнее. Они только добавляют шум. Следующему дизайнеру придется гадать, это осознанные стили или кто-то просто создал все варианты “на всякий случай”. Лучше иметь меньше стилей, но чтобы было понятно: вот основной текст, вот подпись, вот заголовок, вот вспомогательная штука. Тогда человек не выбирает на вкус из мусорной корзины, а продолжает понятную логику.
С сеткой такая же история: она должна помогать собирать интерфейс, а не просто лежать сверху для ощущения порядка. Можно нарисовать grid и ни разу по-настоящему им не пользоваться. Или наоборот, начать подгонять контент под случайную сетку, хотя сам контент просит другую структуру. Для меня нормальный подход тут простой: сначала понять, какие блоки и секции будут в интерфейсе, по каким правилам они будут жить (ваер в помощь), а потом уже собирать сетку под эту логику. Не сетка определяет дизайн сама по себе, а контент помогает понять, какая сетка вообще нужна.
По сути проверка довольно простая: перед тем как создавать новый стиль, переменную или правило, стоит спросить себя не “как это назвать”, а “каким изменением это должно управлять?”. Если ответа нет, скорее всего, ты создаешь сущность ради сущности. Она может выглядеть профессионально в моменте, но потом станет мусором, который кто-то будет разгребать.
Понятно, что не в каждом проекте нужна огромная дизайн-система. Иногда достаточно аккуратного UI kit, нормальных стилей и понятной логики. Но даже маленький файл должен быть собран так, чтобы его можно было продолжить без автора рядом. Потому что проект может попасть к другому дизайнеру или другой команде. И они будут смотреть не только на то, красивый ли экран, а на то, можно ли с этим дальше работать.
Для меня гигиена в фигме это не душнота и не фетиш на порядок. Это часть проф ответственности. Если после тебя файл можно поддерживать, значит ты думал не только о картинке. Если без тебя он превращается в угадайку, значит никакой системы там не было.
