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

Точечные изменения не ноу-хау

Тут в памяти всплывает фраза “Это уже было в Симпсонах”. И да, примером великолепного использования методики точечных изменений служила работы команды BFF, в проекте EVE online. (Best Friends Forever :: “инициатива тысяча мелочей”, прим) Направлением работы команды была работа с сообществом игры через форумы и Звездных Консулов (представителей силовых центров игроков). Составляя план на квартал, команда публиковала его и замеряла реакцию сообщества. План после этого не редко претерпевал существенные изменения, что крайне тепло воспринималось в сообществе.

Видео-презентация инициативы Тысяча Мелочей от 2011 года : EVE Online Dev Blog – Team BFF: Tackling the Little Things

Источник информации о точечных изменениях — игроки

Всегда нужно начинать собирать информацию с игроков. Весь UX — это для них. Очень помогает, если вы сам игрок. В этом случае акцент при сборе информации нужно делать на сегменты, к которым вы не относитесь. Можно найти в коллективе игроков других архетипов и преставать к ним с вопросами время от времени.

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

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

Для долговременного оперирования продуктом все эти компоненты успеха необходимы. Примеры долговременных проектов это подтверждают.

Немного прототипов точечного изменения

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

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

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

Мы потратим время на создание УСЛОВНОЙ мини-презентации для занесения предложения в команду. Под условной я подразумеваю то, что в данном случае она не нужна, но я желаю показать вам, какие элементы обсуждений\утверждений встречаются в настоящем большом проекте. Ведь огромный план реализации нужд оперирования расписан буквально на годы. Чтобы в него бесконфликтно и без стресса, заносить подобные точечные изменения нужны с умом выстроенные процессы и поддержка проектного менеджмента.
 
Хорошей практикой является выделение на очевидные полезности отдельной команды, подобно примеру из EVE online.

Описательная часть проектировки

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

Для тех, кто считает, что UX не существует и решения сыплются в головы UI дизайнеров в виде красивых макетов уже со слоями, дальше, в принципе можно не читать. Аналитика, согласования, изобретательство, опросы, перебор вариантов, «прижимание» концепции к техническим возможностям команды, консультации разработчиков, участие в приемке занимают в 5-6 раз больше времени, чем одна итерация графического дизайна. И если вы считаете, что интерфейс нужно делать «от макета» (есть такое веяние, к сожалению) продолжение материала тоже не для вас.

Формулировка проблемы

Интерфейс в экране управления экипировкой не удовлетворяет значительной части сценариев по оснащению персонажа под сложные активности. Для эффективной игры в сложных активностях игроки используют разные наборы снаряжения и оружия. Это обуславливается ролевой системой, которая построила связку [эффективность]=[требуемый класс оружия]+[перки брони для этого класса оружия].

Сразу приводим пример, который у всех на слуху (желательно именно такой).

Реальный пример из Destiny 2

Игроки в роли «хранителя карты» в рейде «Истребители прошлого» должны использовать дальнобойное высокоточное оружие для противодействия «Вандалам» на соседних крышах. Самым подходящим оружием для этой цели служит снайперская винтовка. Но без поддержки соответствующими перками брони у игроков быстро кончаются патроны. Для того, чтобы справляться с этой ролью в одиночку (что повышает эффективность команды в целом) игроки собирают набор брони со специализацией на снайперские винтовки. В него входят части со свойствами: Резервный боезапас, Заряжатель, Сборщик боеприпасов х2, Локатор особых боеприпасов х2. И еще несколько менее важных перков. Игроку нужна возможность быстро идентифицировать части брони для этого столкновения. В среднем за рейд игрок переодевается 2-4 раза.

В данный момент, у игроков нет возможности быстро определить какая часть брони в инвентаре предназначена для конкретной ситуации. Игра не представляет функциональности «наборов экипировки» примеры которых можно найти у аналогичных игр. Ситуацию усугубляет то, что тематические наборы под конкретную роль собрать почти невозможно. Вероятность того, что требуемый набор выпадет, например, в набор «Железного знамени сезона» очень низкая.
 
Как следствие игроки собирают «наборы под класс оружия» из частей разных тематических наборов. Они выглядят совершенно по-разному и не объединяются никакими внешними признаками, кроме самих перков, которые видны только в экране информации о конкретном предмете. Экран находиться слишком глубоко в иерархии ( третий уровень вложенности), что затрудняет его использование.

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

Добавляем изюма

При торге с руководством очень полезно бывает связать лоббируемую идею с «политикой партии». Поэтому добавим в нашу воображаемую устную речь следующее. Это, искусство и дар божий, поэтому просто приведу врезку для примера. Применять такое можно только на свой страх и риск.
 
«Изменения последних месяцев направлены на балансировку многих классов оружия в PvE с целью поднятия их эффективности с нулевой отметки. Снайперские винтовки, к слову, входят в их число. Поэтому положительный эффект от предлагаемого изменения будет усилять эффект ребалансировки оружия. Это кумулятивный эффект к нашему уже утвержденному плану. Будем следить за реакцией сообщества, хотя все опрошенные игроки очень положительно отзывались о макетах на форуме тестового сервера».
 
Такая пилюля хорошо закрывает блок презентации и помогает продюсерам лучше погрузиться в контекст для вынесения вердикта. Само собой, блефа наша речь содержать не должна. Хотя бывает, что уж тут — тут все свои вроде, должны понимать.

Оценка серьезности и приоритет исполнения

Когда проблема описана, донесена до порождающей планы силы и разъяснена, остается найти ей место в календаре. Тут в силу вступает методика подсчета ее важности. Не сильно вдаваясь в нюансы, перечислю компоненты, которые берут в расчет при определении важности. Оценку дам «на глазок» — доступа к данным аналитики Bungie у меня нет.

Компонент номер 1 — значимость сегмента игроков

Участники этого сценария не более 10% играющих на спаде (т.е. входящие в ядро аудитории игры). Эти игроки проходят сложные активности такие как рейды с испытаниями и сумеречные налеты со сложными модификаторами. В других, менее сложных активностях, специализации не требуется — все проходиться без закорочек. Это один из самых «терпеливых» и лояльных сегментов. Так же это продвинутый сегмент — он вполне способен обходиться функциями сторонних приложений. И по факту участвует в формировании этих функций в сообществе сторонних продуктов.
 
Отличный пример такого приложения Destiny Item Manager в котором не очень удобная функция формирования наборов есть давно (текущий UX, увы, содержит ошибки).

 Итоговая значимость сегмента не выглядит высокой.

В этом срезе «важности» изменение может вполне подождать или вовсе быть отложено.
 

Компонент номер 2 — частота использования

Следующий срез «важности» частота применения проблемной функциональности. Чем выше частота, тем больше условный множитель, поднимающий значимость. В данном случае частота не выглядит высокой. Рейды среднем закрывают 1-2 раза в неделю, сумеречные налеты так же.
 
Для примера можно сравнить нашу проблему с чем-то нехорошим внутри основного игрового процесса (т.е. боя), которое проявляет себя с определенной частотой. Например, один раз в час или один раз в день. Оба случая перебивают частоту возникновения нашей проблемы на порядок. Хотя между собой отличаются так же на порядок.
 
Оценка частоты возникновения неудобства второй фактор оценки важности точечных изменений.

И в этом срезе наша проблема значительной и масштабной не выглядит.
 

Компонент номер 3 — Сложность исправления

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

«Что-то» — лучше, чем «ничего».

Нафантазируем очередное сравнение. Наше изменение оценено в 1 день работы разработчиков. Конкурирующая с ним доработка визуального feedback’а от срабатывания перка «Локатор боеприпасов» оценена в 5 дней работы артистов и в 2 дня работы программистов. Поэтому принимается решение запустить нашу доработку в поток задач-заполнителей (fillers или филлеры), которые исполняются в моменты простоя во время передачи задач между отделами. Такие простои на стыках обязательное явление, которое не берут в расчет исключительно по неопытности.
 
И вот в этом срезе наша задача «занимает» первое место т.к. более быстрых в исполнении задач в нашем логе нет.
 

Компонент номер 4 — Важность для бизнеса

Упоминание влияния точечных изменений на продажи, обязательная компонента оценочного процесса. Функциональность имея большую значимость в этом срезе, легко может попасть на первое место в очереди на исполнение.
 
Наш случай таковым не выглядит. Отвратительно работающие «краски» предметов получат незначительную популяризацию с введением этой функции. Какой-то незначительный сдвиг в монетизации шейдеров может иметь место. Так же прогнозируется незначительное повышение лояльности, которая в случае с ядром аудитории имеет высокую значимость на долговременной перспективе.

Итого

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

---

С вами, был Блот.
До встречи в игре!

Ссылка на страницу с информацией о игре Destiny 2: Перейти