Как повышать качество разработки. Часть 2. Использование дизайн-системы и автоматизация глобальных изменений UX/UI

Эволюция стандартов пользовательского интерфейса ставит новые вызовы перед дизайнерами приложений. Казалось бы, выбрав единый стиль и цветовую палитру, несложно привести ИТ-продукт к однородному и последовательному дизайну: нужно покрасить все элементы в нужные цвета, задать параметры скругления углов кнопок, проследить за консистентностью шрифтов и других элементов.

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

Например, в нашем приложении для продажи авиабилетов содержится 714 элементов и их состояний, 96 стилей и более 80 компонентов. Как управлять этим набором, не упустив ни единой детали и сохранив консистентность?

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

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

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

Чем больше в проекте неясности и ручного труда, тем больше костылей, случайных решений, принятых в спешке, отложенных на потом дел, которые называют “долгом”. Эти отложенные дела накапливаются и затрудняют развитие проекта. С течением времени дизайн-долг порождает все больше проблем и несоответствий во внешнем виде продукта.

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

Самая простая и распространенная практика при дизайне интерфейсов — это просто копировать и вставлять повторяющийся элемент на новые экраны.

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

Логическое развитие предыдущего подхода — выделить повторяющийся элемент в отдельный класс, и присвоить ему название и характеристики, изменение которых повлияет на все случаи (так называемые инстансы) применения этого элемента в интерфейсе. Например, если у нас есть кнопка “Далее”, которая повторяется на нескольких экранах, мы можем создать для нее компонент “кнопка Далее”. Когда нам понадобится поменять цвет кнопки, одно изменение в компоненте поменяет цвет всех кнопок “Далее”, которые увидит пользователь.

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

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

Поэтому в автоматизированном подходе мы не прописываем цвет ни у конкретных кнопок, ни в библиотеке компонентов. Вместо этого мы прописываем своеобразную ссылку — дизайн-токен — который сообщает, что цвет этой кнопки записан в главной палитре как основной.

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

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

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

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

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

Выгружать библиотеку токенов из Figma можно с помощью плагина в форматах json или .js. Можно написать собственный плагин, который будет связывать файл дизайн-системы в Figma и все его обновления со Storybook. О применении этих инструментов мы расскажем в следующей статье.