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

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