Казалось бы, дизайн‑система — это инструмент, который помогает ускорить процесс разработки продуктов, облегчает масштабирование и обновление, обеспечивает единообразие дизайна и пользовательского опыта на всех платформах. Однако мы убедились на собственном опыте, что это не панацея, и если все связанные с дизайн‑системой процессы не будут налажены, то для компании она станет ахиллесовой пятой.
Привет, Хабр! Меня зовут Виктория Марухняк, я дизайнер интерфейса продукта 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 дней, но на выходе мы получили полный, соответствующий нашей системе, набор иконок, который больше не включает капризулю при изменении цветов в компонентах. И если у вас возникает вопрос, а как же обезопасить себя в аналогичных случаях, то очень рекомендую видосик Виктора Теплова про пуленепробиваемые иконки.
Для страницы компонента был разработан четкий шаблон с первоначальной документацией и сценариями использования.
Каждая страница библиотеки стала содержать в себе несколько смысловых блоков:
Название и описание компонента.
Анатомия компонента.
Параметры компонента.
Из таких сухих списков обычно не складывается полное представление, поэтому погнали смотреть на примере селекта.
Название и описание компонента
Этот блок позволил создать общий язык для всех членов команды и упростить коммуникацию с разработчиками, снижая риск недоразумений и ошибок.
Анатомия компонента
Тут хранится информация о ключевых паддингах, размерах и обозначениях внутренних элементов. Благодаря этому любой разработчик и дизайнер будут точно знать, какие значения должны быть у каждого элемента, что обеспечивает консистентность и упрощает тестирование.
Параметры компонента
Это основной блок с описанием применения компонента, его состояний, размеров и другой специфичной информацией. Он выступает ключевым элементом в создании эффективной, согласованной и высококачественной дизайн‑системы.
Важное примечание: постоянное изучение информации о ДС, в частности, о документации, показало мне, что вариаций ее составления великое множество и для первого этапа работы у нас был взят необходимый, на мой взгляд, минимум, который в короткие сроки помог масштабировать работу с ДС.
Подводя итоги о гайдлайнах для компонентов
Не буду говорить, что составление гайдлайнов было простым. Для этой работы потребовалось:
тщательно изучить текущие компоненты дизайн‑системы не только с визуальной, но и технической стороны,
сравнить текущие компоненты с лучшими практиками индустрии и нашими представлениями об обновленном интерфейсе платформы,
описать компоненты так, чтобы команды разных отделов одинаково понимали смысл написанного,
постоянно общаться с разработкой для согласования и уточнения тех или иных аспектов,
править документацию после дизайн‑ревью компонентов, реализованных на фронте.
Внедрение такой структуры помогло сократить количество обращений и вопросов разработчиков к дизайнерам, что сделало работу более эффективной, а тестировщики смогли улучшить качество продукта, быстрее диагностируя недоработки и ошибки.
А что с самими компонентами?
Качественная разработка компонентов в ДС требует хорошего понимания функциональности Figma и внимания к деталям. Я поставила для себя ключевую задачу по переработке старых компонентов таким образом, чтобы учесть все их возможные варианты, состояния и нюансы. В будущем это сэкономит время проектирования интерфейсов на компонентах со всеми «обвесами». При этом важно сохранить логику настроек и удобство работы с ними.
Вернемся к селекту и сравним реализацию компонента из старой и новой библиотеки.
Старая библиотека Shoelace
На странице компонента раздел Properties содержит только выбор состояния и не самое корректное отображение этих состояний. Нет возможности изменять отображение лейбла, подсказки, иконок. Не для всех состояний разработано отображение заполненного контента и не учтено множественное заполнение селекта.
Конечно, отображение внутренних элементов можно менять с помощью слоев, но, во‑первых, наши компоненты содержали в себе их великое множество, а во‑вторых, при проектировании целых экранов вечное ковыряние в слоях увеличивало время работы дизайнера примерно в 2–3 раза.
При попытке изменить состояние все настроенные в селекте данные и отображения слетали, что заставляло наполнять компонент заново и увеличивать время проектирования. Получается муторно и грустно:
Новая библиотека Shoelace
Страница компонента стала содержать в себе несколько component set: label, help message и select. Каждый сет имеет характерные для него настройки:
label: выбор размера, отображения подсказки и иконки,
help message: выбор типа сообщения и отображения иконки,
select: выбор размера, состояния, отображения и вида иконки.
Select‑combobox имеет комплексные настройки по каждому сету и свои собственные. Работа с этим компонентом дает нам большую вариативность при проектировании интерфейса и не требует постоянного перехода в панель слоев или библиотеку, что увеличивает скорость выхода новой функциональности. Теперь можно выбирать отображение контента внутри, состояния, типы подсказок и ничего не будет слетать. Сплошное удовольствие и медитация)
Разработка таких настроек стала одним из самых трудозатратных и интересных этапов. Нужно было смотреть не только широким взглядом на всю систему и ее светлое будущее, но и детально всматриваться в мелочи, которые являются фундаментом любого интерфейса. Это потребовало много внимания, концентрации и проверки всех деталей и связей по несколько раз. Я составила свой чек‑лист проверки библиотеки перед публикацией, который помог мне обратить внимание на упущенные моменты:
Общие проверки:
все необходимые компоненты добавлены в библиотеку и находятся в соответствующих категориях,
все компоненты, иконки и слои правильно названы и организованы,
все компоненты имеют корректные связи и настройки.
Стили:
шрифты, цвета, спейсинги и тени имеют корректно созданные стили и задокументированы,
стили шрифтов, цветов и теней применены последовательно и соответствуют стандартам системы.
Анатомия компонента:
для каждого компонента описана его анатомия, включая ключевые паддинги, внутренние элементы и размеры,
все размеры и отступы соответствуют стандартам дизайн‑системы.
Состояния компонента:
каждый компонент имеет все необходимые состояния,
все состояния функционируют корректно и отображаются правильно,
настроены прототипы основных состояний.
AutoLayout и адаптивность:
все компоненты используют autolayout для обеспечения гибкости и адаптивности,
компоненты корректно масштабируются и адаптируются к разным размерам экранов.
Гайдлайны:
для каждого компонента написана подробная документация с описанием его назначения, состояний, параметров и примеров использования,
сценарии использования компонентов описаны понятно и доступно для всей команды.
Тестирование и валидация:
корректное отображение и функциональность всех компонентов,
все компоненты работают как ожидается в различных сценариях использования.
Управление версиями:
все изменения и обновления в дизайн‑системе задокументированы,
все версии компонентов синхронизированы и соответствуют текущим требованиям проекта.
Завершая этап разработки и проверки, важно помнить, что хорошая документация и сценарии использования компонентов играют ключевую роль в обеспечении их правильного применения и интеграции. Это не только облегчает работу дизайнерам и другим причастным командам, но и способствует созданию качественного и единого пользовательского опыта.
Осознания и выводы
Приступая к обновлению нашей дизайн‑системы, я думала, что это довольно быстрый и простой процесс — всего лишь компонентики перенести на новый функционал Figma. Но глубокое изучение опыта других компаний, популярных и не очень дизайн‑систем и постоянное общение со стейкхолдерами об их удобстве работы с библиотекой компонентов помогло мне провести такую детальную работу, которая привнесла в нашу компанию большую пользу. В результате мы получили:
увеличение скорости разработки и проектирования макетов в 2–3 раза,
налаженную коммуникацию как внутри отдела дизайна, так и с другими отделами,
сокращение количества запросов по работе и применению компонентов со стороны разработки и тестирования,
быструю диагностику недоработок и ошибок,
улучшение пользовательского опыта за счет проработки состояний, размеров, подсказок и уведомлений,
возможность масштабирования, разработки новых компонентов и внедрения новой функциональности в систему,
сокращение времени онбординга новых сотрудников,
более свежий, обновленный и приятный для глаз пользователя интерфейс.
Обновление и поддержание дизайн‑системы — это сложный, но необходимый и непрерывный процесс. Это открытость к новым идеям и готовность адаптироваться к изменениям в технологиях и предпочтениях пользователей. Стремление к идеальной ДС — путь с постоянными препятствиями длиною в целую жизнь)))
Переработка нашей UI‑библиотеки стала лишь первым шагом на пути к совершенствованию дизайн‑системы. Мы уже видим значительные улучшения в эффективности и качестве работы, но это только начало. Впереди нас ждет большой план по доработкам и внедрению новых функций, которые сделают нашу библиотеку ещё более мощной и гибкой:
Внедрение дизайн‑токенов.
Улучшение документации: добавление обширных примеров использования и best practices.
Добавление визуальной навигации по библиотеке.
Создание видео‑ и текстовых туториалов для обучения дизайнеров и разработчиков.
Анализ и оптимизация компонентов для улучшения производительности и уменьшения времени загрузки.
Разработка системы сбора обратной связи от дизайнеров и разработчиков.
Создание внутреннего сообщества для обмена знаниями и лучшими практиками.
Введение четкой системы управления версиями для отслеживания изменений и обновлений.
И этот список может продолжаться еще до бесконечности.
Надеюсь, в этой статье вы нашли для себя пользу или просто с удовольствием провели время за ее чтением. Делитесь, пожалуйста, своим опытом обновления или разработки ДС в комментариях. Мне будет очень интересно почитать, ведь каждый опыт по‑своему уникален.
