Ребрендинг T2: как мы полностью переработали digital-пространство компании

В феврале 2024 года стартовал секретный проект по ребрендингу Tele2: шведская франшиза заканчивалась, и мобильный оператор не планировал её продлевать. Проект по обновлению стиля коснулся и digital-платформы.

Нужно было переделать цифровое пространство Tele2 с большим количеством пользовательских сценариев под актуальные требования Т2. Это было сделано силами команды разработки T2 с помощью экспертов Лиги Цифровой Экономики.

В статье опустим детальные технические выкладки и кодовую базу: все инструменты и применяемые подходы сами по себе в настоящий момент достаточно стандартны. Мы поделимся вызовами, которые встали перед командами в рамках редизайна, и комплексным подходом к решению, который позволил в короткие сроки получить результат.

В чем сложность проекта?

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

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

1. Редизайн.

2. Актуализация пользовательских сценариев.

3. Синхронизация дизайна между однотипными компонентами в разных местах системы (и между командами разработки и дизайна).

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

4. Реализация импортозамещения и редизайна параллельно.

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

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

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

●      Единая дизайн-система всех компонентов T2;

●      UI Kit;

●      Пошаговое внедрение и посценарная замена компонентов;

●      Синхронизация плана по импортозамещению и редизайну.

Рассмотрим каждый пункт детальнее.

Единая дизайн-система всех компонентов T2

В нулевой слой — Foundation UI — заложили токены для цветов, текстовых стилей, размерной сетки. Следующим слоем — T2D2 UI — сформировали токены для проектирования компонентов, что позволяет контролировать каждый из них отдельно. Большой плюс такого решения в том, что изменения в том или ином компоненте влияют только на тот компонент, к которому они применяются. В параллельном слое — T2D2 Styles — сформировали набор токенов для применения продуктовыми дизайнерами в рабочих задачах. Кроме того, эта библиотека используется разработкой, что позволило разработчикам и дизайнерам понимать друг друга.

Block library — библиотека паттернов, контролируемая дизайнерами. Она упрощает работу с ui-kit’ом. В ней зафиксированы паттерны, которые формируют продуктовые дизайнеры. Block library также снижает нагрузку на команду дизайн-системы — не приходится создавать множество подобных элементов. По сути, это витрина паттернов.

Была выбрана Figma и ее функционал. За эту часть отвечала команда дизайнеров. На выходе команда разработки получала макеты, в которых были сущности «компонент», используемые дизайнерами при составлении макета. Каждый компонент имел набор свойств, конфигурируя которые, можно получать разные варианты одного и того же компонента.

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

UI Kit

За время работы над ребрендингом было спроектировано около сотни компонентов.

При проектировании компонентов столкнулись с проблемой разнообразия контента внутри таких компонентов:

—        модальные окна;

—        карточки тарифов;

—        баннеры;

—        лист-айтемы;

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

Технологический стек этого решения был выбран следующий:

●      React;

●      TypeScript;

●      StoryBook — в роли библиотеки, собирающей web-интерфейс, в котором можно посмотреть коллекцию компонентов и сделать для них разные состояния;

●      Jest — для тестов;

●      Rollup — для сборки проекта;

●      Sass — для стилизации.

UI Kit собирается в пакет и устанавливается в основной проект как зависимость.

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

В дополнение команда дизайнеров сделала пакет переменных (дизайн-токенов), которые тянутся в UI Kit, что позволяет, изменяя значения переменных в одном месте (например, размер или цвет кнопки), корректировать визуальное представление как на макетах, так и в коде.

Пошаговое внедрение и посценарная замена компонентов

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

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

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

Синхронизация плана по импортозамещению и редизайну

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

1. Завязаться на старую систему и сделать на back-end небольшие доработки для меняющегося сценария;

2. Завязаться на новую систему и в случае, если нужная часть уже реализована на импортозамещенной платформе, сделать на back-end небольшие доработки для меняющегося сценария;

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

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

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

Прогнозируемые проблемы и пути их обхода

1. Синхронизация изменений в кодовой базе и сетевых настройках

Все изменения должны были произойти в ночь с 3 на 4 сентября. Помимо «обычной» части релиза, команду внедрения ждал вызов в виде необходимости запуска сайта на новом домене вместе со всеми интеграциями (биллинг, корпоративная шина данных, хранилище контента, интернет-магазин, CRM и многие другие системы). Для этого инженеры заранее развернули изменения на так называемом «втором плече», в нужный момент произведя все необходимые переключения на сетевом уровне. Для обеспечения бесшовности перехода на новый домен для пользователей были настроены редиректы со старого сайта.

2. Синхронизация изменений на сайте и в мобильном приложении

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

3. Большой объем задач, железный дедлайн и ответственность за результат

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

Выводы

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