Design System Notes

Расход токенов при работе с Figma to Claude Токены стоят дорого, лимиты быстро утекают, особенно на сложные задачи. Но проблема даже не в том, что они сложные, иногда агент просто читает слишком много данных в Figma. Claude частенько запрашивает метаданные всей страницы — сотни нод в XML. Хотя для задачи мог понадобиться один конкретный компонент или фрейм. Даже когда даешь ему ссылку на фрейм, просишь сделать ревью, он иногда грузит всю страницу целиком, чтобы лучше понять контекст. И он отчасти прав, но это стоит дорого и не всегда нужно. Можно полечить это, ограничив его следующими правилами: ## Figma context rules - Read only the scope required by the task. - Never read the entire page or file when a specific nodeId is known. - If the user provides a frame link, inspect only that frame. - Use full-page or full-file reads only when explicitly requested or required by the task. - Return aggregated results from use_figma: counts, findings, and violations. - Never return raw node trees when aggregated data is sufficient. То есть принцип довольно простой: не прочитать всё и потом отфильтровать, а изначально не читать лишнее. На больших Figma-файлах разница в размере контекста может быть очень заметной. В моем случае это дало в ~69 раз меньше токенов.

Первый пробный прогон контракта на базе компонента Cell. Это скрин теста, который агент сам прогоняет после генерации контракта по компоненту. Выдает сводную таблицу: проверяет позитивные, негативные сценарии и сам себе задает вопросы — по сути симулятор, чтобы не гонять в Figma лишние токены. Проверяет корректность и устойчивость сгенерированного контракта. Получается такой агент-флоу: ревью компонента → генерация контракта → тесты. Следующий этап не начинается, пока не завершится предыдущий.

Дизайн-система для AI: документация или контракты? В комьюнити ДС часто задаются вопросом — «Нужно ли разделять гайды для людей и для AI?» Из последних трендов стала выделяться интересная модель: Documentation + Contracts. Уже недостаточно просто писать гайды человеческим языком. AI-агенты могут их читать, получать контекст и понимать общие принципы системы. Но если мы хотим, чтобы агент не просто «знал документацию», а мог безопасно работать с системой, ему нужны более жёсткие и однозначные рамки: что допустимо, что запрещено, какие варианты существуют и какие правила нельзя нарушать. Эту роль как раз берут на себя контракты. Ранее я уже писал про документацию пропсов компонента, но здесь предлагается более широкая модель: Documentation → объясняет, зачем существует компонент, как и когда им пользоваться, а когда не стоит. Component Contract → формально определяет, что считается допустимой реализацией компонента: его props, variants, states, slots, ограничения и допустимые комбинации. Получается, что это не две отдельные документации — одна для человека, другая для AI. Скорее два слоя одной системы: Documentation → помогает понять решение Contract → определяет границы решения Человек в первую очередь работает со смыслом и контекстом. Агент тоже может использовать этот слой, но при генерации, изменении или ревью компонентов он дополнительно опирается на контракт как на проверяемый источник правил. И здесь появляется важное следствие: контракт можно не только читать, на его основе можно валидировать компоненты, писать тесты, проверять изменения. И самое важное: давать агенту гораздо меньше пространства для ошибок интерпретации.

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

Тренд: роль AI-агента в дизайн-системах Последнее время выходит много видео и статей о роли ИИ в дизайн-системах. И заметно, что фокус постепенно смещается в сторону агента-помощника для соблюдения порядка, ревью компонентов, токенов и спецификаций. То есть, по сути, это отказ от идеи «создай мне компонент» и переход к «помоги мне поддерживать системность». Сейчас есть идеи по разделению агентов: один делает только ревью текущей системы, другой — только правит, третий — исследует новые подходы, но не меняет текущую систему, а просто предлагает решения и план миграции. Я всегда скептически относился к разным историям в духе: «ИИ может создавать компоненты». Безусловно, он может. Вопрос только в масштабируемости такой системы, её осознанном точечном изменении, если это требуется, и последующей поддержке. И вот про осознанное изменение, особенно моё любимое — генерацию токенов, — это прям боль. Возможно, у кого-то реально получилось, и оно работает как нужно. Я бы посмотрел. Но то, что я вижу, говорит об обратном. Можно потратить кучу времени (и денег) на правки созданного ИИ артефакта и всё равно не понять, как была собрана та же палитра или компонент. И что делать, если нужно подвигать цвет или добавить какой-то пропс в компонент без сильной переделки (иначе у кого-то поедут макеты), — вопрос. Это всё к тому, что ИИ — крутой помощник. Но чтобы использовать его на максимум, хорошо бы самому понимать, как устроена система, разбираться в деталях и уметь проверить результат за ИИ. Примерно так же, как мы проверяем текст или изображения: мы сразу можем сказать, ок или не ок. Потому что у нас есть экспертность в этом. Убеждён, что нам всё ещё нужно уметь собирать компоненты и превращать это в системность. Агент тут будет выступать множителем этой системности, используя понятные правила и ограничения, которые мы ему пропишем. Сами как думаете, согласны или можно доверить ИИ все сделать самому?

Claude и $150 на логотипы Мы в продукте работаем на разных рынках, на которых присутствует много локальных компаний — провайдеров. Соответсвенно, нужно добавлять логотипы этих компаний в свою базу, чтобы по красоте отображать их в различных списках операций, инвестициях и тд. Руками собирать такое уже не ок. Поэтому я отдал эту задачу Claude. Тут стоит добавить, что сначала нужно научить его, показать как нужно, как не нужно. То есть самому понимать принцип сборки провайдеров. Что в итоге Обучил на уже готовых хороших примерах, собрал скилл. Далее дал ему список компаний и отправил его в поля (через Goggle Chrome), попросив найти все лого в формате svg и пересобрать по всем правилам. Пришлось чуть докрутить в моменте скилл, но результат вышел достойным. Пока я делал свои задачи, он за 2 часа собрал более 200 провайдеров, оставил только эмблемы, убрав текст из исходников, отцентрировал все это по массе, убрал лишние группы и почистил слои. И после моего ревью разложил по группам рядом с другими уже существующими провайдерами. Результат, который можно использовать. Из интересного Работал на Fable (привык когда ему сбрасывали лимиты), и вопросов он задавал мало, и все понимал сразу, хороший такой мидл дизайнер. Когда я потратил $150☹️ — то переключился на Sonnet, и словил кучу багов. Пришлось допиливать скилл с помощью того же Fable, так как Sonnet делал не то. Сильно была заметна разница. В целом, автоматизация настроена, в будущем добавить новых лого вообще не проблема, а это точно ещё предстоит делать. Вывод Писать скилы точно на Fable, плюс теперь буду просить его добавлять в него максимальное количество информации, чтобы другие модели не терялись. А после отдавать рутину моделям попроще. Плюс разделил скилл на два: создание и ревью, чтобы модель лучше понимала что от неё хотят.

Расстановка документации — убиваем рутину Всю документацию для компонентов я храню рядом с самими компонентами. Каждый раздел (сам компонент, Demo, Specification, Change log) в отдельном фрейме. И, конечно, все эти фреймы хочется содержать в порядке: с конкретной структурой, очередностью, отступами, настройками и так далее. К тому же на одной странице в Figma может быть несколько компонентов. И у каждого свои спеки с разными высотами фреймов. Buttons ├── Button │ ├── Button │ ├── Demo │ ├── Specification │ └── Change log │ └── Button Icon ├── Button Icon ├── Demo ├── Specification └── Change log Чтобы не двигать фреймы на странице вручную, а делать это всё равно приходится каждый раз, когда нужно что-то добавить в спецификацию или поправить текст, я попросил агента в Figma написать простой плагин, который автоматически расставляет всё по своим местам с нужными отступами. На фреймы сразу прокидываются все нужные параметры — фон, скругления, отступы. Расстановка фреймов это рутина, которая занимает время, а бизнесу это совсем не нужно. Но лично мне хочется держать документацию в чистоте и единой структуре, так потом самому проще находить нужное. А раз ценность для меня очевидна, то нужно максимально удешевлять сам процесс. Почему не просить делать это Claude? А потому что плагин делает это стабильнее, быстрее и не ест кучу токенов.

Только нужная инфа Искать новые статьи по своей теме стало в 1000 раз проще. Недавно в ChatGPT завезли запланированные задачи. Он уже давно в контексте моих наработок, задач и подходов. Попросил его раз в неделю делать краткий дайджест по нужным мне темам, которые актуальны для меня именно в текущий момент, и пару новеньких, чтобы быть в тренде. Он делает короткую сводку (5-7 статей), раскрывает чем полезна статья, как может мне помочь сейчас, куда смотрит рынок в целом. Ну я в шоке конечно… приятном)

Компонентные токены, страшно или полезно? Раньше всегда избегал компонентных токенов и в целом, считал что если они есть, значит семантический слой собран слабо, если говорить про цвета. Как же я ошибался. Да, количество токенов растет, и, кажется, что поддерживать такую систему сложно. Но в этом есть и свои плюсы. Используя компонентный уровень можно переназначить токены внутри вложенного компонента. И вот это реально бывает полезно. Например, примитивный counter может быть в брендовом цвете. Но это в обычном контексте. При использовании в кнопке контекст уже задает она. На светлой кнопке брендовый counter, а вот на темной — светлый. В Figma такое переключение можно сделать только через варианты каунтера и кнопки, что убивает всю идею модов для переключения appearance кнопки. А если кнопка в disabled состоянии, counter тоже должен уметь в логику disabled? Нет, не обязательно. Но можно использовать компонентные токены, чтобы переназначить цвета counter. Этот механизм называется Nested component tokens — когда родитель управляет цветом или любыми другими параметрами вложенных компонентов. В Figma это открывает возможность поддержки модов для управления Appearance не только кнопки, но и вложенных компонентов. Единственное требование, это стандартизированный контракт для таких компонентов, чтобы родитель предоставлял такие же параметры, что использует дочерний элемент. В один пост запихнуть все сложно, поэтому попозже сделаю отдельный с примерами. Пока это все в рамках моего тестирования, но выглядит многообещающе и уже решает мои задачи: не раздувать семантический слой токенов и не множить варианты в компонентах. Управление контекстом только через Appearance, а не варианты.

В недавнем большом апдейте Figma показала Generative Plugins. По сути, их встроенный агент позволяет писать плагины прямо в Figma. Мне тут как раз нужно было мигрировать одну версию кнопки на другую — с другими слоями, полями и т. д., чего не сделаешь просто через Swap Instance. Решил потестить, как агент с этим справится. В итоге собрался небольшой плагин, который находит все устаревшие кнопки на странице и переносит все данные в новую версию с сохранением нужных оверрайдов. Считаю, штука может быть полезной, учитывая, как мало времени на неё было потрачено и как быстро она позволяет пройтись по всем макетам, заменив деприкейт компонент на актуальный. Единственное, что я пока не понял, — можно ли такой AI-плагин раскатать на других дизайнеров. P.S. В первой версии плагина по моему запросу «найди все старые кнопки» он в фоновом режиме постоянно запускал поиск и тем самым забивал всю память. Figma просто умирала на глазах. Поэтому лучше сразу сказать агенту, чтобы он добавил кнопку для ручного запуска поиска нужного компонента. P.P.S. Чтобы агент понял, что от него требуется, лучше дать ему несколько примеров старых и новых компонентов в разных вариациях, а также сгруппировать их. Тогда он лучше понимает, как работать и с модами, и с оверрайдами, слоями и свойствами.

Ветров сделал подборку статей про подготовку дизайн-систем к работе с ИИ. Часть статей прочитал сам, часть отправил в Claude, чтобы он сделал скрининг и дал краткое резюме, сразу приложив идеи к моим текущим наработкам. Век ИИ, нужно ускоряться. Что интересного нашел для себя. Статья Your next design system user is an agent — Murphy предлагает: • документировать пропсы как параметры API — с типами, дефолтами и ограничениями • описывать связи между компонентами и правила их вложенности. Да, в статье много говорится про код. Но ничто не мешает описывать внутри каждого компонента правила по единой структуре (разумеется, не вручную). Пример на обычной ячейке: Placement: standalone Description: A horizontal list row with three slot regions (Leading, Middle, Trailing) and an optional chevron. The middle region is flexible; leading and trailing slots hold swappable content. Parts: Leading Slot (optional, Has Leading Slot) · Middle Slot (required) · Trailing Slot (optional, Has Trailing Slot) · Chevron (optional, Has Chevron) Accepts / Leading Slot: Icon, Avatar, Counter, Free Slot Accepts / Middle Slot: Text 2 Lines, Text 1 Line Accepts / Trailing Slot: Icon 24, Avatar, Counter, Free Slot Такой подход должен помочь AI-агентам (в том числе Figma Agent) не просто находить нужный компонент, а понимать его ограничения: какие вложенные элементы допустимы, какие обязательны и в каком контексте компонент вообще можно использовать. Хочу протестировать эту идею. Сейчас активно работаю над тем, чтобы компоненты были AI-readable: собираю единые правила, описываю структуру, связи и поведение компонентов. Цель — в будущем собрать skill, который сможет не только ревьюить дизайн, но и автоматически собирать интерфейсы. Интересно, кто-то уже экспериментирует с подобным подходом?

Claude, Icons and Tokens #ai #tokens Немного из практики использования ИИ в работе. В продукте сейчас используется более 150 иконок из двух разных наборов (так вышло, работаем с тем что есть). Одни и те же метафоры могут называться по-разному, собираются тоже. Проблема в том, что их все нужно объединить в один новый единый набор, стиль которого ещё находится в проработке. Считаю, сейчас самое время перенести всё на токены (да, до этого они были в обычных ресурсах). Когда будет готов новый стиль, я просто заменю шейпы внутри токенов. Тут много повторяющейся работы, поэтому с этой задачей идеально поможет справиться Claude. Но чтобы он завелся, его нужно сначала обучить. Если будет интересно, какие правила я использовал, дайте знать — напишу отдельный пост. А сейчас хочу рассказать, что Claude сделал за 10 минут и несколько часов настройки. Сам процесс обучения и работы Клода оказался значительно быстрее ручной работы и отлично масштабируется не только в Figma, но и в документации. Для начала я скормил Клоду правила работы с иконками — показал идеальный пример сборки (вручную собрал несколько иконок для примера), показал пример иконки до пересборки. Попросил Claude изучить все это. Он моментально понял структуру и контекст, разобрался, как нужно работать, создал Skill с правилами и перешёл к следующему этапу — пересборке всех используемых в проектах иконок в новый формат токенов. Но была одна проблема: у меня был только список используемых иконок (забрал его у разработки) и два файла Figma с 1000+ иконок. Искать вручную 150+ совсем не хотелось. Попросил Claude сделать это за меня. Скинул ему список иконок и ссылки на файлы, а сам пошел ставить чайник. Он за это время нашёл все нужные иконки в двух файлах и собрал их в отдельный фрейм. Идем дальше. Дальше, по моим правилам Claude пересобрал их в нужный формат, присвоил новые названия и собрал карту маппинга «старое название → новое название» — пригодится разработчикам, чтобы быстро заменить в своих проектах.  И самое полезное — я попросил его проанализировать иконки, которые я уже успел вынести в токены. Он: • Подсветил ошибки в их наименовании. • Сам задеприкейтил их (как это делать я показал ему ранее) • Сам создал новые версии с правильными именами • Прописал им замену для правильной выгрузки в токены • Перенёс всё на нужные страницы внутри Figma • И в конце предложил добавить иконки, там где требуется RTL версия — да, нам надо. Если раньше на такую переделку вместе со спецификацией у меня ушла бы неделя, то сейчас это день + параллельно несколько выполненных задач. Это конечно приятный шок. Будем тестить возможности ИИ дальше. Но они уже сейчас очень полезны. Конечно, чтобы добиться от ИИ делать работу за тебя, сначала его нужно обучить, показать как надо, как не надо. А для этого требуется понимание финального результата и четкая система. Нужно показать ему то, что ты хочешь. А он уже по существующим примерам и правилам начинает очень быстро выполнять то, что ты от него просишь. Новый навык дизайнерам дизайн-систем: обучать ИИ скилам

Переменные из другой библиотеки Вместе с большим пакетом обновлений (о котором вы и сами всё знаете) появились небольшие удобства для работы с переменными. Возможно, вы уже сталкивались с такой проблемой — чтобы посмотреть значение переменной из другого файла, например, на какую переменную она ссылается (alias), нужно было идти в тот файл, в котором эта переменная хранится. И так каждый раз, что очень неудобно. Особенно если работаешь с семантическим или компонентным уровнем токенов. Финальное значение переменной одно, а внутри сидит alias на другую переменную, которая может переключиться от выбранного мода. Да или даже обычный HEX подсмотреть, свериться так сказать. Теперь появилась возможность прямо внутри одного файла посмотреть переменные из другого и их значения. Это реально очень крутая и полезная штука. Как работает: подключаете нужную библиотеку к вашему файлу, в котором работаете, идете во вкладку Variables и возле заголовка Collections включаете All collections. Ну и всё. Теперь в списке коллекций текущего файла ниже появятся ещё и коллекции из других файлов. Ну красота!

Ошибки в 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 Сами пробовали уже этот инструмент?

Нейминг 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 подходе у вас не будет таких проблем. А как же смена значений при сохранении названия? — спросите вы Но токен, это не только про смену, это также и про ограничения. И именно этот смысл мы можем использовать как основной, если смена значений все равно нам не понадобится. Мы можем ограничить на уровне токенов количество значений. Договориться о контракте между дизайнерами и разработкой — использовать только токены, а в токенах у нас будет только нужная нам шкала значений в соответствии бренду. Такое решение не позволит продукту «расползаться». Если продукт захочет перейти на другую пиксельную сетку, это значит придется переделать все. Переезд на новую шкалу отступов на этом фоне не выглядит проблемой. Это простое решение во всех смыслах: гибкое, контролируемое и масштабируемое.

Почему Light и Dark не должны делить одну палитру #цвет Заметил, что чаще всего при создании примитивного уровня работают только с одной палитрой (я и сам так делал). Обычно она строится для светлой темы, и уже потом просто переиспользуется для тёмной. А что если в тёмной теме мы видим цвет иначе? Яркость цветов и их насыщенность работают по-разному. А ещё могут быть пересечения одних и тех же значений в двух темах. Но есть дизайн-системы, которые собирают примитивные палитры под каждую тему, и у этого подхода есть свои преимущества. В том числе очень гибкое масштабирование и тонкая калибровка. Решил разобрать плюсы и минусы этих двух разных подходов в новой небольшой статье. 📕 Почему Light и Dark не должны делить одну палитру

Day/Night vs Light/Dark #цвет В моей работе я часто сталкиваюсь с этими терминами. На первый взгляд кажется, что это одно и то же, но есть нюансы — и они реально влияют на то, как мы строим систему. Постарался разобрать это в новой заметке на Medium: 📕 Day/Night vs Light/Dark — в чем разница и почему это важно

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

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