Казалось бы, дизайн‑система — это инструмент, который помогает ускорить процесс разработки продуктов, облегчает масштабирование и обновление, обеспечивает единообразие дизайна и пользовательского опыта на всех платформах. Однако мы убедились на собственном опыте, что это не панацея, и если все связанные с дизайн‑системой процессы не будут налажены, то для компании она станет ахиллесовой пятой.

Привет, Хабр! Меня зовут Виктория Марухняк, я дизайнер интерфейса продукта Polymatica Dashboards. Мы разрабатываем BI‑платформу, и нам критически важно проектировать простой и удобный интерфейс, чтобы пользователи могли легко строить и читать аналитические отчеты. В этой статье поделюсь своим первым опытом рефакторинга и обновления дизайн‑системы и тем, как это помогло нам наладить общение между дизайнерами и разработчиками. Без прикрас и розовых пони.

Почему мы решили, что пора обновлять дизайн-систему

Чуть больше года назад я начала работать дизайнером интерфейса в команде Polymatica. На тот момент многие процессы в отделе дизайна не были налажены и нуждались в решениях. Это и проблемы с коммуникацией как между отделами, так и внутри, и несогласованные методологии проектирования, и перекидывание отдела из управления одного департамента в другой. Самое важное, что общение с разработчиками осуществлялось посредством сломанного телефона через аналитиков, что доставляло много проблем — в интерфейсе были несоответствия. Как следствие, в сложившейся ситуации говорить о грамотной работе с дизайн‑системой и уж тем более ее обновлении не приходилось. Но постепенно, разделяя процесс на небольшие итерации, мы начали собирать пазл из 5000 деталей в одну картину.

Исторически сложилось, что для реализации платформы была выбрана дизайн‑система (далее ДС) Shoelace, но ее наличие не помогло создать единый опыт в компании, а наоборот, вызвало ряд трудностей.

1. Несоответствие версий

Версия библиотеки компонентов у дизайнеров не соответствовала версии у разработчиков. Это создавало путаницу между нашими отделами и приводило к несовпадению внешнего вида и поведения элементов интерфейса.

2. UI-библиотека юрского периода

Наша UI‑библиотека была как старенькая машина — вроде ездить можно, но уже некомфортно и хлопот вызывает много. Основная проблема заключалась в том, что компоненты библиотеки не были проработаны для удобного использования. Отсутствовали четко сформированные варианты, типы, размеры и возможность скрывать содержимое в панели инструментов. При смене состояния приходилось заново менять наполнение компонента, ковыряясь в слоях, а вишенкой на торте стали стили, которые просто не подтягивались.

Дальше — больше. Помимо неполного соответствия функциональности Figma, наша UI‑библиотека содержала довольно скудный набор компонентов. Очевидно, дизайнеры пилили свои компонентики в своих же макетах, где они благополучно оставались жить. Что‑то уходило в прод, а что‑то так и оставалось пылиться. Как итог, другой дизайнер периодически примерял на себя роль «Даши‑путешественницы» и отправлялся на поиски компонентов по всем макетам в Figma.

Не могу не отметить, что и сам дизайн компонентов морально устарел и требовал современного переосмысления, но это сильно меркло на фоне других трудностей.

В результате мы сталкивались со значительным замедлением процесса разработки макетов, постоянной ручной работой с компонентами и проблемами в совместной работе команд.

3. Несогласованность изменений

Столкнуться с проблемами в коммуникации можно даже в небольшой команде. Были ситуации, когда дизайнеры проектировали разнородные решения, используя вручную разработанные компоненты. Один и тот же экран у двух дизайнеров мог выглядеть по‑разному, а ревью предполагалось только в команде разработки. Еще одной ложкой дегтя стала регулярная практика, когда изменения вносились в макеты после их отправки в разработку, но они не были согласованы со всеми задействованными в процессе сотрудниками. Это приводило к недопониманиям и несоответствиям в интерфейсе.

4. Использование разных UI-библиотек

Постепенно, с увеличением команды, начали формироваться личные UI‑киты, которые каждый использовал по‑своему. Отсюда несогласованность внешнего вида и оформления интерфейса в рамках одного продукта. Эффективность работы снижалась, тратилось время на создание компонентов, которые уже существовали в другой библиотеке, а процесс онбординга новых сотрудников удлинялся в несколько раз.

Все это не только затрудняло сотрудничество и обмен опытом внутри команды, но и существенно сказывалось на качестве конечного продукта. Различия в стилях, идентичных компонентах, отображении спроектированных экранов создавали впечатление недоработанности и негативно сказывались на пользовательском опыте.

Ресурсы и сложности на старте. Выбор пути

Может показаться, что приступить к обновлению дизайн‑системы и налаживанию связанных с ней процессов не трудно. Но, как уже было написано во множестве других статей, дизайн‑система — это комплексный подход к проектированию и разработке продуктов, основанный на создании единого набора стилей, компонентов, принципов и руководств. И важнейшим аспектом здесь является стандартизация — гайдлайны, описывающие для чего и как использовать те или иные элементы, и что учитывать при создании новых. Но на старте мы имели сильно меньше, чем сказано выше.

Стартовые данные
Стартовые данные

Вариант

Плюсы

Минусы

Найти для себя новую, хорошо проработанную дизайн‑систему.

Экономия времени и ресурсов, улучшенная поддержка и обновления, расширенный функционал, современный дизайн.

Ограничения в индивидуальности и гибкости, зависимость от стороннего поставщика системы, совместимость и интеграция.

Доработать собственный маленький UI‑кит до полноценной дизайн‑системы.

Индивидуальность и гибкость, полный контроль над процессом, укрепление бренда, современный дизайн.

Временные и финансовые затраты, риск ошибок и недочетов, сложности масштабирования.

Провести рефакторинг и обновление текущей дизайн‑системы Shoelace.

Улучшение эффективности работы, мягкие изменения и улучшения пользовательского опыта, современный дизайн.

Временные и финансовые затраты, риск ошибок и недочетов, сложности масштабирования.

Мы изучили Carbon Design System, PrimeNG, NG‑ZORRO, сопоставили все минусы и плюсы, оценили этапы проектирования, разработки и тестирования и решили, что для нас самым эффективным будет рефакторинг и обновление текущей дизайн‑системы.

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

Поскольку в качестве центральной технологии системы проектирования мы решили оставить Shoelace, то ключевые задачи заключались в том, чтобы со стороны разработки обновить дизайн‑систему до последней версии, исправив все возникающие в процессе поломки, а со стороны дизайна — собрать в единую библиотеку все необходимые компоненты, спроектировать их под текущую функциональность Figma, освежить дизайн и разработать гайды по применению. Рефакторингом и обновлением ДС занимался один дизайнер (я), а количество разработчиков менялось в зависимости от их занятости продуктовыми задачами.

Теперь подробнее, что мы делали со стороны дизайна. Это был мой первый опыт переработки ДС, поэтому я начала с изучения информации о том, как вообще правильно спроектировать дизайн‑систему, что в ней должно быть и как с помощью нее улучшить взаимодействие команд разных отделов. Базовыми принципами для меня стало налаживание коммуникаций и улучшение работы с макетами всех причастных, чтобы коллеги понимали, что использовано на макете и для чего. Тогда я и узнала, насколько велик и могуч гайдлайн в ДС.

Структура библиотеки

Я разработала для себя четкую структуру обновленной библиотеки. Изучила новую версию ДС Shoelace и сопоставила ее с нашими компонентами — получилось, что нам необходимо переработать и осовременить типографику, цветовые стили, иконки и 24 компонента (звучит не так уж и много). Чтобы предотвратить перегрузку и подтормаживание библиотеки, я решила проектировать из принципа 1 компонент = 1 страница. Тогда были созданы страницы под каждый элемент библиотеки, где каждая из них содержала статус для идентификации процесса разработки.

Навигация по библиотеки с актуальными статусами работы
Навигация по библиотеки с актуальными статусами работы

За основу был взят атомарный подход, поэтому типографика и цвета стали фундаментом библиотеки. Появились группы шрифтовых стилей для заголовков, подзаголовков, основного текста и подписей. Среди цветовых стилей были выделены основной, акцентный и стили для разных типов уведомлений.

Hidden text

Поскольку мы занимались именно рефакторингом и обновлением уже используемой ДС, то каждая страница новой библиотеки содержала экран изменений, в котором подробно описывалось, какие изменение повлекло за собой обновление и что конкретно необходимо изменить/добавить.

Экран изменений, которые претерпел компонент
Экран изменений, которые претерпел компонент

С иконками пришлось знатно попотеть. Мы не рисовали их заново, а использовали Bootstrap Icons, соответствующий Shoelace, но у наших иконок были «разноперые» слои, типы вектора и наименования, которые вызывали проблемы с подтягиванием стилей в компонентах. Поэтому тут я запарилась, распределила иконки по категориям, создала для каждой один слой вектора с заливкой и переименовала их все по единому принципу. Если честно, все это получилось не сразу, а методом проб и ошибок. Одна эта задача заняла 5 дней, но на выходе мы получили полный, соответствующий нашей системе, набор иконок, который больше не включает капризулю при изменении цветов в компонентах. И если у вас возникает вопрос, а как же обезопасить себя в аналогичных случаях, то очень рекомендую видосик Виктора Теплова про пуленепробиваемые иконки.

Страница иконок
Страница иконок
Распределение иконок по категориям
Распределение иконок по категориям

Для страницы компонента был разработан четкий шаблон с первоначальной документацией и сценариями использования.

Каждая страница библиотеки стала содержать в себе несколько смысловых блоков:

  1. Название и описание компонента.

  2. Анатомия компонента.

  3. Параметры компонента.

Из таких сухих списков обычно не складывается полное представление, поэтому погнали смотреть на примере селекта.

Название и описание компонента

Этот блок позволил создать общий язык для всех членов команды и упростить коммуникацию с разработчиками, снижая риск недоразумений и ошибок.

Анатомия компонента

Тут хранится информация о ключевых паддингах, размерах и обозначениях внутренних элементов. Благодаря этому любой разработчик и дизайнер будут точно знать, какие значения должны быть у каждого элемента, что обеспечивает консистентность и упрощает тестирование.

Параметры компонента

Это основной блок с описанием применения компонента, его состояний, размеров и другой специфичной информацией. Он выступает ключевым элементом в создании эффективной, согласованной и высококачественной дизайн‑системы.

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

Подводя итоги о гайдлайнах для компонентов

Не буду говорить, что составление гайдлайнов было простым. Для этой работы потребовалось:

  • тщательно изучить текущие компоненты дизайн‑системы не только с визуальной, но и технической стороны,

  • сравнить текущие компоненты с лучшими практиками индустрии и нашими представлениями об обновленном интерфейсе платформы,

  • описать компоненты так, чтобы команды разных отделов одинаково понимали смысл написанного,

  • постоянно общаться с разработкой для согласования и уточнения тех или иных аспектов,

  • править документацию после дизайн‑ревью компонентов, реализованных на фронте.

Внедрение такой структуры помогло сократить количество обращений и вопросов разработчиков к дизайнерам, что сделало работу более эффективной, а тестировщики смогли улучшить качество продукта, быстрее диагностируя недоработки и ошибки.

А что с самими компонентами?

Качественная разработка компонентов в ДС требует хорошего понимания функциональности Figma и внимания к деталям. Я поставила для себя ключевую задачу по переработке старых компонентов таким образом, чтобы учесть все их возможные варианты, состояния и нюансы. В будущем это сэкономит время проектирования интерфейсов на компонентах со всеми «обвесами». При этом важно сохранить логику настроек и удобство работы с ними.

Вернемся к селекту и сравним реализацию компонента из старой и новой библиотеки.

Старая библиотека Shoelace

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

Конечно, отображение внутренних элементов можно менять с помощью слоев, но, во‑первых, наши компоненты содержали в себе их великое множество, а во‑вторых, при проектировании целых экранов вечное ковыряние в слоях увеличивало время работы дизайнера примерно в 2–3 раза.

При попытке изменить состояние все настроенные в селекте данные и отображения слетали, что заставляло наполнять компонент заново и увеличивать время проектирования. Получается муторно и грустно:

Новая библиотека Shoelace

Страница компонента стала содержать в себе несколько component set: label, help message и select. Каждый сет имеет характерные для него настройки:

  • label: выбор размера, отображения подсказки и иконки,

  • help message: выбор типа сообщения и отображения иконки,

  • select: выбор размера, состояния, отображения и вида иконки.

Select‑combobox имеет комплексные настройки по каждому сету и свои собственные. Работа с этим компонентом дает нам большую вариативность при проектировании интерфейса и не требует постоянного перехода в панель слоев или библиотеку, что увеличивает скорость выхода новой функциональности. Теперь можно выбирать отображение контента внутри, состояния, типы подсказок и ничего не будет слетать. Сплошное удовольствие и медитация)

Разработка таких настроек стала одним из самых трудозатратных и интересных этапов. Нужно было смотреть не только широким взглядом на всю систему и ее светлое будущее, но и детально всматриваться в мелочи, которые являются фундаментом любого интерфейса. Это потребовало много внимания, концентрации и проверки всех деталей и связей по несколько раз. Я составила свой чек‑лист проверки библиотеки перед публикацией, который помог мне обратить внимание на упущенные моменты:

  1. Общие проверки:

    • все необходимые компоненты добавлены в библиотеку и находятся в соответствующих категориях,

    • все компоненты, иконки и слои правильно названы и организованы,

    • все компоненты имеют корректные связи и настройки.

  2. Стили:

    • шрифты, цвета, спейсинги и тени имеют корректно созданные стили и задокументированы,

    • стили шрифтов, цветов и теней применены последовательно и соответствуют стандартам системы.

  3. Анатомия компонента:

    • для каждого компонента описана его анатомия, включая ключевые паддинги, внутренние элементы и размеры,

    • все размеры и отступы соответствуют стандартам дизайн‑системы.

  4. Состояния компонента:

    • каждый компонент имеет все необходимые состояния,

    • все состояния функционируют корректно и отображаются правильно,

    • настроены прототипы основных состояний.

  5. AutoLayout и адаптивность:

    • все компоненты используют autolayout для обеспечения гибкости и адаптивности,

    • компоненты корректно масштабируются и адаптируются к разным размерам экранов.

  6. Гайдлайны:

    • для каждого компонента написана подробная документация с описанием его назначения, состояний, параметров и примеров использования,

    • сценарии использования компонентов описаны понятно и доступно для всей команды.

  7. Тестирование и валидация:

    • корректное отображение и функциональность всех компонентов,

    • все компоненты работают как ожидается в различных сценариях использования.

  8. Управление версиями:

    • все изменения и обновления в дизайн‑системе задокументированы,

    • все версии компонентов синхронизированы и соответствуют текущим требованиям проекта.

Завершая этап разработки и проверки, важно помнить, что хорошая документация и сценарии использования компонентов играют ключевую роль в обеспечении их правильного применения и интеграции. Это не только облегчает работу дизайнерам и другим причастным командам, но и способствует созданию качественного и единого пользовательского опыта.

Страница компонента “select” до и после обновления
Страница компонента “select” до и после обновления

Осознания и выводы

Приступая к обновлению нашей дизайн‑системы, я думала, что это довольно быстрый и простой процесс — всего лишь компонентики перенести на новый функционал Figma. Но глубокое изучение опыта других компаний, популярных и не очень дизайн‑систем и постоянное общение со стейкхолдерами об их удобстве работы с библиотекой компонентов помогло мне провести такую детальную работу, которая привнесла в нашу компанию большую пользу. В результате мы получили:

  • увеличение скорости разработки и проектирования макетов в 2–3 раза,

  • налаженную коммуникацию как внутри отдела дизайна, так и с другими отделами,

  • сокращение количества запросов по работе и применению компонентов со стороны разработки и тестирования,

  • быструю диагностику недоработок и ошибок,

  • улучшение пользовательского опыта за счет проработки состояний, размеров, подсказок и уведомлений,

  • возможность масштабирования, разработки новых компонентов и внедрения новой функциональности в систему,

  • сокращение времени онбординга новых сотрудников,

  • более свежий, обновленный и приятный для глаз пользователя интерфейс.

Обновление и поддержание дизайн‑системы — это сложный, но необходимый и непрерывный процесс. Это открытость к новым идеям и готовность адаптироваться к изменениям в технологиях и предпочтениях пользователей. Стремление к идеальной ДС — путь с постоянными препятствиями длиною в целую жизнь)))

Переработка нашей UI‑библиотеки стала лишь первым шагом на пути к совершенствованию дизайн‑системы. Мы уже видим значительные улучшения в эффективности и качестве работы, но это только начало. Впереди нас ждет большой план по доработкам и внедрению новых функций, которые сделают нашу библиотеку ещё более мощной и гибкой:

  1. Внедрение дизайн‑токенов.

  2. Улучшение документации: добавление обширных примеров использования и best practices.

  3. Добавление визуальной навигации по библиотеке.

  4. Создание видео‑ и текстовых туториалов для обучения дизайнеров и разработчиков.

  5. Анализ и оптимизация компонентов для улучшения производительности и уменьшения времени загрузки.

  6. Разработка системы сбора обратной связи от дизайнеров и разработчиков.

  7. Создание внутреннего сообщества для обмена знаниями и лучшими практиками.

  8. Введение четкой системы управления версиями для отслеживания изменений и обновлений.

И этот список может продолжаться еще до бесконечности.

Надеюсь, в этой статье вы нашли для себя пользу или просто с удовольствием провели время за ее чтением. Делитесь, пожалуйста, своим опытом обновления или разработки ДС в комментариях. Мне будет очень интересно почитать, ведь каждый опыт по‑своему уникален.

Комментарии (2)


  1. udinhtml
    24.05.2024 09:49
    +1

    Анатомия компонента

    Тут хранится информация о ключевых паддингах, размерах и обозначениях внутренних элементов. Благодаря этому любой разработчик и дизайнер будут точно знать, какие значения должны быть у каждого элемента, что обеспечивает консистентность и упрощает тестирование.

    Вижу, что вы очень старательна, Виктория, но не могу понять, зачем люди продолжают таким заниматься в современных инструментах дизайна и проектирования.

    Панель inspect дает возможность разработчикам досконально узнать о свойствах чего угодно тыкнув в него курсором, в гораздо более удобной и информативной подаче. Кроме этого, эти данные будут всегда правдивыми, а нарисованные ручками размеры, паддинги и все остальное, могут устаревать после внесенных изменений, могут быть ошибки по невнимательности.

    Такое было бы актуально лет 10 назад, когда макеты собирались в фотошопе. Да даже тогда появился zeplin, который мог выдавать свойства макетов, как сейчас фигма.


    1. severalnight Автор
      24.05.2024 09:49
      +1

      Благодарю за верно подмеченный момент. Действительно, вы правы, и я с вами согласна.

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

      Наша первостепенная цель - как раз внедрение DevMode. Для компаний, которые его используют, конечно, разработка блоков с анатомией будет лишней тратой ресурсов))