Я дизайнер продуктов и в последнее время много работаю с библиотекой компонентов пользовательского интерфейса в своей компании. Я участвую в различных процессах обслуживания библиотеки, а также вношу в нее непосредственный вклад.
В течение последних нескольких месяцев моя команда пыталась поднять планку эффективного общения между дизайнерами и разработчиками, чтобы улучшить качество реализации компонентов, композицию дизайна (визуально и поведенчески) и упростить поддержку. В этой статье я хотел бы поделиться своим опытом выстраивания общего языка в команде с помощью символов дизайна и показать примеры интеграции, которые мы используем.
Иконки дизайна
Иконки дизайна — это базовые единицы дизайна интерфейса, основные компоненты пользовательского интерфейса: цвета, стили шрифтов, стили теней, размеры отступов и т. д. Иконки можно использовать на любой платформе и в любом продукте, использующем компоненты с их поддержкой. Начало истории использования символов дизайна лежит в 2014 году после публикации сообщения в блоге отдела продаж. С тех пор эта концепция была принята многими компаниями по всему миру, которые используют системы проектирования или библиотеки компонентов для разработки своих цифровых продуктов.
Наиболее важным преимуществом использования иконок при разработке интерфейса является налаживание связи между дизайнерами и разработчиками. Многие из вас наверняка знакомы с проблемами, связанными с соглашениями об именах, стандартизацией повторяющихся элементов и так далее. Символы помогают решить эту проблему на фундаментальном уровне. Например, ваши команды могут иметь названия для цветов, шрифтов, округлости и т. д., чтобы эффективно обмениваться идеями и решениями.
Еще одним преимуществом использования иконок является тематика интерфейсов. Допустим, у вас есть продукт A и продукт B, и они используют общую библиотеку компонентов пользовательского интерфейса. Пользователи должны четко понимать, какой продукт они используют, а компании должны эффективно позиционировать продукты в маркетинге. Итак, команда дизайнеров решает использовать другой акцентный цвет и шрифт в продукте Б.
Примеры тем объектов
При отсутствии иконок разработчикам может потребоваться переопределить значения в исходных стилях компонентов или создать дубликаты компонентов. Такой подход неэффективен и может привести к большому количеству проблем в будущем, от построения до тестирования. Гораздо удобнее иметь конфигурацию, которая определяет, как отображать или изменять компоненты. Другими словами, список символов, который, в зависимости от требований платформы или инфраструктуры, может быть списком переменных CSS или констант в коде, используемых для переопределения основных переменных в интерфейсе.
Примеры использования символов в коде
Темы можно использовать не только для визуального разделения продуктов, но и для решения практических задач по созданию приятного опыта использования продуктов: адаптация элементов под размеры устройств, уменьшение/увеличение плотности элементов для повышения юзабилити, решение проблем разделения интерфейса для людей. с нарушениями зрения. На этом список возможностей не ограничивается. В зависимости от того, какие цели вы будете решать с помощью символов, вы сможете более гибко управлять глобальными изменениями в своих интерфейсах.
Пример доступного интерфейса темы наподобие Twitter
Подводя итог вводно-теоретической части, символы имеют ряд преимуществ при их использовании:
- Выстраивание отношений между дизайнерами и разработчиками, формирование общего языка (лексики) и средств общения;
- Простая тема интерфейса, экономит ресурсы при настройке библиотеки компонентов за счет централизованного управления;
- Улучшенный пользовательский опыт в разрезе платформ, доступность интерфейсов (accessibility) и т.д.
Определение владельцев
Начните с введения символов, в первую очередь следует определиться с группой, которая будет определять структуру, название и правила использования символов. Выбор зависит только от имеющихся ресурсов, времени и уже существующих процессов в компании. Есть несколько вариантов:
- Выделенная команда дизайнеров и разработчиков, обеспечивающая поддержку библиотеки (лучший, но зачастую «дорогой» вариант);
- Команда дизайнеров с консультационной поддержкой команды разработчиков;
- Когда дизайнеров поддерживают дизайнеры.
В последних двух вариантах важно учитывать, откуда исходят требования и инициатива по изменению вашей библиотеки. Если дизайнеры выступают движущей силой изменений, было бы не совсем уместно оставлять роль управления токенами исключительно команде разработчиков. Этот подход приведет только к высокой десинхронизации или высокой координации из-за бесконечных компромиссов с разработчиками.
Предпочтение дизайнерам в большинстве случаев оправдано тем, что компании или пользователи обычно приносят запрос на изменения продуктовой команде, так как дизайнеры играют одну из ключевых ролей в формулировании решений, которые затем реализуются дизайнерами.
Правила изменения также играют важную роль. Очевидно, что добавление или изменение значений токенов — наименее эффективная операция. Хотя удаление может привести к поломке больших частей вашей библиотеки, здесь лучше следовать строгим правилам редактирования.
Методы именования
Особо стоит упомянуть историю с названием иконы. Наиболее эффективные способы именования значков улучшают и поддерживают общее понимание визуального стиля вашей команды с помощью дизайна, кода и других средств. Существует много методов, и выбор полностью зависит от вас и вашей существующей инфраструктуры проекта.
В общем, мы используем соглашения об именовании рядом с пространствами имен (namespaces). Это многоуровневая система, в которой используются абстрактные, функциональные или семантические имена. У каждого метода есть свои преимущества и недостатки, и я редко видел их применение в чистом виде, чаще — в виде комбинации.
В абстрактном именовании часто используются наиболее распространенные термины. Главный плюс — гибкость масштабирования. Минусом является сложность выбора при подаче заявки из-за слишком общего названия.
// Абстрактные токены
$color-core-main
$typo-heading-250
$spacing-100
$size-s
Функциональный подход, как следует из названия, часто отражает место или способ использования. Я бы сравнил этот подход с именованием стилей в БЭМ. Кстати, в этом методе часто используются сложные иерархии с наследованием — это позволяет более точно контролировать изменения, но усложняет процесс поддержки.
Пример практического подхода к неймингу
Метод маркировки представляет собой компромисс между двумя упомянутыми выше методами. Название каждой иконки должно говорить само за себя, часто с умеренным уровнем абстракции и функциональности, что делает ее максимально простой в использовании. Главный недостаток — масштабируемость.
// Семантические токены
$color-neutral-text-regular
$color-accent-bg-strong-hover
$typo-heading-title-bold
$spacing-x-regular
Если ваша система компонентов довольно стабильна и не слишком часто меняется с течением времени, то функциональный или семантический подход, скорее всего, подойдет вам. В остальных случаях лучше рассмотреть комбинации методов.
Несколько ссылок по теме, где методы нейминга рассматриваются на примерах:
- Именование символов в дизайн-системах (нет);
- Именование символов дизайна (нет);
- Полное руководство по дизайну иконок.
Примеры интеграции
Важно не только придумать номенклатуру, но и начать использовать символы. Использование включает в себя не только использование символов разработчиками в своих инструментах, но и программистами в коде, но и процессы синхронизации и доставки символов из одной среды в другую. Сейчас есть несколько инструментов для автоматизации этого процесса, например Знак дизайна. В данном примере хотелось бы рассмотреть интеграцию Figma и сервиса Сверхновая обеспечивать управление токенами и их доставку в кодовую базу.
Процесс состоит из нескольких этапов:
- Создание и публикация библиотеки стилей в Figma
- Синхронизация библиотек с Supernova
- Экспорт настроек
Принципиальная схема интеграционных процессов
1. Создайте и опубликуйте библиотеку стилей в Figma
Со стороны дизайнера управление иконками частично осуществляется в Figma с помощью стилей. Например, поддерживаются цвета, типографика и тени. Сейчас это самое слабое звено в процессе синхронизации. Плагины следует использовать, если нужны другие типы значков или возможно переключение тем.
Я готов пример файлагде я создал иконки (стили), поддерживаемые Figma. Я использовал семантический подход к названию по структуре: тип-роль-значение-состояние. Внутри я также оставил несколько примеров имен для каждого уровня структуры.
Пример файла Figma (коллекция) со стилями
Чтобы использовать Supernova, важно соответствовать критериям, согласно которым файл стиля должен быть библиотекой и быть опубликованным. Если вы копируете файл к себе, не забудьте это сделать.
Публикация файла Figma в виде библиотеки
2. Синхронизация библиотек с Supernova
Следующим шагом будет добавление библиотеки Figma в Supernova для синхронизации. На первом экране после регистрации будет доступна кнопка «Добавить источник данных», в открывшемся окне добавьте ссылку на файл Figma с библиотекой и выберите импорт стилей. Я не использую опцию автоматического обновления в первую очередь из-за желания управлять изменениями вручную (помимо того, что это платная опция).
Добавляет библиотеку Figma в Supernova
После успешной синхронизации вы получите отчет о загруженных иконках. Вы можете столкнуться с ошибкой, если библиотека Figma не была опубликована, и предупреждениями, если некоторые стили не используются или возникают конфликты импорта.
Успешный импорт библиотеки Figma
Supernova позволяет не только синхронизировать стили из Figma, но и добавлять недостающие значки (размер границы, скругление, отступы и т. д.). Все синхронизированные значки отмечены логотипом Figma. Вы также можете добавить отсутствующие значки, нажав кнопку «Новый значок», такие значки будут недоступны для Figma, но будут добавлены в сборку.
Список портированных иконок в разделе “Содержание/Иконки”
3. Экспорт настроек
В разделе “Интеграция/Магазин кода” вы можете найти готовые экспортеры. Для примера я взял экспортер CSS, который размещает символы в параметрах CSS. Вы можете увидеть пример экспорта для установки. Добавьте тот, который вам подходит. В зависимости от ваших целей и задач вы можете настроить более точную выгрузку иконок с помощью собственные экспортеры.
Предварительный просмотр экспортера значков CSS
После добавления экспортера нам нужно добавить место для загрузки сборки. Для этого перейдите в раздел «Интеграция кода/хуки» и создайте новый хук, который будет вызываться при обновлении исходников. В качестве цели у меня есть репозиторий на GitHub. Процесс подключения стандартный: указываем ссылку на репозиторий, ветку и путь, даем доступ Supernova для создания пулл-реквеста.
Добавляет новый хук для отслеживания обновлений.
Теперь после получения новых обновлений от Figma (автоматически или вручную после нажатия «Получить все обновления» в разделе «Контент») будет вызываться хук и создаваться пулреквест. В платной версии вы можете устанавливать автоматические обновления, не нажимая эту кнопку.
Пример запроса на вытягивание с обновлениями токенов в репозитории
Интеграция настроена! Теперь разработчики могут отправлять изменения значков непосредственно в репозиторий, опубликовав измененную библиотеку и нажав кнопку «Получить все обновления» в разделе «Содержимое» Supernova (или это будет сделано автоматически, если вы используете платную версию). После получения обновлений, если все в порядке, будет выполнен хук обновления и сгенерирован пулл-реквест.
Таким образом, вы можете создать интеграцию между библиотекой дизайна и репозиторием кода. Все команды будут использовать один набор значков, иметь возможность выбирать темы и настраивать элементы.
Полезные ссылки
В заключение я собрал упомянутые ссылки, которые могут оказаться полезными в ваших исследованиях по этой теме:
