Design System Notes

описание

Заметки из своего личного опыта, про токены, цвет, компоненты, интересные практики и подходы в дизайн системах и около. Контакты: @ravil_shafikov Чат канала: https://t.me/+lfoqTu6_dEY4MTky #design #designsystem

← к каналу @designsystemnotes

подписчиков

Охват к подписчикам

176,7%

ERR

Реакции к просмотрам

5,85%

124 на 20 постов

Пересылки к просмотрам

1,65%

Постов в день

0,3

всего 20

Где отзываются чаще

доля реакций к просмотрам

7 авг.Не так давно Т-Банк стал активно заниматься развитием регионов. В рамках этой инициативы я решил поучаствовать и тоже поделиться опытом с ребятами, кто только начинает свой путь или кому было интересно узнать, как создаются крупные продукты, как дизайн можно превратить в систему и как дизайн-система помогает экономить, масштабировать и поддерживать продукты едиными в рамках всей компании. Мне нравится делиться опытом, и точно так же всегда интересно послушать коллег по цеху и не только. Если есть чего подсмотреть/списать, я вообще за)20,41%
12 авг.Первый пробный прогон контракта на базе компонента Cell. Это скрин теста, который агент сам прогоняет после генерации контракта по компоненту. Выдает сводную таблицу: проверяет позитивные, негативные сценарии и сам себе задает вопросы — по сути симулятор, чтобы не гонять в Figma лишние токены. Проверяет корректность и устойчивость сгенерированного контракта. Получается такой агент-флоу: ревью компонента → генерация контракта → тесты. Следующий этап не начинается, пока не завершится предыдущий.17,65%
30 июл.Расстановка документации — убиваем рутину Всю документацию для компонентов я храню рядом с самими компонентами. Каждый раздел (сам компонент, Demo, Specification, Change log) в отдельном фрейме. И, конечно, все эти фреймы хочется содержать в порядке: с конкретной структурой, очередностью, отступами, настройками и так далее. К тому же на одной странице в Figma может быть несколько компонентов. И у каждого свои спеки с разными высотами фреймов. Buttons ├── Button │ ├── Button │ ├── Demo │ ├── Specification │ └── Change log │ └── Button Icon ├── Button Icon ├── Demo ├── Specification └── Change log Чтобы не двигать фреймы на странице вручную, а делать это всё равно приходится каждый раз, когда нужно что-то добавить в спецификацию или поправить текст, я попросил агента в Figma написать простой плагин, который автоматически расставляет всё по своим местам с нужными отступами. На фреймы сразу прокидываются все нужные параметры — фон, скругления, отступы. Расстановка фреймов это рутина, которая занимает время, а бизнесу это совсем не нужно. Но лично мне хочется держать документацию в чистоте и единой структуре, так потом самому проще находить нужное. А раз ценность для меня очевидна, то нужно максимально удешевлять сам процесс. Почему не просить делать это Claude? А потому что плагин делает это стабильнее, быстрее и не ест кучу токенов.14,29%
31 июл.Claude и $150 на логотипы Мы в продукте работаем на разных рынках, на которых присутствует много локальных компаний — провайдеров. Соответсвенно, нужно добавлять логотипы этих компаний в свою базу, чтобы по красоте отображать их в различных списках операций, инвестициях и тд. Руками собирать такое уже не ок. Поэтому я отдал эту задачу Claude. Тут стоит добавить, что сначала нужно научить его, показать как нужно, как не нужно. То есть самому понимать принцип сборки провайдеров. Что в итоге Обучил на уже готовых хороших примерах, собрал скилл. Далее дал ему список компаний и отправил его в поля (через Goggle Chrome), попросив найти все лого в формате svg и пересобрать по всем правилам. Пришлось чуть докрутить в моменте скилл, но результат вышел достойным. Пока я делал свои задачи, он за 2 часа собрал более 200 провайдеров, оставил только эмблемы, убрав текст из исходников, отцентрировал все это по массе, убрал лишние группы и почистил слои. И после моего ревью разложил по группам рядом с другими уже существующими провайдерами. Результат, который можно использовать. Из интересного Работал на Fable (привык когда ему сбрасывали лимиты), и вопросов он задавал мало, и все понимал сразу, хороший такой мидл дизайнер. Когда я потратил $150☹️ — то переключился на Sonnet, и словил кучу багов. Пришлось допиливать скилл с помощью того же Fable, так как Sonnet делал не то. Сильно была заметна разница. В целом, автоматизация настроена, в будущем добавить новых лого вообще не проблема, а это точно ещё предстоит делать. Вывод Писать скилы точно на Fable, плюс теперь буду просить его добавлять в него максимальное количество информации, чтобы другие модели не терялись. А после отдавать рутину моделям попроще. Плюс разделил скилл на два: создание и ревью, чтобы модель лучше понимала что от неё хотят.11,11%
21 июл.Только нужная инфа Искать новые статьи по своей теме стало в 1000 раз проще. Недавно в ChatGPT завезли запланированные задачи. Он уже давно в контексте моих наработок, задач и подходов. Попросил его раз в неделю делать краткий дайджест по нужным мне темам, которые актуальны для меня именно в текущий момент, и пару новеньких, чтобы быть в тренде. Он делает короткую сводку (5-7 статей), раскрывает чем полезна статья, как может мне помочь сейчас, куда смотрит рынок в целом. Ну я в шоке конечно… приятном)10,98%
9 авг.Дизайн-система для AI: документация или контракты? В комьюнити ДС часто задаются вопросом — «Нужно ли разделять гайды для людей и для AI?» Из последних трендов стала выделяться интересная модель: Documentation + Contracts. Уже недостаточно просто писать гайды человеческим языком. AI-агенты могут их читать, получать контекст и понимать общие принципы системы. Но если мы хотим, чтобы агент не просто «знал документацию», а мог безопасно работать с системой, ему нужны более жёсткие и однозначные рамки: что допустимо, что запрещено, какие варианты существуют и какие правила нельзя нарушать. Эту роль как раз берут на себя контракты. Ранее я уже писал про документацию пропсов компонента, но здесь предлагается более широкая модель: Documentation → объясняет, зачем существует компонент, как и когда им пользоваться, а когда не стоит. Component Contract → формально определяет, что считается допустимой реализацией компонента: его props, variants, states, slots, ограничения и допустимые комбинации. Получается, что это не две отдельные документации — одна для человека, другая для AI. Скорее два слоя одной системы: Documentation → помогает понять решение Contract → определяет границы решения Человек в первую очередь работает со смыслом и контекстом. Агент тоже может использовать этот слой, но при генерации, изменении или ревью компонентов он дополнительно опирается на контракт как на проверяемый источник правил. И здесь появляется важное следствие: контракт можно не только читать, на его основе можно валидировать компоненты, писать тесты, проверять изменения. И самое важное: давать агенту гораздо меньше пространства для ошибок интерпретации.10,42%
18 июл.Компонентные токены, страшно или полезно? Раньше всегда избегал компонентных токенов и в целом, считал что если они есть, значит семантический слой собран слабо, если говорить про цвета. Как же я ошибался. Да, количество токенов растет, и, кажется, что поддерживать такую систему сложно. Но в этом есть и свои плюсы. Используя компонентный уровень можно переназначить токены внутри вложенного компонента. И вот это реально бывает полезно. Например, примитивный counter может быть в брендовом цвете. Но это в обычном контексте. При использовании в кнопке контекст уже задает она. На светлой кнопке брендовый counter, а вот на темной — светлый. В Figma такое переключение можно сделать только через варианты каунтера и кнопки, что убивает всю идею модов для переключения appearance кнопки. А если кнопка в disabled состоянии, counter тоже должен уметь в логику disabled? Нет, не обязательно. Но можно использовать компонентные токены, чтобы переназначить цвета counter. Этот механизм называется Nested component tokens — когда родитель управляет цветом или любыми другими параметрами вложенных компонентов. В Figma это открывает возможность поддержки модов для управления Appearance не только кнопки, но и вложенных компонентов. Единственное требование, это стандартизированный контракт для таких компонентов, чтобы родитель предоставлял такие же параметры, что использует дочерний элемент. В один пост запихнуть все сложно, поэтому попозже сделаю отдельный с примерами. Пока это все в рамках моего тестирования, но выглядит многообещающе и уже решает мои задачи: не раздувать семантический слой токенов и не множить варианты в компонентах. Управление контекстом только через Appearance, а не варианты.8,89%
16 июл.В недавнем большом апдейте Figma показала Generative Plugins. По сути, их встроенный агент позволяет писать плагины прямо в Figma. Мне тут как раз нужно было мигрировать одну версию кнопки на другую — с другими слоями, полями и т. д., чего не сделаешь просто через Swap Instance. Решил потестить, как агент с этим справится. В итоге собрался небольшой плагин, который находит все устаревшие кнопки на странице и переносит все данные в новую версию с сохранением нужных оверрайдов. Считаю, штука может быть полезной, учитывая, как мало времени на неё было потрачено и как быстро она позволяет пройтись по всем макетам, заменив деприкейт компонент на актуальный. Единственное, что я пока не понял, — можно ли такой AI-плагин раскатать на других дизайнеров. P.S. В первой версии плагина по моему запросу «найди все старые кнопки» он в фоновом режиме постоянно запускал поиск и тем самым забивал всю память. Figma просто умирала на глазах. Поэтому лучше сразу сказать агенту, чтобы он добавил кнопку для ручного запуска поиска нужного компонента. P.P.S. Чтобы агент понял, что от него требуется, лучше дать ему несколько примеров старых и новых компонентов в разных вариациях, а также сгруппировать их. Тогда он лучше понимает, как работать и с модами, и с оверрайдами, слоями и свойствами.8,51%
27 июн.Переменные из другой библиотеки Вместе с большим пакетом обновлений (о котором вы и сами всё знаете) появились небольшие удобства для работы с переменными. Возможно, вы уже сталкивались с такой проблемой — чтобы посмотреть значение переменной из другого файла, например, на какую переменную она ссылается (alias), нужно было идти в тот файл, в котором эта переменная хранится. И так каждый раз, что очень неудобно. Особенно если работаешь с семантическим или компонентным уровнем токенов. Финальное значение переменной одно, а внутри сидит alias на другую переменную, которая может переключиться от выбранного мода. Да или даже обычный HEX подсмотреть, свериться так сказать. Теперь появилась возможность прямо внутри одного файла посмотреть переменные из другого и их значения. Это реально очень крутая и полезная штука. Как работает: подключаете нужную библиотеку к вашему файлу, в котором работаете, идете во вкладку Variables и возле заголовка Collections включаете All collections. Ну и всё. Теперь в списке коллекций текущего файла ниже появятся ещё и коллекции из других файлов. Ну красота!8,00%
1 авг.Тренд: роль AI-агента в дизайн-системах Последнее время выходит много видео и статей о роли ИИ в дизайн-системах. И заметно, что фокус постепенно смещается в сторону агента-помощника для соблюдения порядка, ревью компонентов, токенов и спецификаций. То есть, по сути, это отказ от идеи «создай мне компонент» и переход к «помоги мне поддерживать системность». Сейчас есть идеи по разделению агентов: один делает только ревью текущей системы, другой — только правит, третий — исследует новые подходы, но не меняет текущую систему, а просто предлагает решения и план миграции. Я всегда скептически относился к разным историям в духе: «ИИ может создавать компоненты». Безусловно, он может. Вопрос только в масштабируемости такой системы, её осознанном точечном изменении, если это требуется, и последующей поддержке. И вот про осознанное изменение, особенно моё любимое — генерацию токенов, — это прям боль. Возможно, у кого-то реально получилось, и оно работает как нужно. Я бы посмотрел. Но то, что я вижу, говорит об обратном. Можно потратить кучу времени (и денег) на правки созданного ИИ артефакта и всё равно не понять, как была собрана та же палитра или компонент. И что делать, если нужно подвигать цвет или добавить какой-то пропс в компонент без сильной переделки (иначе у кого-то поедут макеты), — вопрос. Это всё к тому, что ИИ — крутой помощник. Но чтобы использовать его на максимум, хорошо бы самому понимать, как устроена система, разбираться в деталях и уметь проверить результат за ИИ. Примерно так же, как мы проверяем текст или изображения: мы сразу можем сказать, ок или не ок. Потому что у нас есть экспертность в этом. Убеждён, что нам всё ещё нужно уметь собирать компоненты и превращать это в системность. Агент тут будет выступать множителем этой системности, используя понятные правила и ограничения, которые мы ему пропишем. Сами как думаете, согласны или можно доверить ИИ все сделать самому?6,67%
5 авг.без подписи6,25%
9 июл.Ветров сделал подборку статей про подготовку дизайн-систем к работе с ИИ. Часть статей прочитал сам, часть отправил в 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, который сможет не только ревьюить дизайн, но и автоматически собирать интерфейсы. Интересно, кто-то уже экспериментирует с подобным подходом?6,06%