Всем привет! 

Меня зовут Курилкина Арина, я почти год являюсь фронтенд-разработчиком интеграционных и инфраструктурных сервисов склада. Также я 2,5 года разрабатывала мессенджер для сайтов Покупателя (Buyer Experience или же, как мы у себя говорим, — BX) и Продавца (Seller Experience — SX). Таким образом, я успела поработать с продуктами трёх крупных структур Ozon: BX, SX и Warehouse (Складские сервисы).

Каждая структура уникальна, имеет свои потребности, свои проблемы и свои решения. И каждая является неотъемлемой частью функционирования компании Ozon. Своеобразные три кита, на которых стоит маркетплейс. Поработав с каждым из них, я посмотрела на клиентскую разработку и на работу с дизайн-системами и UI-kit’ами, в частности, с разных сторон. И теперь я хочу поделиться своим опытом.

Моя статья может быть полезна всем тем, кто хочет разобраться в принципах взаимодействия с дизайн-системами и UI-kit и научиться эффективно использовать их в своих проектах.

Дизайн-система и UI-kit

Дизайн-система — это своеобразный фундамент IT-продукта. Она служит основой для создания единообразного, удобного и эффективного пользовательского интерфейса и сильно упрощает жизнь дизайнерам, разработчикам, тестировщикам и всем, кто задействован на пути «от идеи до реализации».

Хорошо проработанная система решает сразу несколько проблем:

• все детали интерфейса консистентны, то есть гармонируют друг с другом. Это помогает создать единый и узнаваемый стиль бренда;

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

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

Кстати, подробнее о том, как создаются дизайн-системы в Ozon рассказал мой коллега Виктор Теплов в статье «Автостопом по дизайн-системе. Путеводитель с оглавлением».

В дизайн-системе можно выделить несколько основных разделов:

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

• визуальный язык — цвета и шрифты (они же — дизайн-токены), основные принципы формирования элементов (размеры, отступы, скругления, паттерны поведения), иконки — в общем, всё, что может потребоваться для создания удобного и единообразного внешнего вида продукта;

• компоненты — повторяемые элементы интерфейса (кнопки, поля ввода, модальные окна, таблицы, уведомления и прочее);

• паттерны — готовые сценарии использования тех или иных компонентов и их объединений (например, логика построения экранов авторизации или принципы организации навигации по сервису и фильтрации контента);

• инструменты — средства для работы с дизайн-системой — от документации до библиотеки реализованных компонентов или же UI-kit.

  

Подробнее об UI-kit

UI-kit — набор готовых элементов, основанных на правилах гайдлайна и визуального языка, которые помогают создавать более согласованные пользовательские интерфейсы. Он представляет собой удобную библиотеку, из которой разработчик может взять, например, уже реализованную по правилам дизайн-системы кнопку, а не создавать её с нуля самому. UI-kit не только ускоряет разработку, но и значительно облегчает поддержку готового функционала. Представьте ситуацию: компания решила сменить свой фирменный цвет с тёмно-синего на светло-голубой. Если библиотека компонентов отсутствует, то сотрудникам необходимо вручную обновить каждый элемент, который реализован в «устаревшем» оттенке. При наличии UI-kit достаточно обновить значение дизайн-токена, и все элементы, использующие его, автоматически перекрасятся в новый цвет.

На первый взгляд может показаться, что все продукты Ozon будут иметь одинаковую основу: общие фундаментальные требования, общее флоу разработки и, соответственно, общая дизайн-система. Но как бы не так. BX имеет свою дизайн-систему — Buyers Experience Design System, SX же использует Ozon Internal Design System или кратко — OZI. OZI — дизайн-система также для всех внутренних сервисов Ozon, поэтому складские админ-панели тоже используют её, но добавили свою «надстройку» над OZI с учётом особенностей необходимого разнообразного функционала. 

Почему в одной компании существует несколько дизайн-систем

Дизайн-система унифицирует, задаёт единый стиль и стандарты для всего бренда, упрощает масштабирование продуктов и их поддержку. Таким образом, дизайн-система — это не просто гармонично оформленные элементы интерфейса. Она помогает решать различные проблемы использования продуктов. Разные продукты -> разный функционал -> разная целевая аудитория -> разные потребности. Из-за этого они и могут требовать разные дизайн-системы.

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

Основные причины создания локальных дизайн-систем.

Скорость
Если каждую доработку, которую требует тот или иной продукт, вносить в основную дизайн-систему компании, время от идеи до реализации может сильно увеличиться. Локальные системы позволяют быстрее тестировать и внедрять изменения.

Выход за рамки
В главной дизайн-системе находятся самые популярные элементы, которые используются в большинстве команд. Если в систему вносить каждый «особый» набор компонентов из каждого продукта — она станет слишком громоздкой и тяжело поддерживаемой за счёт своих масштабов. А если все проекты просить подстроиться под определенный список элементов, то это может сильно ограничить их функциональность. Локальные системы позволяют закрыть частные потребности проектов.

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

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

Подобное разделение дизайн-систем используют многие крупные компании:

• Google. Компания для своих продуктов использует дизайн-систему Material Design, однако разные продукты добавляют свои специфические компоненты.

• Microsoft. В качестве основы применяется дизайн-система Fluent Design, но в отдельных продуктах аналогично есть свои локальные системы.

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

BX

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

SX

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

Warehouse

Складские сервисы. Для поддержания работоспособности складов на всех этапах существуют десятки админ-панелей, каждая из которых решает свою задачу: от процессов логистики до выдачи формы сотрудникам. Большинство сервисов работает с большим (я бы даже сказала — огромным) количеством информации, из-за чего им необходимо отображать таблицы с десятками столбцов и сотнями строк. И в этот момент красота интерфейса немного отступает на второй план, потому что на кону стоят функциональность и скорость работы с данными. Всё для того, чтобы сотрудники склада могли быстро и комфортно выполнять свою работу, а ваши посылки приходили к вам вовремя.

Потребности продуктов

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

Основные запросы сайтов Покупателя и Продавца:

• консистентность интерфейса, ведь эти сервисы — лицо компании, а гармоничный фирменный дизайн создаёт правильный и запоминающийся образ;

• привлечение внимания к элементам, которые побуждают посетителя на целевое действие;

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

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

Ключевые требования складских сервисов:

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

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

Вывод

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

Разработка и UI-kit

Итак, что мы имеем? Несколько дизайн-систем и, соответственно, несколько UI-kit’ов. И тут разработчик сталкивается со следующим: он один, а «китов» вокруг него много. И все они разные.

Ключевая особенность UI-kit’ов в том, что они отличаются не только дизайн-решениями, палитрами, типографиями и определённым набором элементов. Разные UI-kit’ы нацелены на абсолютно разные потребности продуктов.

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

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

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

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

Мой опыт

Сайты Покупателя и Продавца

Моё знакомство с UI-kit’ами в Озоне началось в 2021 году, когда я пришла в команду «Платформа чатов». Перед нами стояла задача — обновить текущий (а с точки зрения разработки — создать новый) мессенджер. Сначала для сайта Покупателя (BX), а следом для сайта Продавца (SX). И все было бы донельзя прекрасно, если бы не одно НО: у сайтов совершенно разные дизайн-системы. Создавать два отдельных мессенджера, согласитесь, было бы слишком затратно и нерационально — помимо удвоенного времени на разработку мы бы получили ещё трудности с поддержкой и интеграцией нового функционала в будущем. Наша цель — создавать доступные, универсальные и масштабируемые решения, поэтому, пока бэкенд создавал единую архитектуру для чатов на своей стороне, фронтенд приготовился сражаться с двумя UI-kit’ами. А если быть точнее, то даже с тремя, потому что в BX есть поддержка моб-веба, который должен быть похож на апп-версию. Приложение, хоть и сделано на базе BX Design System, но все же имеет свою «надстройку» над ним с учётом особенностей мобильной платформы. Это также создавало дополнительные трудности.

Для сравнения внешний вид десктопной версии чата BX и чата SX:

Разработка продуктов для BX и SX — это акцент, в первую очередь, на дизайн элементов. Все разделы сайта Покупателя и сайта Продавца должны быть максимально консистентны друг с другом. Важно абсолютно все: от типографии и палитры до величины отступов и скруглений. Мессенджер же представляет собой сложный (по количеству функционала на квадратный метр пиксель) продукт: в нем огромное количество компонентов и подружить два абсолютно непохожих UI-kit поначалу казалось невыполнимой задачей. 

Но дело мастера боится и, побрейнштормив, наша команда пришла к выводу, что для чата будет создаваться «каркас», который впоследствии можно будет кастомизировать в соответствии с требованиями той или иной дизайн-системы. Способов видоизменения у нас получилось два: с помощью СSS-переменных и использования «кастомных» блоков.

СSS-переменные

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

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

Аналогичную логику мы решили реализовать и в своём мессенджере.

Нам пришлось достаточно долго изучать все элементы мессенджера, чтобы сформировать достаточный список переменных. Больше всего сложностей вызвала типография, так как дизайн-системы BX и SX имеют кардинально разное представление о ней: от семейства шрифтов до размеров. Например: на сайте Покупателя для небольших кнопок используется ‘GTEestiPro’, размер 14px, высота строки 20px и жирность 500, а на сайте Продавца — ‘Inter’, размер 15px, высотой строки 24px и 600 жирностью в другой. Чтобы смочь использовать переменные для типографии, пришлось достаточно долго изучать все текстовые элементы мессенджера, чтобы один и тот же стиль одной платформы точно соответствовал одному конкретному стилю другой.

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

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

Кастомные блоки

К сожалению или счастью, не все проблемы стилизации можно решить с помощью CSS-переменных. Поэтому для себя мы придумали и интегрировали «кастомные блоки».

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

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

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

Работа с двумя разными UI-kit’ами в двух разных структурах компании — незабываемый и очень полезный опыт. Он научил меня не только техническим вещам, но и креативным подходам, как можно одновременно жить и выживать в двух дизайн-системах. Проработав в команде «Платформы чатов» 2,5 года и уже подружившись с UI-kit’ами BX и SX, весной 2024 года я приняла решение перейти в команду складских сервисов, чтобы получить новый опыт и поделиться имеющимся в ещё одной крупной части компании Ozon.

Складские сервисы

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

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

Для всей необходимой нам магии у нас есть своя «надстройка» над OZI, которая предоставляет не только переиспользуемые дизайн-решения или кастомные комбинации, которые используются в большинстве админок, но и помогает решать некоторые вопросы компонентов, например, как большие объёмы или разные типы данных. 

Почему «надстройка», а не самостоятельный UI-kit? OZI — наша основная дизайн-система, которая используется для внутренних сервисов. Админ-панели — не исключение. Большая часть компонентов действительно используется напрямую из UI-kit OZI. Но зачастую сервисы имеют схожие функциональные части и для избежания дублирования кода, а также его упрощённой поддержки существует «надстройка». Таким образом, наш UI-kit это:

• реэкспорт уже существующих компонентов из UI-kit OZI;

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

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

• кастомные компоненты, которых нет в OZI, но встречающиеся во многих наших сервисах: например, карточки админ-панелей для быстрого перехода между ними;

• различные решения для комфортной работы пользователей (поговорим о них чуть позже).

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

Решения для комфортной работы с админ-панелями

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

Помощь для быстродействия

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

Виртуальный скролл — помощник в оптимизации отрисовки списков, благодаря которому в DOM-дереве находятся только элементы, видимые на экране. В процессе прокрутки списка новые элементы добавляются, а старые (с противоположного конца), соответственно, удаляются.

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

Взгляните на две гифки: на первой виртуализация отсутствует и все элементы списка отрисовываются сразу (для наглядности была создана утрированно длинная база из 3000 элементов). Можно заметить фризы и медленный отклик при взаимодействии. На второй тот же самый список из такого же количества элементов, но уже с использованием виртуализации. Согласитесь, разница поражает.

Мы уже планировали добавлять своё решение в наш UI-kit, но ребята из OZI нас опередили и добавили виртуализацию в свои компоненты списков, за что им большое спасибо.

Помощь для визуала

Что касательно визуального комфорта, то отличный пример — уведомления. В OZI уведомления реализованы в минималистичном формате, так как рассчитаны для пользователей, которые работают непосредственно перед монитором. На складах же есть ситуации, когда экран с развёрнутой системой на нем — не прямая точка взаимодействия с пользователем, а, скорее, сопутствующий фактор. Это касается сервисов, которые, к примеру, работают с поставками: перед сотрудником палета с большой партией товара, с помощью ТСД (терминал сбора данных) необходимо быстро отсканировать каждый предмет. Будет ли вам удобно в таком случае всматриваться в монитор, чтобы увидеть — успешно ли выполнился запрос? Конечно, нет. Поэтому уведомления были модифицированы в более яркие и заметные, которые можно легко считать, не отвлекаясь от процесса.

Заключение

Дизайн-системы и UI-kit позволяют быстро и эффективно создавать пользовательские интерфейсы, соответствующие дизайну компании и отражающие её философию.

Работа с UI-kit, в частности, имеет ряд преимуществ:

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

• переиспользуемость, потому что UI-kit позволяет разработчикам повторно использовать компоненты интерфейса, затрагивая меньше сил на реализацию нового функционала;

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

Однако работа с UI-kit также имеет некоторые недостатки:

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

• сложность интеграции. В некоторых случаях могут возникать сложности с интеграцией UI-kit в некоторые проекты. И тут приходится искать кастомные решения, чтобы все стороны (и дизайн, и разработка) были довольны;

• основной UI-kit компании, как и основная дизайн-система, предоставляет общие решения, использующиеся в большинстве команд. А отдельный продукт может требовать персонализированных решений, которые не сможет предоставить общая библиотека компонентов. Возникает потребность создавать локальные UI-kit в рамках команд конкретного продукта и тратить дополнительные ресурсы.

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