Павел Григорьев написал об ошибках при создании дизайн-системы.

— Все макеты рисовали под основное разрешение (была статистика), для других разрешений прорабатывали только типовые страницы. Элементы для этих разрешений появлялись в ДС вне контекста, без примерки на реальных экранных формах. Местами поплыли пропорции, часть элементов забыли;
— На основное разрешение не всегда можно ориентироваться: пользователи иногда работают в окнах не на весь экран, увеличивают масштаб в браузере, производители ноутбуков иногда по умолчанию увеличивают системный масштаб, чтобы интерфейс не был слишком мелким;
— Подход с целевыми разрешениями себя не оправдал. Надо закладывать ресурсы на проработку экранных форм, элементов ДС и UI-кита под разные разрешения;
— Сложные модули лучше делать более гибкими, чтобы проще было их изменить (в первую очередь с точки зрения кода), так как для таких модулей сложно всё предусмотреть с самого начала;
— Набора элементов недостаточно, нужны инструкции по их правильному использованию, примеры и шаблоны с лучшими практиками;
— В шаблонах и описаниях должно быть однозначно понятно, как использовать элемент, и они должны быть привязаны к реальным примерам использования.

#design_system

Ксения Гаврилова написала о предпосылках создания дизайн-системы и выводах, которые сделала в процессе её создания.

— Возможно, вам подойдёт одна из ДС, что есть в открытом доступе;
— Если создаёте свою, выделите роль её владельца. Иначе столкнётесь с перекладыванием ответственности и увеличением сроков разработки;
— Не будьте слишком оптимистичны при оценке времени. Люди болеют, ходят в отпуск и могут не иметь опыта в создании и описании компонентов. Если вы справились с компонентом кнопки за 20 часов, это не значит, что другой дизайнер потратит столько же на другой компонент;
— Кроме состояний компонента описывайте паттерны его использования в продукте. Например, для радиокнопки: как сообщить об ошибке (если выбор обязателен), какой стиль должен быть у заголовка радиогруппы, можно ли расположить её горизонтально;
— Чем больше людей в команде, тем более формально стоит подходить в сбору и упорядочиванию информации: заметки по итогам встреч, трансляция их в телеграм-канал, презентации больших изменений, внутренняя база знаний;
— Работа над ДС — долгий процесс. Рассказывайте о прогрессе, вовлекайте стейкхолдеров, чтобы им не казалось, что всё идёт слишком долго;
— Закладывайте ресурсы на развитие ДС, вводите роли выделенных дизайнеров и разработчиков ДС. Продуктовые дизайнеры могут участвовать в развитии ДС только в факультативном формате, когда закрыты более приоритетные продуктовые задачи.

#design_system

Дмитрий Якушин написал о дизайн-токенах.

— Набор дизайн-токенов позволяет сделать визуально согласованный и при этом гибкий дизайн (легко поменять один оттенок на другой);
— Дизайн-токен — псевдоним определённого значения той или иной переменной: цвета, шрифта, размера элемента, тени, отступа, скругления;
— Цвет #677178 можно назвать color-grey-600 и использовать в макетах так, а можно создать токены color-text-secondary и color-component-badge-bg-neutral, которые будут ссылаться на color-grey-600;
— В тёмной теме color-text-secondary может ссылаться на другой цвет, что упрощает создание макетов для других тем;
— Говорящие названия упрощают их использование, особенно новыми участниками команды;
— Есть черновая версия стандарта дизайн-токенов от W3C;
— В составном токене (миксине) может быть больше одной переменной. Например, в токене типографики: название шрифта, кегль, высота строки, межбуквенный интервал;
— color-green-600 — глобальная переменная (примитив, палитра, референсный токен) с абстрактным названием без контекста. Число обычно отражает количество света в цвете;
— color-text-success — дизайн-токен, который ссылается на переменную color-green-600 и имеет контекст использования: для текстовых сообщений об успехе;
— Есть компонентные токены, которые относятся к конкретным компонентам, например, color-component-badge-bg-info для фона информационного бейджика;
— Распространены стили названия: color_text_primary для веба, сolorToken.textPrimary для мобильных платформ;
— Полная структура названия: префикс, группа (color), тип (text, component), элемент (badge), модификатор (background), вариант (info), состояние (hover);
— Некоторых частей может не быть: если токен не относится к компоненту, если к проекту не подключено нескольких библиотек с токенами (прификс их идентифицирует);
— В именах токенов размеров лучше не использовать цифры, чтобы не было путаницы с фактическими значениями: xx-small, x-small, small, medium, large, x-large, xx-large;
— Категории: colors, font family, font size, line height, border color, grid, border radius, spacing, box shadow, duration/transition, shadows, z-index, size.

#figma #design_system

В «Инферит Клаудмастер» написали об этапах создания дизайн-системы и проблемах, с которыми столкнулись.

— 1. Планирование и приоритизация: разделение процесса на этапы; анализ существующих компонентов и выявление зависимостей между ними; приоритизация задач дизайнерами и построение плана работ;
— 2. Утверждение семантики и шаблонов для оформления в Фигме: система нейминга токенов, состояний, вариантов, иконок и компонентов в Фигме и на фронте; шаблоны для создания документации; система статусов компонентов для определения готовности к публикации и разработке;
— 3. Стандартизация построения интерфейса: внедрение дизайн-токенов; определение стандартов для сетки, отступов, скруглений, типографики и цветов;
— 4. Шаблон чейнджлога об изменении компонентов дизайн-системы и внедрении новых;
— 5. Разработка страниц с компонентами: демонстрация компонентов, описание правил использования;
— 6. Изменение компонентов в продукте (итеративный процесс): выбор компонентов для разработки в спринте; тестирование и ревью; внедрение обновлённых компонентов в продукт; оценка эффективности и влияния на пользовательский опыт;
— Одна из проблем: не разделили компоненты на более простые атомы и молекулы, из-за чего они стали слишком сложными, а их состояния избыточными.

#design_system

Максим Кононов написал о 13 базовых цветовых токенах (без токенов для ховеров).

— Блоки в интерфейсе — контейнеры для элементов и других блоков. Они должны выделяться на фоне родительского блока, создавая структуру слоёв;
— View (1) — блок, на котором отображается контент. Navigation (2) — блок с навигацией, который управляет тем, какие View отображаются;
— Border (3) может отделить два находящихся рядом блока, а также обвести немодальный блок, находящийся поверх остальных (плюс тень);
— Если блок модальный, для затемнения лежащего ниже контента — полупрозрачный Overlay (4);
— Элементы — всё остальное: текст, иконки, кнопки, поля ввода. Они управляют вниманием пользователя, выделяя важное, показывают состояние элемента;
— За внимание отвечают цвета элементов: Primary (5), Secondary (6) и Accent (7), перебивающий Primary;
— Характер задают: Danger (8), Success (9), Warning (10);
— Для фона кнопки — Background (11);
— Указанные выше яркие цвета можно применить не к тексту или иконке в кнопке, а к её фону. Тогда для её содержимого потребуется OnAccent (12);
— Кнопка в состоянии фокуса может иметь обводку с цветом Accent (с небольшим отступом, чтобы не сливаться, если у кнопки такой же фон), а в заблокированном состоянии — красить содержимое в цвет Disabled (13);
— Он же пригодится для плейсхолдера в поле ввода (логичнее было бы его назвать просто Tertiary);
— Также в статье есть о том, как подобрать цвета для этих токенов для светлой и тёмной темы.

Да, в заголовке статьи написано о 12 токенах, но это ошибка.

#color #design_system

Игорь Бутков понятно написал для начинающих о стилях, переменных и дизайн-токенах в Фигме.

— Минус стилей: если в большой дизайн-системе надо заменить один цвет на другой, каждый стиль придётся обновлять по отдельности;
— С переменными такой проблемы нет: цвет становится значением переменной (корневого токена), с которой можно связать другие переменные;
— Корневые токены варьируются по цветам и контрастности, например: purple-500;
— С ними могут быть связаны семантические токены — абстрактные названия, указывающие не на сам цвет, а его функцию, например: background.primary;
— Если нужна возможность отдельно настраивать, например, цвета кнопок, можно добавить компонентные токены, например: button.primary.default;
— Минус: таких токенов будет очень много;
— Преимущества абстрактных названий: если вместо button.purple будет button.primary, фиолетовый цвет можно легко заменить на розовый, и логика названий не сломается;
— Для обозначения числового шага используют S, M, L или числа с большим шагом: 100, 200, 300;
— Числа удобны, если размеров много и могут добавляться промежуточные шаги (250 добавить проще и он будет понятнее, чем 2L).

Токены Atlassian. #figma #design_system #color

Виктор Теплов рассказал, как работать с иконками в Фигме. А я немного дополнил из других источников.

— Иконку преобразуйте в векторную форму (flatten);
— Исходник полезно сохранить, чтобы не перерисовывать иконку, если в будущем потребуется её изменить;
— Назовите слой Vector. Это стандартное имя для таких слоёв. Можно удалить текущее название и нажать Enter, Фигма подставит слово Vector;
— Иногда слой называют Shape, чтобы название отражало суть;
— Чтобы цвета не слетали при смене иконок в компонентах: создайте копию слоя Vector, объедините эти 2 слоя (union), появится объединяющий слой с именем Union, удалите копию слоя Vector. Задавайте цвет слою Union;
— Иногда этот слой называют Color, чтобы отразить его суть;
— Если во всех иконках будут аккуратно названные слои Vector, то красить можно и их, цвета слетать не должны. Подход со слоем Union позволяет сохранить цвет, когда внутри иконки один вектор полностью меняется на другой;
— Лучше использовать обычный #000000, а не цветовой токен. Так в макетах и компонентах можно отследить, какие иконки не покрашены;
— Можно выбрать какой-нибудь необычный цвет (например, коричневый), чтобы он бросался в глаза, но не слишком, чтобы не усложнять просмотр иконок в библиотеке;
— Векторный слой иконки должен скейлиться;
— Расположите его внутри квадратного контейнера (например, 24×24 px);
— Называть компоненты иконок лучше по тому, что изображено (например, magnifying_glass), без префикса icon или обозначения размера;
— В поле Description можно записать синонимы, по которым могут искать такое изображение в ассетах (например, search);
— В компоненты вставляйте иконки и создавайте свойство Swap instance с именем icon, выбирайте свои иконки в Preferred values.

#figma #icon #design_system

Бо Кибза и Лёха Макаренко (дизайнеры дизайн-систем Альфа-Банка, Озона, Самоката и Почтатеха) рассказали о развитии системы цветов в ДС Туту.

— Легаси-ДС не дорабатывали, чтобы нигде ничего не отвалилось. Команды с большой автономностью локально допиливали компоненты под свои нужды;
— Хотели консистентности, единых стандартов и при этом пространства для свободы;
— Одним из требований к системе цветов была отзывчивость к изменениям, так как компания ребрендилась;
— В этом случае, если минимизировать возможность кастома, бардак накопится не в продукте, а в ДС, где его проще прибрать;
— Обычно делают слои токенов: палитра → семантика (подложки, обводки, текст) → компоненты (текст на кнопке);
— Ради скорости дизайна и разработки компонентов отказались от семантического слоя. Условие: не использовать цвета палитры напрямую, не оверрайдить цвета в покрашенных компонентах;
— Подход даёт очень много компонентных переменных, а также много мелких разночтений (вроде немного отличающихся подложек в чипе и лейбле);
— Зато дизайнеры успели попробовать компоненты в макетах и понять, что нужно единое решение для контрастных элементов и компоновки On white / On gray;
— On white больше подходит для коммуникационных экранов, On gray — для более интерфейсных, с формами и карточками;
— On gray экраны нельзя просто перевести в тёмную тему — бекграунд светится ярче, чем форграунд, и в интерфейсе появляются дыры;
— Можно завести в светлой теме 2 background и 2 panel цвета, которые в тёмной теме станут 1 background и 1 panel. Но как объяснить дизайнерам, какой из 2 цветов использовать?
— В итоге завели мод для переключения On white / On gray, и в светлой теме оставили 1 background и 1 panel;
— Мод On gray кроме цвета подложки может устанавливать, например, более тёмный цвет текста, чтобы сохранять контраст на более тёмном фоне;
— Также через мод Contrast (low, high) реализовали возможность делать отдельные элементы более контрастными;
— Таким образом, семантика построена на основе конкретных продуктовых запросов;
— Палитру всегда можно доделать потом;
— Удобно, когда семантические цвета в палитре находятся на одном уровне: можно сразу увидеть ошибку и в целом запомнить, что цвет текста — это 500;
— Также удобно иметь отдельную палитру для тёмной темы с интерпретированными цветами (можно оставить только те, что точно используются).

Статья на Хабре. #color #design_system

В Фигме появились слоты.

— Это области в компонентах, позволяющие вставить любое содержимое в инстансы этих компонентов;
— Они упрощают компоненты со списками элементов внутри вроде аккордеонов, меню и дропдаунов. В них можно размещать любое количество элементов (не надо заранее закладывать какой-то максимум) и легко менять их порядок;
— Проще работать с компонентами с высокой вариативностью содержимого. В компоненте карточки можно задать стиль подложки и заголовка, расположение контролов, а её содержимое — добавлять через слот;
— Алексей Бычков записал видео о слотах;
— В блоге Фигмы [English] также предлагают использовать их для работы с лейаутом страниц: фиксировать в компоненте меню, хедер и футер, а содержимым конкретной страницы управлять через слот;
— Забавно, что они противопоставляют слоты детачу или созданию сложных многовариантных компонентов. Раньше такую же задачу решали добавлением dummy-компонентов и их свапом в инстансах на локальные компоненты с нужным контентом. Но со слотами, конечно, удобнее;
— Консультант по дизайн-системам Нейтан Кёртис написал, как внедрять слоты в библиотеку компонентов [English];
— Как понять, где слоты будут полезны, какие компоненты снабжать слотами первыми (где чаще всего детач), какие настройки применять (без контента, с контентом, списком предпочитаемых компонентов и без него);
— Правила лейаута слотов: не задавать цвет, обводку, скругление углов, паддинги. Паддинги лучше задавать в контейнерах, в которых будут располагаться слоты. Слот должен отвечать за лейаут, направление, отступы между элементами и изменение размеров.

#figma #design_system

Алексей Макаренко рассказал об автоматизации доставки логотипов разработчикам.

— Старый порядок: экспорт ×4 в формате png, оптимизация через приложение ImageOptim, переназывание, загрузка в общую папку с логотипами;
— Со временем появились папки для тёмной и светлой темы, для лого, вписанных в квадрат;
— В Фигме через плагин SVG Export цветные логотипы экспортировали с дефолтным пресетом (просто чтобы сжать), а монохромные — с пресетом Correct color (чтобы разработчики могли красить их в любой цвет);
— Новый порядок: собственный плагин, который смотрит на свойства компонента с изображением логотипа и называет экспортируемый файл, например, avrora_color_dark_compact_square, экспортирует архив с png и svg;
— Дизайнер сохраняет архив в репозиторий, где хранятся логотипы, и запускает bash-скрипт. Он раскрывает архив, оптимизирует файлы (такие же алгоритмы, как в ImageOptim и SVG Export), раскладывает по папкам и называет logo.png и logo.svg;
— Иерархия папок учитывает, что логотипы могут быть цветными и монохромными, цветные варианты нужны для тёмной и светлой темы, также они могут быть широкими и компактными, а компактные — вписанными в круг, квадрат и без формы;
— Вписанный в квадрат логотип компании Avrora для тёмной темы в формате png доступен по адресу logos/avrora/color/dark/compact/square/logo.png;
— Разработчики используют компонент логотипа и обращаются к конкретному файлу в папке.

#image #figma #design_system

Виктор Теплов рассказал, как дизайнеру работать с ИИ.

— Тест Патрика: чаще вы соглашаетесь с ИИ или он с вами? Если вы, то готовьтесь потерять работу;
— Опасные сценарии: профи-скептик не разбирается в ИИ, использует его на удачу и сразу видит некачественный результат; энтузиаст-профан лезет в незнакомую область и полностью доверяет ИИ; дофаминовый наркоман радуется быстрому результату и делает 5 проектов (и ещё 7 в уме);
— ИИ — не партнёр, а инструмент. Человек становится автором продукта и берёт ответственность, когда нажимает на «Принять изменения»;
— По умолчанию ИИ выдаёт массово-приятный результат, похожий на музыку в лифте, которая не бесит, но и не цепляет. Это хорошо для интерфейсов, так как привычные паттерны удобны. Но плохо для творчества, бренда и голоса продукта, где нужна узнаваемость;
— Дизайнеры, которые не хотели разбираться в функциях программ, но хотели «сделать красиво», раньше использовали плагины. Не понимаешь, как работает свет, — плагин Cinematic LUT;
— ИИ может сгенерировать артефакты по фреймворкам вроде JTBD, CJM, Personas, но не может взять на себя ответственность за принятое решение;
— Не получится найти ИИ-инструмент, который просто сделает то, что нужно. Придётся разбираться, как добиться в нём нужного результата;
— План: опишите образ результата, критерии качества и ограничения (что делаем, для кого, в каких условиях). Итерации: делите задачу на шаги, фиксируйте изменения и промежуточные артефакты. Проверка: просите ссылки на первоисточники, объяснить сделанный выбор, дать альтернативы и подсветить риски;
— Рутину надо делать быстро, одинаково и без ошибок. Дизайнер дизайн-системы либо автоматизирует, либо тонет. Раньше для автоматизации надо было стать немного разработчиком, сейчас порог входа снизился. Но ИИ не должен быть автором архитектуры;
— Например, плагин для сбора типографских variables в JSON-стили и построения витрины стилей, плагин для создания шрифта из иконок дизайн-системы;
— Работа с цветовыми токенами. Опишите контракт: структура токенов, устройство имён, запреты, эталонные примеры. Попросите выполнить операцию: добавь новый токен в core-палитру и создай семантический токен bg.main.primary на его основе, добавь во все тематические и брендовые палитры;
— Сначала в режиме Plan, когда ИИ ничего не делает с файлами. Затем просите не только изменить файлы, но и показать изменения, объяснить, почему они соответствуют правилам, подсветить риски, поискать дубли, проверить ссылки;
— В Figma Make можно быстро сделать прототип, проверить поведение компонента в корнер-кейсах и принять решения по вопросам, которые часто всплывают уже во время реализации в коде;
— Доступность инструмента лишь подчёркивает искусность мастера. Кто-то может порубить топором дрова, а кто-то построить дом. Важен опыт, вкус и логика. ИИ не заменяет мастерство, а позволяет делать быстро, много и предсказуемо.

Копия в ВК Видео. #ai #design_system

Лёха Макаренко рассказал, что делать дизайнеру дизайн-системы, если продуктовому дизайнеру понадобился элемент, которого нет в ДС.

— Этот элемент может отличаться от готовых компонентов ДС визуалом или логикой. Например, нужен инпут с маской под номер банковской карты и определением платёжной системы;
— Не стоит решать за дизайнера. Лучше предложить 3 варианта;
— 1. Использовать существующий компонент, выполняющий базовую функцию, но менее удобный и не такой эстетичный. Например, обычный инпут;
— 2. Провести необходимые исследования и прийти к команде ДС с обоснованием, что такой компонент необходим. В идеале он должен переиспользоваться другими командами. Этот путь может занять время;
— 3. Сделать кастомный элемент таким, как хочется. Надо будет проработать все нужные состояния, предусмотреть его работу в тёмной теме и так далее;
— Такой подход позволяет прозрачно планировать развитие продукта и управлять дизайн-долгом;
— Выбрав один из вариантов, со временем можно от него отказаться. Например, сделать кастом и потом затащить его в ДС либо заменить его на базовое решение. Или попробовать простой вариант, а потом кастомный.

#design_system

Денис Зеленых написал о подходе «Атомарная матрёшка» к организации дизайн-системы.

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

Иерархия отражается и на структуре файлов в Фигме: набор сценариев в рамках пользовательской истории (страница файла) → все сценарии модуля (файл) → сервис (папка) → продукт (командное пространство). Легко искать нужные макеты.

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

У Фигмы есть ограничение в 2 ГБ на вкладку, в которые должны уместиться и файл, и все подключённые библиотеки. Глобальный UI-кит включает дизайн-токены, базовые компоненты и универсальные элементы. Продуктовая библиотека — общие шаблоны, навигацию, паттерны продукта. Сервисные и модульные библиотеки — всё сложное и специализированное: экраны, тяжёлые лейауты, паттерны взаимодействия.

Подход «Файл на компонент» подходит сверхкрупным компаниям. В обычных командах минусы перевешивают плюсы: падает производительность (медленнее отклик системы), больше рутины (правки надо проводить по цепочке файлов).

Не всё в компоненте должно быть вариантом. Простые штуки вроде скрытия иконки, подмены контента и изменения текста надо делать через свойства компонента: boolean, instance swap, text. Это уменьшает комбинаторику вариантов даже сильнее, чем дробление по неймингу («button / basic», «button / icon»).

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

Когда есть один однозначный компонент с понятными вариантами, токенами и маппингом на код, то и ИИ меньше ошибается.

Дополнение подхода экосистемой продуктов. #design_system #figma