Хабр Курсы для дизайнеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Дизайн доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
Тема то крутая, но не хватает больше примеров и каких-то частых затыков. Ну и если есть разные степени прозрачности.
Как вы решаете кейс, когда цвет кнопки для hover из примитивов не подходит? Например кнопка gray-100, на hover gray-200 кнопка получается слишком темной. Подбираете gray-200 более светлым? Или делаете другой тип ховера, например через оверлей чёрного с 0.05 opacity?
Ммм, какой классный вопрос. Вообще на фронте, например, в Material используют 5% черного или белого поверх — это экономит токены. Но как поступить дизайнеру дизайн-системы, чтобы продуктовым дизам было удобно? Можно сделать в ховер состоянии кнопки поверх основного фона фрейм, в котором будет 5% черного — но если вариантов много, фигма будет тормозить.
В идеале нужно сделать больше шагов в палитре изначально, чтобы не возникало таких ситуаций в принципе — можно посмотреть на Radix UI — у них 12 шагов контрастности, чего хватит с головой для любых сценариев. Если не подходит прозрачная палитра в каком-то кейсе, то пробуем использовать solid-цвета, и создаем компонентный токен под конкретную ситуацию.
Также, насколько мне известно, в Tokens studio есть модификаторы, которые прям в плагине могут сделать цвет кнопки на 5% темнее, а затем экспортировать полученный цвет в Figma variables как сплошной цвет или прозрачный.
Если бы возникла ситуация, когда не хватает шагов контрастности, то я бы переделывал палитру и токены в рабочее и внерабочее время — сам виноват, что сделал недостаточно))
Я обычно решаю через оверлей. Можно добавить fill прямо поверх основного цвета и тоже токеном.
А в палитре и так 11 цветов, но в них 50 и 950 никак не влияют на основную палитру. Возможно, стоит это пересмотреть) Спасибо за ответ.
Хм, а некоторые цвета же грязнить начинают с черным поверх, например, желтый. Там надо играться с тоном и яркостью, а не просто черный поверх накладывать. Но главный косяк такого подхода — сложно Accessibility/a11y проверять, так как плагины тупят на двойных заливках полупрозрачных. Хотя, надо проверять, вдруг поумнели)) Может, вы тестили?
По идее, чтобы желтый выглядел хорошо, нужно просто создать токен именно для желтого цвета, например, не black 5%, а dark-orange 5% — сейчас проверил, реально работает) Если просто черный накладывать, то уходит в оливковый
Да, черный это условно, даже под нейтральные интерфейсы с синим brand color лучше подобрать что-то из темно синего спектра. Желтый тоже проверил, ярко-красный так же хорошо работает)) Разве что opacity можно немного выше, чем для темного цвета. И под нейтральные кнопки или инпуты надо создавать второй токен оверлея с более нейтральным цветом.
На счет a11y не скажу, не тестил.
Пришел к тому, что в первом слое я не использую группировки по типу: blue, green, neutral, gray и т.п. В первый слой включаются такие же цветовые растяжки, часть их них привязаны к бренду: brand-primary, brand-secondary, brand-accent-01... и часть для success, error и т.п.
Для меня цвета бренда это тоже семантика, в цвета бренда включаются и нейтральные цвета (обычно это brand-secondary), если интерфейс с белым или серым фоном по типу хабра. Но проекты бывают разные, у кого-то вообще может не быть серых кнопок и белого фона, где вместо ч\б secondary растяжки будет растяжка насыщенного оранжевого цвета, соответственно оранжевый фон сай и какие-нибудь зеленые акцентные кнопки на нем.
Если бренд решит, что «фирменный синий» должен стать чуть светлее, вы поменяете HEX-код только в одном примитиве blue-500.
А само имя примитива blue-500 - не меняется? А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
И второй вопрос.
Если взять, что например бренд-колор\акцент-колор\ховер-колор\итд - бизнес не будет менять никогда на уровне всего бизнеса всех продуктов. Зато будут меняться эти значения на уровне исключений в куче разных мест:
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить.
- А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде.
- А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить.
- А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
Тогда мы добавляем новый цвет, например, red, а blue мы ни в коем случае не трогаем!
Затем идем на семантический слой и меняем там все токены blue на red
По итогу имена примитивов остались честными, а имя семантического токена не изменилось. Все компоненты во всех продуктах перекрасились за несколько минут
Примитивы описывают физику (что это за цвет), а семантика — логику (где он сидит). Если физика поменялась, мы добавляем новый примитив, а не врем в старом.
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить.
Продуктовый интерфейс и маркетинговый — это разные вещи. Лендинги или промо-материалы живут своей жизнью. Никто не мешает экспериментировать, на дизайн-систему это не повлияет. В дизайн-систему мы вносим те токены и компоненты, которые прошли отбор и используются в нескольких местах
- А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде.
Есть компонентный уровень, в который и можно добавить такие исключения. Например, создать что-то вроде:
color-button-bg-celebrate-hover — у этого токена будет свой уникальный цвет, со всем остальным аналогично. Создаем отдельную коллекцию для нового года и помещаем эти токены туда.
Есть еще такое понятие как снежинка — это компонент или токен на один спринт, это мусор, который мы не тянем в ДС. Я могу спокойно накостылить что угодно руками, а потом перенести это в корзину или архив, когда оно больше не понадобится. Дизайн-система тут не нужна, она будет мешать.
А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить.
То же самое — компонентные токены, либо семантику новую создаем, если на постоянке будет использоваться.
А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
Для такого мы можем создать несколько тем, например, brand-dark / brand light / brand-weak-dark / brand-weak-dark, и переключать эти моды при необходимости у конкретных организмов или блоков
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
С типографикой мы также можем создавать разные коллекции и кастомить компоненты как душе угодно, а скругления и отступы, в основном, стандартные и привязаны к 4px сетке. Но если значения, например, задаются от ширины экрана, то мы для этого создаем вариант с парметрами scale внутри и fixed aspect ratio, и он будет скейлиться спокойно без привязки к конкретным значениям.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Дизайн-система в первую очередь нужна, чтобы облегчить жизнь дизайнерам и связать их с фронтами. Мы берем самые частые случаи и выносим их в токены и компоненты, вследствие чего их можно переиспользовать как в дизайне, так и в коде — мы ставим рамки и уменьшаем неопределенность. Плюс это уменьшает в десятки раз время на перепроверку компонентов, потому что больше не будет такого, что в одной карточке 31px скругление, а в другой 32, в третьей 33 — мы сводим человеческий фактор на нет.
Дизайн-система, это не тюрьма, а помощь команде. Не везде она нужна. Если продукт небольшой, можно и нужно обходиться без нее, потому что она будет его тормозить. Уже дальше можно подключать, так как возникает много рутины и экспериментов, и нужно высвобождать время дизайнеров на эксперименты и тесты.
Это как генерить в Stable Diffusion либо на GTX 1050, либо на RTX 5090 — разница будет колоссальная, и экспериментов можно сделать в разы больше на мощной видюхе. Но вопрос целесообразности — а зачем генерить? Чтобы поржать над котиками или создавать изображения для отдела маркетинга и приносить прибыль? С дизайн-системами также, нужна цель и метрики успешности.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
Кажется, вы немного перепутали работу принципов связности и зацепления. Хардкодинг стилей внутри компонентов — это как раз путь к Tight Coupling (высокому зацеплению). Компонент становится намертво привязан к конкретному визуальному бренду.
Дизайн-токены — это реализация паттерна Inversion of Control (Инверсия контроля) и Low Coupling. Наш компонент Button имеет High Cohesion (он отвечает только за структуру и состояния) и Low Coupling (он ничего не знает про HEX-коды или бренды). Он использует абстрактный контракт (семантический токен color-bg-primary). Благодаря этому мы можем переключить всю компанию на фиолетовый бренд или темную тему, вообще не касаясь кода компонентов. Абстракция не "течет", она выполняет роль идеального API между дизайном и разработкой
Теперь я кажется понял и смаппил ваши абстракции на свои.))
У себя я юзаю условно только "компонентные токены". Т.е внутри компонента лежат все стили\ассеты что ему нужны. У него есть дефолтные какие-то состояния. Ну и окружение диктует этому компоненту как ему быть в каждом каком-то исключительном случае (через пропсы или css-переменные).
И если много разных компонентов используют довольно много похожих стилей (т.е. хотя бы 4 компонента с хотя бы 5 строками одинаковых стилей) - то я эти повторяющиеся стили выношу в миксины или классы. Ну а в компоненте уже пишу @include или @extend . В вашей системе - это "семантический слой".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайн-токены: полный гайд по архитектуре и неймингу (CTI vs W3C) с примерами и задачками