Привет! Меня зовут Денис, я продуктовый дизайнер в X5 Tech. Последние несколько месяцев мы, вместе с коллегами приводили в порядок, рефакторили, чистили и доводили до ума дизайн-систему внутреннего бэк-офиса X5 для личного кабинета сотрудника. Расскажу, на какие подводные камни мы наткнулись, к чему готовиться и зачем вообще заниматься рефакторингом в дизайне.
Дизайн-система – невероятно важная и полезная штука. Не только UI Kit и палитра цветов – сейчас это целый набор артефактов, компонентов и правил для комфортного проектирования продуктов.
Отлаженная дизайн-система – отличный инструмент для комфортной работы. Но бывает и наоборот: что-то пошло не так, где-то не проследили. И вот ваша система, призванная навести порядок и сделать всем хорошо, сама заросла бурьяном и разваливается на части.
![](https://habrastorage.org/getpro/habr/upload_files/04a/99f/b63/04a99fb63e62dc8056165d1fbba7e6ee.png)
Что за продукт, что происходит и где мы находимся
Мы делаем дизайн и вот это вот всё.
Личный кабинет для сотрудников большой компании – всегда занимательный проект. Легаси, старые и новые сервисы, распиленный на микросервисы монолит, разнообразный пользовательский опыт. Гремучая смесь бэк-офиса и операционки, B2B и B2C.
Какое-то время назад X5 масштабировала личный кабинет «Пятёрочки» на другие бизнес-единицы. Получилось растиражировать рабочее решение на разные структуры компании (от «Перекрёстка» до офиса X5), сэкономить бюджет и ресурсы, добиться единых процессов и консистентности, обойтись без зоопарка разнообразных продуктов.
![Обновлённый личный кабинет для разных бизнес-единиц Обновлённый личный кабинет для разных бизнес-единиц](https://habrastorage.org/getpro/habr/upload_files/efe/20d/19e/efe20d19eb1fb2a1366c206423d5fab1.png)
В идеале, вся корпоративная волокита, проектирование внутренних процессов, отношения «компания – сотрудник» должны прорабатываться с помощью эффективной дизайн-системы. Ближайшие аналоги:
Открытая система Госуслуг со стороны G2C → заявки, справки, документооборот, потребности сотрудников.
Проектирование бизнес-процессов в инициативах Контура → коммерческие продукты, работа с бизнес-требованиями, уникальные сервисы.
Со стороны проектирования личный кабинет превратился в маркетплейс с кучей сервисов для разных пользователей. У офисного сотрудника свой набор (расчётные листки, заявки, отпуска), у директора магазина совершенно другой (график работы сотрудников, внутренняя статистика), но все находятся под одной крышей.
И добротная, удобная дизайн-система критически необходима для сохранения единообразия в макетах и на фронте, поддержки различного функционала, безпроблемного ревью и быстрой синхронизации.
![Структура дизайн-системы Структура дизайн-системы](https://habrastorage.org/getpro/habr/upload_files/17e/a9b/bb3/17ea9bbb33dd85102009e469a8054d8f.png)
Почему решили рефакторить
Время пришло.
Личным кабинетом «Пятёрочки» и его тиражом на другие бизнес-единицы X5 занималась команда подрядчика, полностью отвечая за техническую часть. Для тиража выбрали наиболее быстрый и прямолинейный путь: перекрасить основные элементы на фронте без дизайна и исследований. Интерфейсы, макеты, компоненты остались от «Пятёрочки».
Бизнес-задача масштабирования была успешно решена. Теперь пользователю открывался такой же личный кабинет как и у «Пятёрочки», но с логотипом, цветами и раскрашенными элементами по брендбуку бизнес-единицы, в которой он работает.
Подрядчик в скорости добавлял новые сервисы и кастомизировал функционал под разные роли. Но в повседневной работе появились:
куча неразобранного легаси и дизайн-долг от старого кабинета;
значительные расхождения между разработкой и дизайном;
отсутствие чётких правил проектирования интерфейсов для новых бизнес-единиц;
длительный и дорогой этап дополнительной проверки готовых макетов.
Большое количество разношёрстных сервисов, собранные в одном месте, необъятные горы легаси, нестандартные решения вне общих паттернов – всё это изнутри разрушало систему и мешало работе. В этот момент появляемся мы и с головой окунаемся в проблему.
В компонентах и библиотеках стремительно увеличивался беспорядок. На системный подход и единообразие в макетах недоставало времени и ресурса, бюджет выделялся строго на релизные задачи, рос и без того тяжёлый дизайн-долг.
![Неприбранный UI Kit для личного кабинета Неприбранный UI Kit для личного кабинета](https://habrastorage.org/getpro/habr/upload_files/633/2fc/98a/6332fc98ae8d0893f7fe0072234e071f.png)
Как итог, без внимания и ухода дизайн-система перестаёт работать. Компоненты устаревают, правила не обновляются, процессы распадаются и приходят в упадок. Почему у этой иконки неправильный размер? Откуда взялся этот оттенок зелёного? Куда пропал компонент с уведомлениями, вот же, только что был здесь?!
Прежде всего, это влияет на сроки. Простая задача на несколько макетов превращается в бесконечную пересборку одних и тех же элементов. Снова для каждого типового решения придумываются костыли, потому что в дизайн-системе этого нет, или есть, но мы не смогли найти.
Сильно падает продуктивность дизайнера и ценность его работы. Мало того, что на задачу приходится закладывать больше времени (а должно быть наоборот), так ещё и дизайн-система, призванная облегчить и ускорить процессы, превратилась в тыкву и малопонятное легаси (а должно быть наоборот).
Неухоженность системы принуждает вернуться к классическому подходу «да мне быстрее на коленке это собрать-нарисовать», чем пытаться привыкнуть к неудобному инструменту. Говорю об этом без всякого осуждения: человек осознанно и/или неосознанно тянется к удобному и избегает дискомфорт.
![«Быстрые» макеты для мобильного приложения в режиме Outline «Быстрые» макеты для мобильного приложения в режиме Outline](https://habrastorage.org/getpro/habr/upload_files/933/e38/4d8/933e384d879293a925aaeb0af78464b5.png)
Нужен ли дизайн-системе рефакторинг? Как понять, что текущие решения не работают? В нашем случае погружение в процессы, анализ и диагностика проблем показали следующее:
Вовлечённость подрядчика в продукт снизилась и бесхозная дизайн-система перестала работать сама по себе без постоянной поддержки.
Уменьшился контроль со стороны дизайн амбассадора – специалиста, полностью отвечающего за работу дизайн-системы на постоянной основе.
Продукт взаимодействует как с сотрудниками внутри компании, так и с внешними специалистами (фриланс/аутсорс/аутстафф) без чёткого разделения ролей.
Потерялась единая точка входа в дизайн-процессы. Без грамотного онбординга и собранной в одном месте экспертизы каждый дизайнер собирает свой велосипед.
Готовые макеты по текущим задачам устаревают за пару месяцев и требуют полной пересборки.
Что делать? Вызывайте пожарную дизайн-бригаду, выделяйте ресурсы на рефакторинг и приступайте к генеральной уборке.
![Основные причины для рефакторинг дизайн-системы Основные причины для рефакторинг дизайн-системы](https://habrastorage.org/getpro/habr/upload_files/02f/07d/23b/02f07d23b821ec9bf1f02294eb6819b4.png)
У рефакторинга дизайн-системы есть и другое хорошее обоснование для бизнеса. Личный кабинет сотрудника нужен много где, практически для каждой бизнес-единицы, структуры, департамента и отдела требуется свой сервис для организации рабочих процессов.
Чистую отрефакторенную систему без больших сложностей можно масштабировать на любой другой продукт, подключив для сотрудников единый и бесшовный опыт. С «грязной» дизайн-системой такое вряд ли возможно.
Как почистили и довели до ума дизайн-систему
Вот так, вот так, раз-раз и готово.
Дизайн процессам часто недостаёт структуры и организованности. Не хватает своего стайлгайда, как PEP8 у питона или SQL гайдлайнов. Нам в X5 сильно помогают дизайн-фреймворки, но порой и их недостаточно.
Рефакторинг дизайн-системы – тщательный и планомерный процесс, без чётких правил и стандартов не обойтись. Поэтому общий принцип такой: берём на вооружение методики из фреймворков внутри компании и замешиваем с лучшими практиками индустрии.
![Приводим в порядок слои и структуру в макетах Приводим в порядок слои и структуру в макетах](https://habrastorage.org/getpro/habr/upload_files/27f/2a3/39d/27f2a339d40ce2cbbc71789f0d4a35d9.png)
Вручную пылесосим захламлённые компоненты, архивируем устаревшие файлы, обновляем документацию, показываем изменения команде, собираем обратную связь. Да и сама Figma влюблена в чистые, организованные макеты:
Навели порядок в именовании слоёв и общей структуре → Multi-edit функции заработали шустрее и почти перестали путать названия элементов.
Избавились от групп в пользу Auto-Layout, настроили режимы «Fixed width», «Hug to content», «Fill container» для элементов → Получили в качестве бонуса нормально тянущиеся адаптивные макеты.
Собрали макеты по принципам html/css вёрстки → Облегчили работу для фронтов, а Figma раскрыла удивительные возможности в режиме прототипирования.
Добавили описания и нужные пометки в Dev Mode → Ещё больше облегчили работу для фронтов и сказали себе «Спасибо» при подготовке документации к релизу.
У того же Контура есть отличные гайды, как держать свои макеты в чистоте и как вовремя остановиться.
![Обновлённый раздел с иконками Обновлённый раздел с иконками](https://habrastorage.org/getpro/habr/upload_files/230/dac/cbc/230daccbce5674351c5d339e01ddd386.png)
![Как выглядели иконки до рефакторинга Как выглядели иконки до рефакторинга](https://habrastorage.org/getpro/habr/upload_files/313/c42/427/313c42427fbb021aa01720b7066c7a0c.png)
Ветки (Branches)
Использование веток помогло нам усмирить хаос с кучей ненужных песочниц, спасти мастер-файл от превращения в свалку, а также увидеть ответственных за пересобранные компоненты.
Ветки по-настоящему спасают фигму от захламления. У бранчей всё ещё урезанный функционал и есть свои особенности. К примеру, нельзя сливать ветку в ветку, плохо работают публичные ссылки на отдельные бранчи и не всегда обновления в мастере корректно заливаются в ветку.
Но оберегать макеты от мусора, избавиться от десятка архивных файлов, назначить дизайнера на новую задачу с помощью веток – самое то.
![Использование веток в мастер-файле с элементами Использование веток в мастер-файле с элементами](https://habrastorage.org/getpro/habr/upload_files/7f8/728/58d/7f872858d78875f9ba52e9de5415be89.png)
Переменные (Variables)
Одно из самых значительных обновлений – мы перевели дизайн-систему на Variables. Без токенов нет смысла ни заводить новую систему, ни рефакторить текущую. Всё, что можно загнать в параметры (типографика, цвета, скругления, отступы, CSS) записывается в токены и становится единой точкой входа для дизайнеров.
![](https://habrastorage.org/getpro/habr/upload_files/c46/5c7/340/c465c73409db65168dc934709d535a9b.png)
Токены помогли полностью переработать палитру с учётом различий торговых сетей и бизнес-подразделений X5. Наконец-то получилось разрешить большую проблему с вёрсткой единых макетов по разным брендбукам, когда один сервис личного кабинета нужно вписать и в гайдлайны «Перекрёстка», и в бренд «Пятёрочки», да ещё следовать правилам самой дизайн-системы.
![Личный кабинет в темах «Пятёрочки» и X5 Личный кабинет в темах «Пятёрочки» и X5](https://habrastorage.org/getpro/habr/upload_files/6c7/59c/46f/6c759c46f4f9233f5fab97a71dfd3105.gif)
Даже в текущем состоянии библиотека с токенами уже позволяет нам значительно ускорить дизайн-процессы. Figma поддерживает переключение разных режимов для одинаковых переменных: теперь гораздо проще собирать и адаптировать интерфейсы для бизнес-единиц. Личный кабинет для «Пятёрочки» в мгновение переключается в личный кабинет для офиса X5.
![Перекраска макетов с помощью токенов Перекраска макетов с помощью токенов](https://habrastorage.org/getpro/habr/upload_files/334/c68/50e/334c6850ee7220a14449947effa8eea2.png)
Документация
Начали приводить в порядок документацию и описывать, как что работает в системе. Главный принцип: тексты должны быть понятными для всех. Во-первых, избавляемся от канцелярита и корпоративного языка. Во-вторых, решили разделить все гайдлайны на две группы артефактов:
Юзабилити документация. Правила и методики проектирования → поведение элементов, пользовательский опыт, взаимодействие, поддержка.
Системная документация. Технические памятки для разработки и дизайна → отступы, CSS, токены, особенности вёрстки, отдельные детали по фреймворкам.
![Пример системной документации по работе с иллюстрациями Пример системной документации по работе с иллюстрациями](https://habrastorage.org/getpro/habr/upload_files/932/4c0/267/9324c0267c3af0a68643c0d335aa2d7b.png)
Гайдлайны, токены, ветки, чистые компоненты, пересобранные макеты, свой евангелист в дизайн-системе - базовый перечень обновлённого и отрефакторенного.
Что получилось
Мы строили, строили и, наконец, построили.
Мы проделали большую работу. Теперь у нас появилась возможность формализовать правила прохождения дизайн-ревью. До этого макеты по задачам попадали на ревью, и каждый случай рассматривался отдельно, вручную сопоставляя то, что есть в задаче и в неорганизованной дизайн-системе. Такой подход отнимал кучу времени на этапе между дизайном и разработкой.
После рефакторинга мы можем собрать чёткий алгоритм действий, как и что должно собираться: эффективно, быстро, следуя правилам. Стало проще вписать в общие процессы нестандартные решения и уникальные ситуации – то, чего недоставало до обновления. Промежуточные итоги спустя несколько месяцев:
разгрузили бэклог по текущим задачам и дизайн-долгу;
освободили ресурсы дизайнеров для новых продуктов;
значительно упростили прохождение дизайн-ревью;
с чистыми компонентами и обновлёнными правилами макеты собираются быстрее;
дизайн-система может масштабироваться и подстраиваться под новые условия.
![Набор самого важного в Figma после первой «уборки» Набор самого важного в Figma после первой «уборки»](https://habrastorage.org/getpro/habr/upload_files/095/134/7f4/0951347f46ed79adfb1a0c00cfde40bf.png)
Следующие шаги
Рефакторинг закончен. Да здравствует новый рефакторинг!
Продолжаем обновлять и дорабатывать дизайн-систему в более спокойном, фоновом режиме. Рефакторинг не влияет на рабочие задачи и проходит параллельно с основными процессами. Взаимодействие с продуктом становится более очевидным и постоянным.
Теперь мы можем подключать сторонних дизайнеров к продукту без долгого и болезненного внедрения. До этого специалисту приходилось монотонно просматривать старую систему, неактуальные гайды, сравнивать с относительно свежими макетами и разработкой и только затем погружаться в новые задачи.
![](https://habrastorage.org/getpro/habr/upload_files/456/224/79e/45622479e2194ef28800b805e397d9e3.png)
В планах – доработать стандарты и отшлифовать документацию: разбить её на юзабилити и системную части, причесать тексты и вместе с техническим писателем упростить сложные формулировки.
Практически всё готово к более глубокой синхронизации с фронтендом. Несоответствия дизайна и кода ещё не стали критическими, но требуют внимания. Унифицированные токены и JSON/TS/CSS манифесты должны с этим справиться. Возьмём на вооружение практики VK и переработаем под себя.
Подготовим отдельный комплексный онбординг для новых дизайнеров, менеджеров и заказчиков, чтобы снизить порог входа. Добавим универсальную поддержку айдентики и брендбуков для разных бизнес-единиц («Пятёрочка», «Перекрёсток», «Чижик», «Много Лосося»).
![](https://habrastorage.org/getpro/habr/upload_files/ec1/e3f/d49/ec1e3fd49078dc60ee5df5bcd94894bc.png)
X5 – огромная компания с самыми разными дизайн-процессами. В статье затронута лишь малая их часть, всё самое вкусное лежит в корпоративном блоге. Например:
отличный туториал от Евгении «Как создать хороший FAQ» сильно помог в подготовке технической документации;
статья Георгия «33 оттенка зелёного. Как мы проектировали темизированные палитры для внутренних интерфейсов Х5» идеально передаёт ощущения дизайнера при работе с большим легаси.
Лёгкого вам дизайна!