Привет! Меня зовут Денис, я продуктовый дизайнер в 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» идеально передаёт ощущения дизайнера при работе с большим легаси.
Лёгкого вам дизайна!
