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

Дизайн-система – невероятно важная и полезная штука. Не только UI Kit и палитра цветов – сейчас это целый набор артефактов, компонентов и правил для комфортного проектирования продуктов.

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

Что за продукт, что происходит и где мы находимся

Мы делаем дизайн и вот это вот всё.

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

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

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

• Открытая система Госуслуг со стороны G2C → заявки, справки, документооборот, потребности сотрудников.

• Проектирование бизнес-процессов в инициативах Контура → коммерческие продукты, работа с бизнес-требованиями, уникальные сервисы.

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

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

Почему решили рефакторить

Время пришло.

Личным кабинетом «Пятёрочки» и его тиражом на другие бизнес-единицы X5 занималась команда подрядчика, полностью отвечая за техническую часть. Для тиража выбрали наиболее быстрый и прямолинейный путь: перекрасить основные элементы на фронте без дизайна и исследований. Интерфейсы, макеты, компоненты остались от «Пятёрочки».

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

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

• куча неразобранного легаси и дизайн-долг от старого кабинета;

• значительные расхождения между разработкой и дизайном;

• отсутствие чётких правил проектирования интерфейсов для новых бизнес-единиц;

• длительный и дорогой этап дополнительной проверки готовых макетов.

Большое количество разношёрстных сервисов, собранные в одном месте, необъятные горы легаси, нестандартные решения вне общих паттернов – всё это изнутри разрушало систему и мешало работе. В этот момент появляемся мы и с головой окунаемся в проблему.

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

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

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

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

Неухоженность системы принуждает вернуться к классическому подходу «да мне быстрее на коленке это собрать-нарисовать», чем пытаться привыкнуть к неудобному инструменту. Говорю об этом без всякого осуждения: человек осознанно и/или неосознанно тянется к удобному и избегает дискомфорт.

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

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

• Уменьшился контроль со стороны дизайн амбассадора – специалиста, полностью отвечающего за работу дизайн-системы на постоянной основе.

• Продукт взаимодействует как с сотрудниками внутри компании, так и с внешними специалистами (фриланс/аутсорс/аутстафф) без чёткого разделения ролей.

• Потерялась единая точка входа в дизайн-процессы. Без грамотного онбординга и собранной в одном месте экспертизы каждый дизайнер собирает свой велосипед.

• Готовые макеты по текущим задачам устаревают за пару месяцев и требуют полной пересборки.

Что делать? Вызывайте пожарную дизайн-бригаду, выделяйте ресурсы на рефакторинг и приступайте к генеральной уборке.

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

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

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

Вот так, вот так, раз-раз и готово.

Дизайн процессам часто недостаёт структуры и организованности. Не хватает своего стайлгайда, как PEP8 у питона или SQL гайдлайнов. Нам в X5 сильно помогают дизайн-фреймворки, но порой и их недостаточно.

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

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

• Навели порядок в именовании слоёв и общей структуре → Multi-edit функции заработали шустрее и почти перестали путать названия элементов.

• Избавились от групп в пользу Auto-Layout, настроили режимы «Fixed width», «Hug to content», «Fill container» для элементов → Получили в качестве бонуса нормально тянущиеся адаптивные макеты.

• Собрали макеты по принципам html/css вёрстки → Облегчили работу для фронтов, а Figma раскрыла удивительные возможности в режиме прототипирования.

• Добавили описания и нужные пометки в Dev Mode → Ещё больше облегчили работу для фронтов и сказали себе «Спасибо» при подготовке документации к релизу.

У того же Контура есть отличные гайды, как держать свои макеты в чистоте и как вовремя остановиться.

Ветки (Branches)

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

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

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

Переменные (Variables)

Одно из самых значительных обновлений – мы перевели дизайн-систему на Variables. Без токенов нет смысла ни заводить новую систему, ни рефакторить текущую. Всё, что можно загнать в параметры (типографика, цвета, скругления, отступы, CSS) записывается в токены и становится единой точкой входа для дизайнеров.

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

Даже в текущем состоянии библиотека с токенами уже позволяет нам значительно ускорить дизайн-процессы. Figma поддерживает переключение разных режимов для одинаковых переменных: теперь гораздо проще собирать и адаптировать интерфейсы для бизнес-единиц. Личный кабинет для «Пятёрочки» в мгновение переключается в личный кабинет для офиса X5.

Документация

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

• Юзабилити документация. Правила и методики проектирования → поведение элементов, пользовательский опыт, взаимодействие, поддержка.

• Системная документация. Технические памятки для разработки и дизайна → отступы, CSS, токены, особенности вёрстки, отдельные детали по фреймворкам.

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

Что получилось

Мы строили, строили и, наконец, построили.

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

После рефакторинга мы можем собрать чёткий алгоритм действий, как и что должно собираться: эффективно, быстро, следуя правилам. Стало проще вписать в общие процессы нестандартные решения и уникальные ситуации – то, чего недоставало до обновления. Промежуточные итоги спустя несколько месяцев:

• разгрузили бэклог по текущим задачам и дизайн-долгу;

• освободили ресурсы дизайнеров для новых продуктов;

• значительно упростили прохождение дизайн-ревью;

• с чистыми компонентами и обновлёнными правилами макеты собираются быстрее;

• дизайн-система может масштабироваться и подстраиваться под новые условия.

Следующие шаги

Рефакторинг закончен. Да здравствует новый рефакторинг!

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

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

В планах – доработать стандарты и отшлифовать документацию: разбить её на юзабилити и системную части, причесать тексты и вместе с техническим писателем упростить сложные формулировки.

Практически всё готово к более глубокой синхронизации с фронтендом. Несоответствия дизайна и кода ещё не стали критическими, но требуют внимания. Унифицированные токены и JSON/TS/CSS манифесты должны с этим справиться. Возьмём на вооружение практики VK и переработаем под себя.

Подготовим отдельный комплексный онбординг для новых дизайнеров, менеджеров и заказчиков, чтобы снизить порог входа. Добавим универсальную поддержку айдентики и брендбуков для разных бизнес-единиц («Пятёрочка», «Перекрёсток», «Чижик», «Много Лосося»).

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

• отличный туториал от Евгении «Как создать хороший FAQ» сильно помог в подготовке технической документации;

• статья Георгия «33 оттенка зелёного. Как мы проектировали темизированные палитры для внутренних интерфейсов Х5» идеально передаёт ощущения дизайнера при работе с большим легаси.

Лёгкого вам дизайна!