Обновление дизайна UI в проекте, который уже запущен в релиз — тема скользкая. Когда, как, а главное — зачем это делать? В этой статье я расскажу, как этот вопрос решался в нашем конкретном случае и поделюсь своими мыслями и советами на эту тему.
Меня зовут Киселёв Борис, последние 12 лет я работаю UI/UX дизайнером в различных мобильных игровых студиях. Проект, про который пойдет речь в статье, это World War Armies — кроссплатформенная RTS с прямым управлением юнитами в сеттинге Второй Мировой, сделанная на Unity.
На момент написания статьи игра находилась в оперировании уже полтора года. Интерфейс, ставший в результате релизным, первоначально задумывался как “черновой" и разрабатывался в довольно хаотичной манере. Думаю, многим небольшим студиям знакома эта ситуация. Изначально такая бессистемность разработки не выглядела проблемой: пока проект не приносит денег, скорость и гибкость в разработке всегда кажутся важнее правильной архитектуры. Лоск ведь можно навести и во время уборки в проекте, “когда-нибудь”, верно?
Со временем наша UI-cистема стала громоздкой, медленной и непонятной, а сам интерфейс, хоть и выполнял свою функцию, безнадежно устарел морально. В команде появилось стойкое ощущение, что UI не дотягивает по качеству до среднего на рынке, и что игра достойна большего.
Так зародилась идея редизайна.
Цели и ожидания
Помимо внесения собственно визуальных изменений в интерфейсе, мы ставили перед собой еще несколько задач:
Совместить редизайн с ребрендингом проекта и всей студии
Отойти от стилистики второй мировой.
Перенести работу с макетами из Photoshop в Figma.
Подготовить интерфейс к дальнейшему релизу проекта на ПК.
Навести порядок в той части файловой системы, которая относится к интерфейсу.
Сразу было понятно, что до момента запуска нового UI нам понадобится как-то поддерживать уже существующую систему. Значит, все новые продуктовые фичи во время "переходного" периода придется делать в двух экземплярах: в старом дизайне и в новом. Это как ехать на старой машине, в которой и так что-то постоянно ломается, и параллельно делать вторую, посвежее и помоднее. Согласитесь, звучит как огромная по трудозатратам и количеству неизвестных факторов задача.
Какие у нас были ожидания? Неоднозначные. Внутри студии не было понимания того, как именно обновление интерфейса повлияет на продукт. Возможно, что никак. Коллеги из других игровых студий рассказывали, что у них обновление UI положительно отразилось на метриках, но это история очень индивидуальная и непредсказуемая. Нельзя было исключать и тот вариант, в котором сделанные изменения придется откатывать после релиза из-за значительного падения метрик. Со стороны звучит рискованно, но на самом деле это довольно стандартная ситуация для тех случаев, когда речь идет о визуальных изменениях. Субъективно мы, разработчики, можем считать, что нововведения пойдут проекту на пользу. Однако подтверждения этому (тем более до начала работ) найти довольно сложно. Зачастую они либо незаметны на метриках, либо вообще непонятно: а что мерить? В нашем случае решение было принято довольно стихийно. Мы сошлись на том, что готовы смириться с рисками, и что вот нам — надо.
Решение это было принято сердцем, а не разумом.
Дальше я расскажу про техническую составляющую процесса, о том, с какими проблемами мы столкнулись в процессе и каковы были итоговые результаты всей авантюры.
План, надежный как...
Мы заранее постарались обезопасить себя от возможного факапа, поэтому обязательным условием при создании всей фичи была её отключаемость. В том маловероятном (как нам казалось) случае, если новый дизайн покажет себя заметно хуже старого, мы хотели иметь возможность дернуть за условный рубильник и безболезненно откатить все изменения. А потом сделать вид, что ничего и не было.
Вкратце, план состоял из следующих пунктов:
Находим подходящий визуальный стиль для UI — рисуем несколько ключевых экранов-эталонов, которые станут референсами для всех остальных.
Отрисовываем все экраны и окна в новом дизайне — уже в Figma. Всего у нас в игре тогда было порядка 90 экранов и окон. Макеты для них изначально были сделаны в Photoshop и хранились на Google Drive.
Когда мы отрисуем все макеты экранов в новом дизайне, начинаем постепенно переносить их в движок, переверстывая, но пока не подключая.
Как только набирается критическая масса переверстанных экранов и сформируется будущая система элементов и компонентов UI внутри Unity, начинаем переподключать экраны в движке, параллельно доверстывая недостающие.
Прокатываем поэкранно новый интерфейс через QA, правим найденные баги и релизим.
Фиксируем и анализируем результаты.
Дедлайна изначально не было. Он появился позже, естественным образом, по мере приближения релизных сроков для ПК-версии.
Весь план выглядел достаточно подъемным. Имея список всех экранов, ожидающих переделки, мы могли легко мониторить и прогнозировать каждый этап. В теории.
Поиск нового визуального стиля UI
Сеттинг нашей игры — вторая мировая. Часто это подразумевает скевоморфичный стиль интерфейса. То есть кнопки, плашки и панельки, стилизованные под использование реальных материалов и текстур, с приглушенной палитрой, в которой доминируют серо-коричнево-зелёные цвета.
Примеры скевоморфичных интерфейсов из аналогичных по сеттингу игр
В редизайне мы хотели уйти от этой концепции и целились в более легкий, простой и энергичный визуал, вызывающий ассоциации со спортивными соревнованиями. Также мы хотели выработать набор запоминающихся визуальных элементов, которые выделяли бы нашу игру на фоне других.
За несколько недель мозговых штурмов арт-отделу удалось нащупать оригинальный (и не ассоциирующийся с войной) визуал интерфейса, вызвавший положительную реакцию в студии.
Примеры экранов "было-стало".
Отрисовка экранов. Figma вместо Photoshop.
Начну с небольшого пояснения для тех, кто не понимает, откуда тут вообще вылез Photoshop. Какое отношение он имеет к разработке интерфейсов?! Все верно, практически никакого. Ни один веб‑дизайнер в здравом уме не будет собирать интерфейсы в этой программе, однако в игровых студиях это обычное дело. Логика тут следующая: в играх повышенное количество «художественных» элементов UI на квадратный пиксель. Иногда игровые интерфейсы — настоящие произведения искусства. Сложные эффекты и стили, маски, текстурные заливки, огромное количество слоев с целым зоопарком режимов наложения... Игроки привыкли к очень высоким художественным стандартам в этой сфере. Привычных пакетов веб‑дизайнера становится недостаточно и на помощь приходит машина Photoshop'a. Впрочем, в последние годы Figma медленно, но верно теснит старичка даже в игровых студиях. В отличии от Photoshop, Figma позволяет удобно создавать и поддерживать систему компонентов интерфейса и работать с динамическими лэйаутами.
Чтобы вы понимали всю боль работы UI/UX дизайнера в Photoshop, простой пример. В нем можно создать библиотеку компонентов (например, кнопок), но для любых изменений конкретной копии, от размера элемента до текста внутри, необходимо разбить ее связь с библиотекой, превратив в независимую сущность. Тривиальная задача внезапно превращается в титанических размеров квест.
Также упомяну свою любимую "вишенку" на торте — размеры файлов PSD:
Хранили мы их, напомню, в облаке, которое надо регулярно обновлять.
Переверстка экранов в Unity.
Итак, пара недель месяцев работы и, как по волшебству, у нас появляются макеты всех экранов в новом дизайне и с потрясающей системой компонентов!
Дальше начинается самое интересное — перенос макетов в движок.
Перед началом верстки мы разбили все экраны на три логические группы. В первую вошли те, которые игроки видят постоянно: главное меню, инвентарь, подготовка к бою и т.п. Они являются обязательной составляющей базового игрового цикла. До тех пор, пока они не будут закончены в новом стиле, релизить фичу редизайна мы были не готовы. Сюда же можно отнести экраны, так или иначе связанные с монетизацией игры.
Во вторую группу вошли экраны и окна, которые игроки открывают не каждый раз или только при специальных условиях. Например, окно привязки аккаунта, профиль игрока или правила события. Было решено, что никто не умрет, если визуал этих экранов будет обновляться постепенно, от релиза к релизу.
Третья группа экранов представляла собой по сути только боевой HUD, геймплейную часть интерфейса.
Как выглядит боевой HUD
Его мы решили в первой итерации редизайна не трогать вовсе.
Во‑первых, он представляет собой довольно обособленное пространство со своими правилами и визуалом. Например, только там мы использовали круглые кнопки, которые более удобны для быстрого слепого использования.
Во‑вторых, игроки очень чувствительны к любым изменениям геймплейного интерфейса. Коллеги из игровых студий, уже прошедшие этот путь, рассказывали, что игроки крайне негативно (вплоть до массовых «бойкотов») относятся к любым изменениям геймплейного интерфейса. Даже если, согласно аналитике, новая версия работает лучше предыдущей. Мы решили для начала посмотреть, как пройдет редизайн мета‑части игры, и только в случае успеха перейти к вопросу изменения боевого HUD'а.
Нужно ли релизить все экраны сразу в формате редизайна или лучше делать это по частям — для меня все еще открытый вопрос. Понятно, что лучше было бы выпустить все и сразу (да еще и без багов), но это сферическая правильность в вакууме. В начале работы с фичей я придерживался концепции «выпускаем все целиком», но под конец переобулся и теперь считаю, что подобный подход ошибочен. В реальности вести параллельно две разных работоспособных версии интерфейса — то еще «удовольствие». Чем раньше удастся отказаться от дублирования экранов, тем легче, проще и предсказуемей станет жизнь всего проекта.
Насколько мне известно, никто из тех, кто релизил редизайн интерфейсов по кусочкам, не столкнулся с заметным негативом от игроков по этому поводу или с просадками в метриках. В целом я думаю, что это дело индивидуальное и зависит от многих факторов: ресурсов внутри студии, поставленных сроков, различий в визуале старой и новой версии UI (сильно ли бросается в глаза разница) и т. п.
Проблема ресурсов. Интерфейсы и аутсорс.
Наша команда относительно небольшая. UI/UX дизайнер только один. Поскольку помимо редизайна UI требовалось поддерживать уже существующую систему экранов, а в дополнение к этому вести постоянный поток новых фич, мы сразу понимали, что работы стоит лучше максимально делегировать. Попыток было две. Одна с привлечением интернов, вторая — с помощью опытного специалиста на аутсорсе. К сожалению, обе провалились, и это был полезный для меня урок.
Интерны съедали очень много времени и требовали практически ручного контроля, не добирая при этом желаемого качества. Справедливости ради, на этот вариант мы особо и не надеялись, но все равно дали ему шанс.
С аутсорсом вышла печальная история другого рода. Несмотря на то, что скилл и опыт привлеченного специалиста не вызывали сомнения, за месяц сотрудничества ни одного законченного экрана «под ключ» мы не получили. Произошло это по нескольким причинам. Главная, на мой взгляд, это принципиально недостижимая степень интеграции аутсорса во внутрянку проекта. Интерфейс любой игры — штука уникальная, полная своих особенностей и фишечек, костылей и велосипедов. И тут два варианта. Либо человек «снаружи» (которыйможет вести еще N проектов, помимо вашего) начинает дотошно во все врубаться, задает тонны вопросов, находится в постоянном контакте с программистами и тратит на это огромное количество своего времени и «мыслетоплива». Как итог, в этом случае он скорее всего получает оффер и присоединяется к команде на постоянной основе. Второй путь — это когда аутсорсер игнорирует все эти заморочки и молча делает так, как привык и как быстрее. В нашем случае это привело к тому, что сделанные просто экраны просто не подошли для дальнейшей работы. Их оказалось невозможно переподключить малой кровью, т.к. внутрянка префабов кардинально отличалась от первоначальной.
В результате, по прошествии пары месяцев, мы оказались в ситуации, когда сроки уже профакапили, а переверстка по факту так и не началась. Готовых к подключению экранов не было.
Это, пожалуй, был последний момент, когда еще можно было дать заднюю и отказаться от идеи редизайна, обойдясь при этом относительно малой кровью. Но нас к тому моменту уже было не остановить! Пришлось закатать рукава, ужаться во времени и сделать все теми силами, которые имелись в наличии.
Подключение сверстанных экранов
Как я уже отметил, мы делали редизайн с фичафлагом, то есть с возможностью быстро и легко его выключить. Для этого в проекте по факту хранилось две (на самом деле три — еще же ПК) версии префабов экранов и визуальных конфигов: для старого интерфейса и для нового. Они были разнесены таким образом, чтобы (в теории) при удалении всех элементов старого интерфейса поломалось минимум связей в новом. Так же были продублированы все спрайты: в старом интерфейсе использовались только старые текстуры, в новом — только новые, частично при этом дублирующие старые.
Поскольку изменение визуала экрана чаще всего влекут за собой изменение внутренней структуры префабов (количество «слоев», их группировка и положение, анимации, нейминг), после верстки требуется переподключить весь код к новым компонентам. При этом чем меньше логических изменений в новом экране после редизайна, тем лучше. Идеальная ситуация — когда экран сразу после верстки удается запустить сходу и без ошибок. К сожалению, в нашем случае такое случалось нечасто.
Не владея даже основами C# я мог лишь банально, подобно усердному двоечнику, «списывать» структуру из старых префабов. Зачастую я просто не понимал, почему тот или иной элемент магическим образом перестают работать в новом дизайне, хотя прекрасно функционируют в старом. Это порождало много проблем и требовало большой последующей корректирующей работы со стороны программистов.
Этапность, к которой мы в результате пришли и которая более‑менее гарантировала отсутствие ошибок на редизайненных экранах, выглядела так:
Верстальщик собирает экран и подключает его в меру своих возможностей. Обычно после этого экран не запускался «из коробки» и отсмотреть его в разных вариациях в игре еще не представляется возможным.
Программист подключает экран, добиваясь его работоспособного состояния.
Экран вновь возвращается верстальщику на доделку. Проверяется, как он работает уже внутри игры, в разных вариантах и на разных девайсах в симуляторе. Большинство визуальных багов отлавливается на этом этапе.
После такой первичной проверки, экран передается в отдел тестирования, где его гоняют уже «по‑взрослому». Верстальщик и программист на этом этапе только правят баги по мере поступления тикетов от QA.
Когда поток багов иссякает, работу с экраном считаем успешно завершенной и перекладываем его в папку с «готовыми» префабами.
Даже при таком количестве этапов объем багов, просочившихся в результате в релиз, был значительным. Настолько значительным, что отразился на базовых метриках вроде ARPDAU во время AB‑тестирования после релиза фичи. Негативный эффект смягчила постепенная раскатка фичи, так что самую сырую версию увидело лишь небольшое количество игроков, благдоря которым нам удалось найти и починить большую часть проблем.
Например, в первые же дни мы столкнулись с тем, что у игроков с оплаченным боевым пропуском в новой версии интерфейса пропадала возможность собирать награды за квесты. Для таких игроков фичу пришлось отключать — до тех пор, пока баг не будет поправлен. То есть люди с новым дизайном UI после покупки получали в нагрузку «downgrade» интерфейса до предыдущего состояния.
И поверьте, эта была далеко не единственная проблема.
В целом, весь процесс редизайна от стартовой отмашки до первого релиза занял у нас примерно 10 месяцев. Из них первые шесть месяцев мы в основном переносили экраны в Figma с параллельной отрисовкой в новом стиле. Это происходило в фоновом режиме, между актуальными задачами и выполнялось силами дизайнера, поэтому заняло так много времени. На фазу активной работы пришлось 3–4 месяца, во время которых и были зайдествованы, помимо дизайнера, разработчики и тестировщики. После нескольких релизов с правками и багофиксами результаты версии с новым UI наконец стабилизировались, и стало возможным обсуждать и анализировать полученные данные.
Что по метрикам
Откровенно говоря, я не ожидал каких‑либо заметных и однозначно положительных изменений после ввода нового UI. Все‑таки фича не влияла на геймплей и не вносила принципиальных новых сущностей. Основные изменения касались внутренностей проекта и визуальной составляющей.
Коллеги из игровых студий, прошедшие тот же путь, рассказывали, что у них редизайн интерфейса действительно улучшил метрики «в среднем по больнице», но со множеством нюансов. Где‑то (в основном) стало лучше, где‑то чуть хуже. В некоторых местах — заметно хуже. Также эффект варьировался от страны к стране. Один и тот же экран в новом дизайне мог показывать более высокие метрики в Германии и более низкие в Корее.
В нашем случаем главным измеряемым положительным эффектом от редизайна UI стало то, что retention новых пользователей, вернувшихся в игру в 1-й день, в редизайне заметно повысился:
Разница для второго дня составила +10.4%, для третьего +7.2%, для седьмого +3.2% в пользу нового UI. Для старых игроков разница в retention также фиксируется, но в районе всего 1% в пользу редизайна.
ARPU для новых пользователей не изменился. Конверсия в платящих у старых игроков осталась неизменной, а у новых чуть поднялась. В среднем вышло примерно +0.5% в пользу редизайна.
ARPDAU старых игроков в редизайне сократилось, но затем постепенно выправилось. Вероятнее всего это было связано с багами нового UI.
Если анализировать фичу исключительно с финансовой точки зрения, смысла в редизайне особо не было. Взяв и сравнив цифры было/стало, мы увидим, что редизайн окупит стоимость своей разработки примерно за два года. Да, Уоррен Баффет посмеялся бы от души, видя такие «инвестиции», однако я напомню, что помимо (изначально невысоких) финансовых ожиданий от редизайна, он был нужен для корректировки имиджа и бренда игры и компании, а также для решения некоторых технических проблем. Эти составляющие фичи перевести в денежный эквивалент я затрудняюсь.
Это все, что касается объективных данных, которыми я могу с вами поделиться. Еще есть массив субъективного фидбэка.
Отзывы игроков
Люди, как известно, не любят переучиваться. Спустя определенное время любой, даже самый неудобный, но привычный интерфейс становится... ну, приемлемым. И когда его меняют, это чаще всего вызывает недовольство у пользователей. В нашем случае изменения были практически исключительно визуальными, так что я надеялся, что нам удастся избежать большого негатива. Напрасно! Полученный от игроков фидбэк можно в лучшем случае назвать «смешанным». Напихали нам знатно и по делу, в основном за многочисленные баги на релизе.
Примеры отзывов игроков
"Old was better".
"Старый и лучше и удобней".
"Все круто, есть баги но в целом все красиво и сочно".
"It's terrible..now we can't see the unit names and the amount of cards needed to upgrade".
"It’s good, but it’s more laggy than the past version".
"Общий вид нравится меньше" .
"Приятный, не напрягает глаза. стал более "взрослым". лично мне material нравится, поэтому тут тоже зашло".
"The new interface gives a fresh touch to the game, it is very different from how it was in the beginning and it looks very good".
"Beat and tidy, good improvement".
"Okay, but there is some work to be done".
"it is so good, I like that".
"I like the clean new look. It's a nice refresh from the dull generic animation it used to be".
Как и ожидалось, UI баги вне игрового HUD игроков особо не смущали, а вот любые интерфейсные проблемы в бою были для них критичны и сильно аукались на оценках в сторах.
Стоит держать в уме, что отзывы это лишь верхушка айсберга, мнение активного меньшинства. Подавляющее же большинство игроков даже не будет напрягаться ради того, чтобы устраивать полемику с разработчиками. Они молча проголосуют своим временем и рублем. Поэтому, как мне кажется, изменения метрик показывают всегда более объективную картину, а живой фидбэк от игроков позволяет лишь понять и отловить самые заметные и сильные их боли.
Итоги
Что я в итоге могу посоветовать тем, кто также задумывается о редизайне интерфейса своей игры:
Если ваш проект находится в оперировании меньше года, или если еще даже не вышел в оперирование, не думайте о редизайне. Если вы недовольны текущими показателями игры, тюнинг визуала UI скорее всего их не спасет, «ракеты» не будет. Сосредоточьтесь на других, более важных игромеханических аспектах. Тут я оговорюсь, что UX этот совет не касается. Повышайте удобство интерфейса всегда, когда есть такая возможность!
Чисто финансовый выхлоп от редизайна в нашем случае выражался исключительно в повышении Retention. Для нашего проекта она не так влияет на доход, но для игр с более рекламной монетизацией это может быть равноценно поднятию доходов.
Не занимайтесь редизайном интерфейса, если и без него ощущаете нехватку ресурсов, временных и человеческих. Добавить к постоянному авралу сверху еще один — верный путь к падению общей планки качества по всем фронтам.
Уделите достаточное количество времени тем этапам, которые находятся как бы «между» зон ответственности разных отделов. Как показывает практика, они самые проблемные. Кто контролирует качество на каждом из этапов? Кто осуществляет приемку и передачу с одного этапа на другой? Кто и когда правит всплывающие косяки? Кто может вернуть экран с одного этапа на доработку на предыдущий и при каких условиях? С кого спрашивать в случае проблем?
По возможности проводите релиз редизайна отдельными экранами, не тяните до последнего в желании выпустить всё и сразу.
Будьте морально готовы к просадкам и проблемам в первые дни релиза. Интерфейс — он как клей, связывающий всю игру воедино. Связей очень много и шансов на то, что что‑то пойдет не так, тоже. Ну, либо вариант «Б»: закладывайте прям много времени на тестирование.
Не задействуйте аутсорс для таких чувствительных задач, как пересборка интерфейса или создание дизайн‑системы. Если надо — наймите человека в штат. Так вы сэкономите себе время, деньги и нервы.