Как привести библиотеку блоков в Figma в порядок
Всем привет! Меня зовут Галя, я дизайнер команды продуктового web-дизайна t2.digital. Сегодня хочу поделиться своим опытом, как я привела в порядок библиотеку блоков. Это Figma-файл, в котором мы создаем и храним более крупные и составные компоненты для разных стримов и продуктов. С ней мы взаимодействуем практически каждый день.
Предисловие:
Я присоединилась к команде Т2 в июле 2024 года (еще до ребрендинга, когда компания называлась Tele2). Как и любому новичку, мне предстояло пройти через онбординг и разобраться во всех процессах, библиотеках и дизайн-системе (далее буду называть ДС).
У web-команды уже были прописаны довольно детальные гайды по работе с новой ДС, взаимодействию с коммуникационными дизайнерами, UX-редакторами и другими командами, но гайда по работе с библиотекой не было. Из-за этого в ней царил творческий хаос. Было трудно отыскать нужный компонент и еще сложнее адаптировать его под свои нужды, ничего не сломав.
Для контекста важно понимать, что все это усугублялось предстоящим официальным ренеймингом/ребрендингом/редизайном – то есть большим объемом приоритетных задач и жесткими сроками разработки.
На первых порах было непонятно, где использовался тот или иной компонент, поэтому я проводила довольно много времени в поисках нужного. С этой болью я пришла на «one-to-one» к своему чудесному лиду Илоне, которая предложила мне заняться оптимизацией библиотеки в рамках годовой цели. Как видите, упрашивать меня не пришлось! 😉
Что такое библиотека блоков?
В T2 мы следуем принципам атомарного дизайна при разработке пользовательских интерфейсов. Что это значит? Интерфейс строится из взаимосвязанных компонентов, которые организованы по уровням сложности:
- атомы – базовые элементы;
- молекулы – простые комбинации атомов;
- организмы – сложные компоненты из молекул;
- шаблоны – разделы страниц;
- страницы – финальные макеты.
Базовые компоненты (атомы и молекулы) хранятся у нас в UI-ките ДС. Это такие компоненты, которые переиспользуются по всему сайту (например, кнопки и инпуты).
Библиотека блоков предназначена для создания и хранения более крупных и составных компонентов (молекул, организмов и шаблонов), которые тоже переиспользуются, но не так часто, как компоненты ДС. Например, это «начинки» для попапов или карточек.
Помимо библиотеки блоков, в этом году мы также начали разрабатывать полноценную библиотеку сценариев, но об этом расскажем позже.
Принцип атомарного дизайна имеет свои преимущества:
- ускоряет проектирование макетов за счет использования готовых компонентов;
- упрощает управление всеми элементами интерфейса на различных уровнях проектирования;
- обеспечивает единообразие визуальных паттернов по всему сайту, что создает целостный пользовательский опыт.
Благодаря этому:
- пользователи получают интуитивно понятный и предсказуемый интерфейс;
- разработчики могут максимально эффективно использовать готовые решения;
- команда экономит время вывода продукта на рынок.
Короче, одни плюсы!
Определение проблемных зон
И вот я принялась за дело. В первую очередь проанализировала, насколько команде необходима оптимизация библиотеки блоков. Напомню, все происходило в разгар работы над ребрендингом, поэтому было важно не нарушить текущие процессы дизайн-команды своими наполеоновскими планами по изменению библиотеки.
Поэтому я провела индивидуальные встречи с каждым дизайнером, чтобы понять, как они взаимодействуют с библиотекой, определить проблемные зоны и собрать пожелания по улучшению процессов.
Основные проблемы, с которыми сталкивалась команда:
- неудобно, сложно ориентироваться в пространстве библиотеки;
- захламленность;
- отсутствие единой практики создания и работы с компонентами и вариантами.
Дальше я пошла анализировать саму библиотеку и обнаружила ряд проблем:
- Повторяющиеся компоненты. Из-за хаоса в пространстве ребятам было сложно найти нужный компонент, поэтому часто создавались дубли – компоненты со схожим наполнением (например, компонент из автолейаута с заголовком, инпутом и кнопкой).
- Некорректные нейминги. Поиск нужного компонента усложняется, поскольку Figma группирует их в соответствии с неймингом. Поэтому, если мы собираем вложенный компонент для более крупного из дизайн-системы, например, popup, то и название первого уровня должно быть //popup/..., а не //pop-up/... или //modal/.... Нейминги должны строго соблюдаться для корректной иерархии в библиотеке.
- Неуниверсальные настройки компонентов. Например, не настроены свойства отображения, из-за чего сложно переиспользовать компонент. Ребятам иногда было проще и быстрее создать новый компонент с нужными настройками, чем пытаться переиспользовать похожий. И снова привет, захламление!
- Отсутствие привязок к стилям и переменным ДС. Это тоже усложняет переиспользование компонента, так как он, можно сказать, уже не наследует свойства ДС. Например, если у компонента или его составных частей отвязаны цвета, то переключиться на темную тему за один клик уже не получится. К тому же в условиях ребрендинга важно было убедиться, что во всех компонентах используются корректные новые шрифты.
Как я лечила библиотеку блоков
- Проконсультировавшись с командой дизайн-системы, я решила вынести повторяющиеся компоненты в отдельную секцию. Это упростило бы их последующую унификацию в рамках ДС, а не библиотеки блоков.
- Если с первым пунктом было более или менее понятно, то для следующих трех требовалась стандартизация работы с компонентами. Я решила подготовить гайд по использованию библиотеки блоков: прописала правила нейминга компонентов и работы с вариантами и свойствами, основываясь на принципах дизайн-системы. В процессе сразу правила и настраивала свойства компонентов в соответствии с гайдом.
- Для проверки залинкованности стилей и переменных я использовала плагин Style Organiser. Также прописала в гайде необходимость регулярного рефакторинга созданных компонентов, чтобы поддерживать библиотеку в порядке.
- Боль со сложной навигацией в библиотеке и поиском нужного компонента решили лечить с помощью реорганизации пространства по стримам (командам/ продуктам). Также решили добавить описание компонентам, которое может помочь при поиске или выборе нужного компонента при использовании Instance Swap. В описании можно указать, из чего состоит компонент, где применяется, и любые другие примечания относительно его использования.
Все вышеперечисленное позволило нам улучшить работу с библиотекой блоков. Теперь мы быстрее находим нужные компоненты и легко можем их адаптировать под свои нужды.
Удалось ли ее привести к идеальному виду? Нет – но к идеальности мы и не стремились. Библиотека блоков – это живой организм: она растет и изменяется каждый день. А там, где развитие, всегда есть небольшой хаос ;)