Привет, Хабр! Меня зовут Андрей Юрин, я мобильный разработчик в онлайн-кинотеатре «КИОН». Недавно у нас произошел ребрендинг, который коснулся всех платформ. Было решено все делать в мини-команде супергероев из дизайнеров и разработчиков. Я был в зоне ответственности за Android TV и хочу поделиться, с какими проблемами пришлось столкнуться и как проходит ребрендинг в большой компании.
Что такое ребрендинг и с чем его едят
Если смотреть глазами пользователя, ребрендинг — это процесс, при котором выполняется простая задача с изменением текстовок, цветов и картинок. Кажется, что это «косметика», но это не так. Это огромный процесс с переосмыслением бренда, подходов и логики взаимодействия.
Для того чтобы провести ребрендинг, нужно проделать большую работу по внедрению новой дизайн-системы во все платформы, перестройке пользовательских сценариев, интеграции новых фич и так далее.
В нашем случае было еще сложнее. «КИОН» перестал быть только онлайн-кинотеатром — мы перешли в статус единого кластера с кино, музыкой и книгами. Это значит, что внутри приложения должны уживаться разные типы контента и сценарии потребления — например, пользователь может начать с фильма, переключиться на музыку, а потом открыть книгу. Все это должно выглядеть и ощущаться как единый продукт, а не как три сервиса, случайно оказавшиеся под одной иконкой.
О том, как мы провели такой ребрендинг за четыре месяца и какие результаты получили, расскажу поэтапно.
Этап 1. Понимание спектра задач
На момент старта в сентябре 2025 года перед нами стояла цель по переходу к единой дизайн-системе. Надо было не просто поменять цвета и тексты, а привести интерфейс к унифицированному подходу, когда приложение собирается из готовых стилей и UI-компонентов. Это нужно для того, чтобы все экраны были в одном стиле.
Параллельно мы двигались к единой экосистеме. Хотя сама музыка и аудиокниги существовали в «КИОН» и раньше, именно в рамках ребрендинга они должны были стать полноценной частью сервиса, а не отдельной функцией где-то на периферии.
Если говорить о навигации и поиске — у нас не было задачи переписать все с нуля, но они все равно вошли в ребрендинг. Как только меняется структура полок, карточек и визуальных акцентов, у пользователя меняется путь внутри приложения: где он останавливается, куда переходит и что замечает первым. Из-за этого значительная часть работы заключалась в том, чтобы новые элементы максимально естественно встроились в существующие процессы и не создавали ощущения «другого приложения».
На этом этапе также решалось, как выпускать изменения, ведь если раскатывать волнами, все станет неконсистентным и начнет напоминать винегрет. Мы выбрали одновременное переключение, несмотря на то, что это сложнее для команд и тяжелее для финального выхода. Время на ребрендинг заложили с запасом: как ни старайся, все проблемы все равно не предвидеть.
Этап 2. Назначение зон ответственности
Первая проблема, с которой мы столкнулись, — чья зона ответственности? Проще говоря — кто и что должен реализовать? Очевидно, что каждая команда меняет те экраны, за которые она ответственна. Но сколько это бы стоило?
Предположим, есть команды плеера, витрины и монетизации. Каждой нужно синхронизироваться, вникнуть, отвлечься от других стратегических проектов и вписаться в квартал — это уже занимает немало времени. После из-за непрокрашенных экранов могут начаться споры, и внезапно кажущиеся мелочами проблемы растянут весь проект. Это был не наш вариант.
Мы решили создать команду супергероев, состоящую из техлида, тестировщика и разработчиков с разных платформ — Android, iOS, Android TV, tvOS и Web. За каждым из них был закреплен дизайнер, чтобы контактная работа шла без лишних согласований. Такой подход позволяет один раз глубоко погрузиться в задачи и полноценно заниматься «покраской», не тратя время на повторяющиеся процессы.
При этом каждая платформа «КИОН» должна быть уникальна, поэтому сделать одинаковые токены и общий набор иллюстраций на все сразу не получится. Единственное, что действительно должно было совпадать, — это набор правил по визуальному стилю. В итоге должно ощущаться, что это один продукт, даже если интерфейсы на платформах разные по поведению и по форме.
Синхронизацию между командами мы выстроили через этапность и параллельную работу над одними и теми же шагами. Кто, как и что делает, понимали через регулярные встречи и ретро, — это позволило нам двигаться в одном темпе и не собирать все в последний момент.
Однако у такого решения есть обратная сторона: ты становишься первым виновным, если что-то сломалось, даже если ты это не трогал. Отдельное испытание — 20 ревьюверов и ревью на 4000+ изменений, в котором есть участки, которые невозможно нормально декомпозировать и нужен один цельный пул-реквест (Pull Request, PR — запрос на слияние).
Этап 3. Совместная работа разработчиков и дизайнеров
Следующий этап ребрендинга — это попытка понять, каким должен быть итоговый результат. Здесь сразу появились вопросы: как все будет сочетаться, какие цвета останутся, какие иллюстрации подойдут и как в целом будет выглядеть продукт? Четкого представления об этом ни у кого не было.
Когда у приложения больше 30 экранов, то ни дизайнер, ни продакт-менеджер, ни разработчик не может показать полноценный макет, к которому все должны стремиться. Его просто не существует: часть экранов живет в A/B-тестах, а часть появляется в редких сценариях.
Единого источника правды у нас тоже не было, поэтому макеты делались поэтапно и каждый разработчик с дизайнером были ответственны за свою платформу. Например, мы собирали все найденные места по Android TV в документ по этапам, обсуждали пул работ, проговаривали, как видим итог и чего хотим добиться. Другие команды подключались только при острой необходимости. Звучит базово, но необходимость постоянной коммуникации часто недооценивают.
В моменте ребрендинга у нас параллельно проходило около 100 экспериментов и каждая вертикаль управляла своими. Помимо ранее поставленных задач, вошли следующие:
новые полки витрины;
несколько видов оплаты с разными экранами;
обновленная царь-карточка для веба;
UI-дизайн экрана авторизации.
Самыми запоминающимися оказались эксперименты, связанные с экранами оплаты и покупками пользователей. Там десятки всплывающих окон, разные акции, устаревшие спецпредложения и старые подписки, которые живут с 2020 года. Все это нужно было найти, привести к единому виду или вовсе удалить.
Иногда приходилось возвращаться к уже закрытым задачам. Например, дорабатывать экраны из-за поимки баннеров, которые показываются раз в десять показов у 70% пользователей, а ты находишься в 30% неудачников. Только преодолевая все эти трудности, мы понимали, что должно получиться в конце.
Чтобы не утонуть в этом объеме работы и не выгореть, важно было учитывать принципы.
Первый — декомпозиция на этапы. Сначала шла архитектурная подготовка, затем замена фонов и цветов, интеграция новых компонентов, добавление анимаций и специфических фич. И уже потом — оптимизация и работа с кешированием.
Второй — максимально использовать фича-флаги (Feature Flag — техника разработки ПО, позволяющая включать, отключать или изменять функциональность приложения в режиме реального времени). Все, что можно было закрыть флагами, мы закрывали, но при этом все стремились к цельному переходу. Параллельно готовилась замена стоковых ресурсов, чтобы в момент переключения приложение выглядело единым, а не собранным из разных состояний.
Этап 4. Наполнение бэклога
Когда у нас появилось четкое понимание того, что мы делаем, пришло время разработки. Именно в этот момент проблемы становятся видимыми и ты понимаешь, в какую сложную ситуацию попал.
Во-первых, не все было переведено на свежий стек, поэтому в какой-то момент приходилось лезть в самый темный уголок приложения. У нас, например, нашелся экран со списком передач, который появляется только при нажатии на пульте «вниз». Больше нигде ты о нем не узнаешь, пока случайно не наткнешься.
Параллельно всплывали дополнительные «хотелки», которые нужно было встроить вместе с ребрендингом. Они оказались не такими простыми, как звучат. Из примеров: мы делали экран авторизации для детей с красивыми анимациями и внедрение дизайн-системы в тех местах, где ее раньше не было.
Иногда, если везло, можно было найти залежи предыдущего ребрендинга. Они способны сэкономить каплю времени, но легко могут обернуться мучениями, потому что старые заготовки не всегда совпадают с тем, что нужно сейчас.
Этап 5. Реализация задач и тестирование
На этом этапе приходилось искать единый подход к стилистике между разными фреймворками. В какой-то момент разработка даже превращалась в небольшой рефакторинг всего приложения, который, хочется верить, спасет пару разработческих жизней в будущем.
Однако ближе к финалу кода уже не хватает — приходилось включать навыки убеждения и отстаивать результат перед тестировщиками, которые поэтапно проводят ручное и дизайн-тестирование. Здесь могу посоветовать подружиться со всеми, найти общий язык и научиться коммуницировать. Также к тестировщикам лучше приходить после подтверждения от дизайнеров.
Зачем все это было нужно
В итоге с ребрендингом мы получили не только свежий интерфейс, но и более управляемый код, который поможет осуществить все желания дизайнеров и продактов. А также бесценный опыт глубокого взаимодействия разработчиков и дизайнеров через экспериментальное создание отдельной команды из штатных специалистов.
Проект еще не закончен, поэтому финальных итогов не будет и метрики все еще измеряются. По срокам ребрендинг изначально планировали с сентября 2025 года по февраль 2026-го, но уложились быстрее, чем ожидали, и закончили в декабре 2025-го. Из того, что уже видно:
продакт-менеджеры довольны — KPI вырос, а также появился свежий взгляд и возможность выхода на генерацию новых функций;
разработчики пострадали — ребрендинг задел чужой функционал, было ревью громадного полотна кода и последующие баги, которые первостепенно проходят через них;
UI стал цельнее — появился новый взгляд на сервисы «КИОН», единая дизайн-система и легкая управляемость цветовой палитрой всего приложения.
При этом crash-free просел — это неизбежная часть процесса, которая потом превращается в пару недель исправления ошибок и стабилизации. По перформанс-метрикам: замеры скорости старта не изменились, а вот потребление памяти стало немного выше.
Из личных инсайтов. Я понял, что мне нравится вбрасывать информацию о предстоящих изменениях и наблюдать за реакцией команды. А если честно, ничего такого, что было бы «впервые в жизни», не случилось. Просто понравилось работать полностью вовлеченным и пришлось много коммуницировать.
Свою роль я бы описал просто: любитель своего дела и человек, который тащит большой кусок стратегического проекта. Хотел бы я повторить? Думаю, да.
А как проходил ваш ребрендинг? Делитесь эмоциями и задавайте вопросы в комментариях.
