Редизайн игрового лаунчера

Контекст

RustMe — многопользовательская survival-игра, которая переносит игровой опыт Rust в рамки Minecraft. Игрок авторизуется в отдельном desktop-лаунчере, подгружает нужную версию клиента и уже через неё запускает игру.

Клиент — версия игры, которую лаунчер загружает и запускает для подключения к определённым серверам.

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

Клиент — версия игры, которую лаунчер загружает и запускает для подключения к определённым серверам.

Friday

Вайп по пятницам

Группа серверов, на которых игровой мир очищается каждую пятницу.

Monday

Вайп по понедельникам

Группа серверов, на которых игровой мир очищается каждый понедельник.

Wednesday

Вайп по средам

Группа серверов, на которых игровой мир очищается каждую среду.

Как устроены серверы

Какие версии клиента запускает лаунчер

Задача

Изначально запрос от продакт менеджера звучал коротко: сделать редизайн лаунчера.

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

Итак, я сформулировала задачу шире простого рестайлинга:

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

Изначально запрос от продакт менеджера звучал коротко: сделать редизайн лаунчера.

Итак, я сформулировала задачу шире простого рестайлинга:

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

Проблемы

Крупные обновления выходят на серверах не одновременно, всегда начиная с Friday. Тогда для Monday и Wednesday предусмотрен устаревший профиль.

Старый лаунчер показывал пул профилей для входа в игру, но почти не объяснял, для каких серверов они предназначены. Этот контекст жил в соц. сетях. Игроку нужно было увидеть новость, интерпретировать её, запомнить название нужного профиля и вернуться в приложение. Для части ЦА такая цепочка действий регулярно ломалась.

Особенно заметной проблема выбора профилей становилась во время открытых тестов или выхода обновлений.

Ситуация	Что происходило
Выход обновления / Запуск тестов нового контента	Новый контент сначала загружается на сервера Friday
Параллельные версии (разные профили)	Monday и Wednesday временно продолжают работать на теперь уже устаревшей версии клиента
Ошибочный выбор профиля	Для юзера сохраняется возможность зайти на сервера с недавним обновлением / тестовые сервера через устаревший профиль (техническое ограничение)
Конфликт версий	Новые механики работают неправильно; в техническую поддержку или в комментатрии соц. сетей начинают поступать жалобы с ложными багрепортами

Особенно заметной проблема выбора профилей становилась во время открытых тестов или выхода обновлений.

Ситуация	Что происходило
Выход обновления / Запуск тестов нового контента	Новый контент сначала загружается на сервера Friday
Параллельные версии (разные профили)	Monday и Wednesday временно продолжают работать на теперь уже устаревшей версии клиента
Ошибочный выбор профиля	Для юзера сохраняется возможность зайти на сервера с недавним обновлением / тестовые сервера через устаревший профиль (техническое ограничение)
Конфликт версий	Новые механики работают неправильно; в техническую поддержку или в комментатрии соц. сетей начинают поступать жалобы с ложными багрепортами

Мой подход

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

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

Пользователь должен:

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

Пользователь должен:

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

01. Перевела профили в понятные состояния

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

Дополнительно проработала состояния запуска, загрузки и обновления.

02. Разделила общий и локальный контекст

В рамках редизайна я спроектировала главную страницу с промо-материалами. Здесь собраны все последние изменения в игре.

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

Любой медиа-контент можно просматривать в момент, пока профиль обновляется.

03. Универсальная структура и визуал

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

Приведу пример. Для внедрения кнопки смены региона подключения нужно было добавить в настройки drop-down с вариантами RU, EU и AUTO и показать пинг. В существующем интерфейсе было сложно найти место для нового компонента или добавить скролл страницы, сохранить читаемость на текстурном фоне и пользоваться имеющимися стилями типографики.

Подобный опыт сформировал два принципа редизайна:

Без текстурных фонов и разрозненных графических элементов;
Заранее заложенная масштабируемая компонентная система.

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

Подобный опыт сформировал два принципа редизайна:

Без текстурных фонов и разрозненных графических элементов;
Заранее заложенная масштабируемая компонентная система.

Первая продакшн версия и другие этапы релиза

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

Итерация	Что изменилось
✔ Вторая итерация — авторизация двух аккаунтов одновременно	Точечное исправление вёрстки и логики механики профилей. Авторизация до двух аккаунтов одновременно с возможностью свитчить их без перелогина — запрос от ЦА по результатам первого анализа продукта. Ограничение именно на 2 аккаунта предложено мной в рамках защиты продукта от читеров.
✔ Третья итерация — скролл для списка профилей	Спроектировала ограничение для видимого блока профилей и добавила скролл. Обычный пользователь не видит больше трёх профилей одновременно (чаще 1-2). Но дополнительных рабочих клиентов для команды оказалось более 5. Был риск наезда профилей на соседние компоненты.
⚙️ Четвёртая итерация — новый функционал, Airlock Tool (рабочее название)	Предложила внедрить сложную проверку безопасности ПК в блок настроек вместо проектировки отдельной утилиты, т.к. это усложненный путь для игрока. Спроектировала интерфейс на основе UI-kit по результатам общения с разработчиком анти-чит системы.
⚙️ Пятая итерация — уведомления	Подготовила редактируемые компоненты в макете, но оставила функцию в статусе groundwork до появления подтверждённых событий и данных

Итерация	Что изменилось
✔ Вторая итерация — авторизация двух аккаунтов одновременно	Точечное исправление вёрстки и логики механики профилей. Авторизация до двух аккаунтов одновременно с возможностью свитчить их без перелогина — запрос от ЦА по результатам первого анализа продукта. Ограничение именно на 2 аккаунта предложено мной в рамках защиты продукта от читеров.
✔ Третья итерация — скролл для списка профилей	Спроектировала ограничение для видимого блока профилей и добавила скролл. Обычный пользователь не видит больше трёх профилей одновременно (чаще 1-2). Но дополнительных рабочих клиентов для команды оказалось более 5. Был риск наезда профилей на соседние компоненты.
⚙️ Четвёртая итерация — новый функционал, Airlock Tool (рабочее название)	Предложила внедрить сложную проверку безопасности ПК в блок настроек вместо проектировки отдельной утилиты, т.к. это усложненный путь для игрока. Спроектировала интерфейс на основе UI-kit по результатам общения с разработчиком анти-чит системы.
⚙️ Пятая итерация — уведомления	Подготовила редактируемые компоненты в макете, но оставила функцию в статусе groundwork до появления подтверждённых событий и данных

Airlock Tool — проверка масштабируемости архитектуры

Изначально Airlock Tool планировался как отдельная утилита для проверки настроек безопасности ПК. Это очень распространённая дополнительная практика защиты продукта от читеров в популярных онлайн-шутерах.

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

Функция уже интегрирована в лаунчер и проходит тестирование. Скриншоты интерфейса появятся в кейсе после релиза.

Design to Production

Я проверяла продакшн-сборки вместе с разработчиком. Например, в первой реализации профилей были добавлены неверные иконки состояний. Другой пример — слишком мелкий шрифт в drop-down меню профиля игрока. После design QA их заменили на предусмотренные макет. Остальные решения перенеслись практически без изменений.

Что бы я улучшила

Лаунчер нуждается в админ-утилите для управления контентом. В текущей реализации все изменения (например, добавление новостных статей) переходят от меня к разработчику. Такой процесс сильно замедляет контент-наполнение продукта.
Блок инструментов для аналитики в админ-утилите. Дальнейшее развитие продукта без этого сложно представить.
Проверила бы гипотезу замены термина «профиль» на более прямой. Например, «версия игры» или «версия клиента», «сборка». Термин «профиль» больше ассоциируется с профилем пользователя. Это также может помочь снизить количество входов через устаревший профиль.
Техническое ограничение — ошибка совместимости версий. Моя гипотеза в том, что полностью исключить баги и ложные обращения в саппорт из-за использования устаревшего профиля можно только через блокировку входа на сервера, если версия игры не совпадает с актуальной. Сейчас пользователь ситуативно получает ошибку, но с общей формулировкой «Обновите клиент».
Продолжить развивать функцию уведомлений в лаунчере после фиксации реальных событий и подтверждённых сценариев использования.

Лаунчер нуждается в админ-утилите для управления контентом. В текущей реализации все изменения (например, добавление новостных статей) переходят от меня к разработчику. Такой процесс сильно замедляет контент-наполнение продукта.
Блок инструментов для аналитики в админ-утилите. Дальнейшее развитие продукта без этого сложно представить.
Проверила бы гипотезу замены термина «профиль» на более прямой. Например, «версия игры» или «версия клиента», «сборка». Термин «профиль» больше ассоциируется с профилем пользователя. Это также может помочь снизить количество входов через устаревший профиль.
Техническое ограничение — ошибка совместимости версий. Моя гипотеза в том, что полностью исключить баги и ложные обращения в саппорт из-за использования устаревшего профиля можно только через блокировку входа на сервера, если версия игры не совпадает с актуальной. Сейчас пользователь ситуативно получает ошибку, но с общей формулировкой «Обновите клиент».
Продолжить развивать функцию уведомлений в лаунчере после фиксации реальных событий и подтверждённых сценариев использования.

Результаты

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

Снизилась путаница

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

Решение работает

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

Архитектура выдержала рост

Второй аккаунт, новые состояния и Airlock Tool добавлены без полной пересборки интерфейса.

Универсальный UI-Kit

Редизайн стал основой для единого стиля, дальнейшего развития продукта, рабочих утилит и сайта.

Вывод

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

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

‹ COSMOCAT

Редизайн игрового лаунчера

Редизайн игрового лаунчера

Контекст

Контекст

Вайп по пятницам

Вайп по понедельникам

Вайп по средам

Актуальная версия

Предыдущая версия

Тестовая сборка

Задача

Задача

Проблемы

Проблемы

Мой подход

Мой подход

01. Перевела профили в понятные состояния

01. Перевела профили в понятные состояния

02. Разделила общий и локальный контекст

02. Разделила общий и локальный контекст

03. Универсальная структура и визуал

03. Универсальная структура и визуал

Первая продакшн версия и другие этапы релиза

Первая продакшн версия и другие этапы релиза

Airlock Tool — проверка масштабируемости архитектуры

Airlock Tool — проверка масштабируемости архитектуры

Design to Production

Design to Production

Что бы я улучшила

Что бы я улучшила

Результаты

Результаты

Снизилась путаница

Решение работает

Архитектура выдержала рост

Универсальный UI-Kit

Вывод

Вывод