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

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