Практичные советы по уменьшению занимаемой памяти в 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 — в чем разница и почему это важно

Почему Light и Dark не должны делить одну палитру
#цвет

Заметил, что чаще всего при создании примитивного уровня работают только с одной палитрой (я и сам так делал). Обычно она строится для светлой темы, и уже потом просто переиспользуется для тёмной.

А что если в тёмной теме мы видим цвет иначе? Яркость цветов и их насыщенность работают по-разному. А ещё могут быть пересечения одних и тех же значений в двух темах.

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

Решил разобрать плюсы и минусы этих двух разных подходов в новой небольшой статье.

📕 Почему Light и Dark не должны делить одну палитру

Нейминг Spacing Tokens на примитивном уровне
#spacing

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

В токенах на этом уровне принято в нейминге не привязываться к конкретным значениям.

Например, T-Shirt подход
spacing-xs | 8 px
spacing-small | 12 px

или Value multiplier, где x — обычно размер сетки
spacing-2x | 8 px
spacing-3x | 12 px

или менее популярный Numerical order подход
spacing-03 | 8 px
spacing-04 | 12 px

Цель таких подходов — возможность сменить конечное значение, не меняя имя токена.

Но как часто нам приходится менять примитивный уровень спейсингов, честно?

Спейсинги основываются на пиксельной сетке. Представим, что мы изменим ее с 4px на 5px → у нас так «разнесет» интерфейс, что смысл этого мероприятия будет, мягко говоря, сомнительным. За мою практику такого ни разу не делали, даже в небольших продуктах.

Мы заранее закладываемся на то, что возможно в будущем захотим поменять значения, но делать это вряд ли будем, потому что дорого

С другой стороны, пользоваться такими токенами не совсем удобно. S, M, L или x1, x2, x3 названия, не говоря уже о 01, 02, 03 — это не всегда удобно.

Так зачем же нам это нужно!?

И вот здесь у нас есть, по-моему личному мнению, самый удачный подход: Pixel Units, где в название выносится значение:
spacing-8 | 8 px
spacing-12 | 12 px

Цель такого подхода — дать удобство при использовании. А ещё, он очень гибкий, можно добавить в любой момент любое промежуточное значение, в отличии от предыдущих подходов.

Например, частая проблема, когда между M(16px) и L (24px) нужно добавить 20px — мы в тупике, система ломается. То, что помогало строить продукт на начальном этапе, начинает сильно ограничивать. В Pixel Units подходе у вас не будет таких проблем.

А как же смена значений при сохранении названия? — спросите вы

Но токен, это не только про смену, это также и про ограничения. И именно этот смысл мы можем использовать как основной, если смена значений все равно нам не понадобится. Мы можем ограничить на уровне токенов количество значений. Договориться о контракте между дизайнерами и разработкой — использовать только токены, а в токенах у нас будет только нужная нам шкала значений в соответствии бренду. Такое решение не позволит продукту «расползаться».

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

Это простое решение во всех смыслах: гибкое, контролируемое и масштабируемое.

Ошибки в Check designs

Figma выкатила крутой функционал для ревью макетов — Check designs. AI-инструмент, который учится на всех макетах внутри команды, запоминает, где какие токены (переменные) используются, и точечно подсказывает, где лучше заменить и на что.

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

А именно сообщение: Detached component (Library not found), которое может вызывать вопросы, если оно появляется внутри компонента или на обычном фрейме. Это может быть редким кейсом, но Figma не раскроет детали, как с этим быть. Что же это!? Давайте разбираться.

Каждый компонент, который публикуется, получает уникальный ключ — componentKey, так Figma всегда понимает, что это за компонент, откуда он, кому принадлежит, и что с ним сейчас. Если говорить просто, по ключу она может сравнивить инстанс компонента в файле с его публичной версией на сервере Figma и сказать, надо обновлять его или нет. И самый интересный момент — это когда мы детачим компонент. Внутри такого компонента есть поле detachedInfo, которое в момент датача сохраняет тот самый ключ. Это поле помогает, например, в случае, если в макетах есть поломанные компоненты. Можно через код понять, что это был за компонент и восстановить его или передать его в Claude Code и собрать корректный дизайн. Но если это поле на обычном фрейме, который когда-то давным давным давно был инстансом из библиотеки, к которой уже нет доступа? У меня такое случилось

Избавиться от этой ошибки вручную (или через Figma API) невозможно. И такая ошибка в Check designs может подбешивать, особенно если ты перфекционист. Единственный вариант — это заменить текущий фрейм с такой ошибкой на новый. И только так.

Лайфхак: для быстрого переноса всех Properties (цвета, отступы и др) можно использовать комбинацию Opt+Cmd+C → Opt+Cmd+V

Сами пробовали уже этот инструмент?

Переменные из другой библиотеки

Вместе с большим пакетом обновлений (о котором вы и сами всё знаете) появились небольшие удобства для работы с переменными.

Возможно, вы уже сталкивались с такой проблемой — чтобы посмотреть значение переменной из другого файла, например, на какую переменную она ссылается (alias), нужно было идти в тот файл, в котором эта переменная хранится. И так каждый раз, что очень неудобно. Особенно если работаешь с семантическим или компонентным уровнем токенов. Финальное значение переменной одно, а внутри сидит alias на другую переменную, которая может переключиться от выбранного мода. Да или даже обычный HEX подсмотреть, свериться так сказать.

Теперь появилась возможность прямо внутри одного файла посмотреть переменные из другого и их значения. Это реально очень крутая и полезная штука.

Как работает: подключаете нужную библиотеку к вашему файлу, в котором работаете, идете во вкладку Variables и возле заголовка Collections включаете All collections. Ну и всё. Теперь в списке коллекций текущего файла ниже появятся ещё и коллекции из других файлов. Ну красота!

Claude, Icons and Tokens
#ai #tokens

Немного из практики использования ИИ в работе.

В продукте сейчас используется более 150 иконок из двух разных наборов (так вышло, работаем с тем что есть). Одни и те же метафоры могут называться по-разному, собираются тоже. Проблема в том, что их все нужно объединить в один новый единый набор, стиль которого ещё находится в проработке.

Считаю, сейчас самое время перенести всё на токены (да, до этого они были в обычных ресурсах). Когда будет готов новый стиль, я просто заменю шейпы внутри токенов. Тут много повторяющейся работы, поэтому с этой задачей идеально поможет справиться Claude. Но чтобы он завелся, его нужно сначала обучить.

Если будет интересно, какие правила я использовал, дайте знать — напишу отдельный пост. А сейчас хочу рассказать, что Claude сделал за 10 минут и несколько часов настройки.

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

Для начала я скормил Клоду правила работы с иконками — показал идеальный пример сборки (вручную собрал несколько иконок для примера), показал пример иконки до пересборки. Попросил Claude изучить все это. Он моментально понял структуру и контекст, разобрался, как нужно работать, создал Skill с правилами и перешёл к следующему этапу — пересборке всех используемых в проектах иконок в новый формат токенов.

Но была одна проблема: у меня был только список используемых иконок (забрал его у разработки) и два файла Figma с 1000+ иконок. Искать вручную 150+ совсем не хотелось. Попросил Claude сделать это за меня. Скинул ему список иконок и ссылки на файлы, а сам пошел ставить чайник. Он за это время нашёл все нужные иконки в двух файлах и собрал их в отдельный фрейм. Идем дальше.

Дальше, по моим правилам Claude пересобрал их в нужный формат, присвоил новые названия и собрал карту маппинга «старое название → новое название» — пригодится разработчикам, чтобы быстро заменить в своих проектах. 

И самое полезное — я попросил его проанализировать иконки, которые я уже успел вынести в токены. Он:
• Подсветил ошибки в их наименовании.
• Сам задеприкейтил их (как это делать я показал ему ранее)
• Сам создал новые версии с правильными именами
• Прописал им замену для правильной выгрузки в токены
• Перенёс всё на нужные страницы внутри Figma
• И в конце предложил добавить иконки, там где требуется RTL версия — да, нам надо.

Если раньше на такую переделку вместе со спецификацией у меня ушла бы неделя, то сейчас это день + параллельно несколько выполненных задач. Это конечно приятный шок. Будем тестить возможности ИИ дальше. Но они уже сейчас очень полезны.

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

Новый навык дизайнерам дизайн-систем: обучать ИИ скилам