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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы изучили 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. Управление версиями:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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