Практичные советы по уменьшению занимаемой памяти в Figma библиотеках от дизайнера из Honeywell Allie Paschal. Больше актуально для библиотек, хранящие все мастер компоненты в одном файле, но есть кое что интересное.

При сборке сложных компонентов часто приходится выносить небольшие повторяющиеся блоки в отдельные компоненты, например, аксессуары в ячейках или кнопках, чтобы было легче поддерживать изменения во всех вариантах внутри мастер компонента. Но такие компоненты начинают светить в общую библиотеку. Чтобы дизайнеры не видели такие nested компоненты, в начало названия добавляют точку (.name_omponent) или нижнее подчеркивание (_name_component). У этого подхода есть минус, не всегда такие компоненты получают своевременные апдейты. Figma не «прокидывает» к ним путь, ведь они становятся локальными внутри конкретного файла.

Так вот Allie Paschal предлагает выносить такие nested компоненты в отдельный файл, выключив его по умолчанию у всех дизайнеров. Такой подход сохраняет поддержку библиотеки, компоненты не светят в общую библиотеку, и остаётся возможность получать обновления во всех файлах, где они используется.

#design #designsystem #figma #ui

Существует разнообразные подходы к определению названий свойств при сборке компонентов в Figma.

Например, Default, Normal или Enabled — это всё слова, которые часто используются для определения одного и того же свойства состояния. Они описывают состояние компонента, на который можно нажать, выбрать или активировать, который находится в доступном дефолтном состоянии.

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

Normal же больше относится к градации чего-либо, чем к состоянию, и стоит в одном ряду с Medium, Regular, Usual, Standard. Используя это слово, мы начинаем рассматривать состояния в сравнительной плоскости — больше, меньше, нормально.

Один из интересных, на мой взгляд, подходов в выборе принципа именования заключается в том, чтобы использовать псевдоклассы CSS, для синхронизации между дизайном и разработкой. Об этом есть видео от Артура (Team Lead DS из "Касперского"). Он предлагает использовать Enabled в качестве доступного состояния по умолчанию. Этот же подход применяется в Material Design 3 от Google.

Таким образом мы начинает говорить на одном языке с разработчиками. Они знают что значат эти слова, и знают как правильно их интерпретировать в коде.

#design #designsystem #ui #figma

В продолжение работы с памятью в Figma.

Наткнулся на показательную статью от Jérôme Benoit (Design System Lead at Doctolib) об эффективном подходе при сборке компонентов Figma.

Зацепил момент, когда вроде бы простой компонент (что-то вроде привычного чипа с возможностью включения иконки, аватара или спинера) представлял из себя «франкинштейна» из 8692 слоёв! После оптимизации их стало куда меньше — 797.

Не сложно представить, что такой компонент может являться частью другого компонента со своим набором вариантов. То есть мы фактически добавляем все слои такого инстанса ко всем слоям родительского компонента.

Вот что пишет об этом сама Figma: «This improves memory usage because Figma loads all components in a component set. This allows you to quickly switch between variants.»

То есть, компонент включает 20 вариантов, но на макете мы используем всего лишь один, тем не менее загружаются все 20. И если таких сет компонентов у нас несколько (аватары, кнопки, чипы, ячейки или сложные формы), то мы, по сути, загружаем большое количество неиспользуемых слоёв из библиотеки, которые заполняют значительную часть памяти. Между тем, не все будут пользоваться этими вариантами, но они всё равно загрузят к себе в макет все слои.

Один из выводов заключается в том, что не стоит создавать большие наборы компонентов, лучше пусть их будет несколько, но небольших. Благодаря этому макеты будут работать шустрее. Останется лишь правильно организовать навигацию между компонентами через Swap меню.

А второй — это использование проперти instance swap, но об этом уже в статье.

#designsystem #design #ui #figma

Новая и очень крутая статья от Nathan Curtis, где он разбирает типичные ошибки в определении состояний компонента (hover, active, disabled). Что это для дизайнера, что это для разработки. Почему в фигме нам проще делать по одному, и почему мы допускаем эти ошибки.

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

Давно не было меня в этом чате. Есть небольшие новости.

7 февраля в Москве на площадке TAU будет проходить большая финтех-конференции T-Sync. Там будет много разных направлений, с фокусом на продукт, разработку, AI/ML, R&D, UX/UI (куда без этого) и другое. Из интересного, о чем бы мне хотелось с вами поделиться: буду рассказывать про дизайн-токены.

Тема моего выступления «Есть ли единая формула для дизайн-токенов». Поговорим про что работает, что не работает, когда лучше внедрять токены и как с ними быть, когда у тебя огромное количество продуктов на одной дизайн-системе.

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

Еще из интересного в секции UX/UI:
Можно познакомиться с той самой Taiga UI, открытой библиотекой, которая очень популярна во всем мире и делается внутри Т-Банка
Узнать об изменениях, которые ребята видят в дизайне инженерных продуктов и профессии продуктового дизайнера, а именно в интерфейсе Ai-ассистента разработчика

Посещение бесплатное, но нужна будет регистрация. На счет записи видео не знаю, но если будет, обязательно поделюсь! Жду всех, кто хочет послушать и поболтать о токенах!)

Начнем год с выхода на публику😉

Итоги квартирника. Немного рефлексии.

Мое первое выступление по теме дизайна состоялось. Формат выступления в виде квартирника, когда ты не просто рассказываешь про свой опыт, но и сразу обсуждаешь кейсы, узнаешь как ребята по цеху проходят свой путь и решают те же самые проблемы — это очень крутой способ поделиться опытом. Живое открытое общение, гости активно делятся своими решениями и кейсами, временами живо спрашивают друг у друга, а ты сам превращаешься в этот момент зрителем их истории, это то, чего хочется побольше в нашем комьюнити. Душевные разговоры с понимаем, без критики и осуждения.

Может показаться, что если презентации нет, то это даже проще, пришел и рассказываешь, но это не так. Подсказок в виде слайдов нет, так и ещё по ходу выступления нужно постоянно следить за таймингом, развитием темы, живостью, вовлеченностью аудитории и делать микро-выводы на основе только что поднятой темы. Что-то получилось хорошо, но и есть над чем поработать.

Я никогда не был публичным, так как не люблю забирать на себя много внимания. Но мне всегда хотелось делиться опытом и узнавать новое. Формат квартирника отличная возможность для этого. Аутентичная и открытая атмосфера. Ощущение будто знаешь всех уже давно.

В конце, хочется сказать Спасибо всем, кто пришел, кто поучаствовал в обсуждении, за интересные вопросы и живой честный разговор. Очень рад был всех видеть. И отдельно хочу поблагодарить команду за поддержку 🫶🏻

Если хочется оставить обратную связь, обсудить то, что не успели, пишите. Всегда рад! 😉

Хочется сохранить это здесь, вдруг кто не смотрел. Это как собирать предсказуемые палитры по контрасту APCA (WCAG 3.0), используя инструмент huetone и цветовое пространство okLCH

Года 3 назад, когда я работал в Точке, мы пересобирали дизайн-систему. Я много времени потратил на тему с цветом. Мне было интересно изучить его физику, как он работает, как собираются палитры, на что обращать внимание и какие инструменты могут пригодиться в работе.

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

Поэтому, открываю рубрику #цвет. И начнем с первой статьи, в которой я немного затрагиваю популярное цветовое пространство OKLCH и что оно не гарантирует стабильный контраст при сборке цветовой палитры.

📕 Почему одинаковая светлота не гарантирует одинаковый контраст

Day/Night vs Light/Dark
#цвет

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

Постарался разобрать это в новой заметке на Medium:

📕 Day/Night vs Light/Dark — в чем разница и почему это важно