Expero Design System

Компания Expero - сервис бронирования аптечных товаров в аптеках с более чем 40 тысячами подключенных аптек по всей России. Продукт развивается одновременно на Web, iOS и Android. На момент моего подключения к команде сервис разрабатывался несколько лет, в нем сформировались 3 независимые дизайн-системы и большое количество кастомных решений, что усложняло поддержку интерфейсов.

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

Компонентный хаос - 30-40% всех компонентов находились в локальных файлах. Для одних и тех же сущностей создавались разные родительские компоненты.

Переусложненность - Web был разбит на 5 брейкпоинтов, и каждый компонент и макет создавался под каждый брейкпоинт отдельно. Это растягивало процесс подготовки макетов и компонентов для разработки по времени.

Влияние на продукт - сильно растягивался процесс не только подготовки макетов, но и их поддержка.

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

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

А именно:

- Единый источник правды для всех - единая система токенов и атомов;

- ДС Web - оставляем только 2 брейкпоинта - desktop и mobile. Максимальный уклон в адаптируемость компонентов и макетов;

- ДС iOS и Android - теперь считаются как одно целое, единая кроссплатформенная ДС App;

- Page Template Component. Создается, например, Profile Page Template, и из него собираются все состояния и варианты страницы. Тем самым минимизируем возможные ошибки при сборке макетов.

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

Шаг 1. Создание единой системы токенов для всех платформ. Сюда вошли:

- Цвета;

- Шрифты;

- Отступы и скругления.

По цветам было решено пойти по структуре: Цвет -> Примитив -> Семантика, чтобы иметь более гибкую настройку.

Шаг 2. Вынос повторяющихся атомов. Мы провели ревью повторяющихся компонентов и приняли решение взять за основу Android, так как она была самой оптимизированной. Как только я вынес все атомы из Android дизайн-системы, встал вопрос - как быстро заменить эти же атомы в дизайн-системе Web?

Ответом стала функция Swap instances. Проведя пару экспериментов, я понял, что она позволяет производить замену компонентов буквально партиями. Так мы разом сократили очень большую часть ручной работы.

Таким образом, я привел к единству все цвета, шрифты, отступы и основные атомы.

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

Отныне разрешения считаются как:

- 360-991px - это mobile версия;

- 992-max - это desktop версия.

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

Так мы сократили вдвое количество подготавливаемых макетов для разработки.

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

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

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

Они отметили, что такой подход существенно ускорил процесс разработки, снизил риск ошибок при верстке и упростил взаимодействие с макетами.

Подробнее узнать об этих и других кейсах можно на созвоне.