Изучение игроков – это часть процесса оценки игры (приложения, сайта, инструмента и т. п.) с точки зрения удобства использования и увлекательности. UX-аналитики активно отыскивают проблемы, а потом предлагают разработчикам варианты решения. Тем самым они помогают преодолеть проклятие знания, посмотреть на игру издали и под иным углом – под тем, с которого на нее будет смотреть целевая аудитория. Их главная задача – выявить преграды, мешающие создать глубокий пользовательский опыт, с учетом намерений дизайнера и коммерческих целей.
В арсенале аналитиков два главных инструмента: знания (основы когнитивистики, ЧМИ, эргономики и эвристик) и методология (т. е. научный метод). О знаниях мы подробно говорили в предыдущих главах. Теперь позвольте мне познакомить вас с научным методом (если вы, конечно, еще им не владеете).
14.1. Научный метод
Научный метод позволяет систематически искать решение задачи или ответ на вопрос. Это гипотетико-дедуктивный подход, подразумевающий сбор измеримых доказательств и их анализ с использованием стандартизированного протокола, чтобы подтвердить или опровергнуть гипотезу, по возможности, без внесения искажений. Этот процесс итеративен и не слишком отличается от дизайнерских циклов. Обычно все начинается с общих предположений, затем идет фаза концептуализации, на которой изучаются доступные источники по конкретному предмету, делаются широкие наблюдения и формулируются вопросы для дальнейших исследований. После этого идет постановка гипотезы, разработка протокола эксперимента, сам эксперимент, анализ результатов, подтверждение, опровержение или уточнение гипотезы – и общий вывод (чтобы те же или другие исследователи могли повторить результаты или работать с ними дальше).
Формулируя гипотезу, ученый также выдвигает ее противоположность – «нулевую гипотезу», постулирующую, что проверяемая переменная ни на что не влияет. Например, применительно к играм проверяемая гипотеза может звучать так: «Игроки, освоившие правила на практике, в первый час игры погибают реже, чем те, кто просто прочел текст туториала». Нулевой гипотезой в таком случае будет: «Игроки, освоившие правила на практике, в первый час игры погибают с такой же частотой, как и те, кто просто прочел текст туториала». После проведения эксперимента и анализа результатов, если статистическая вероятность того, что нулевая гипотеза не подтверждается, 95 % и выше, то проверяемая гипотеза считается доказанной.
Протокол эксперимента должен гарантировать, что измеренная разница между двумя группами (например, той, которая училась на практике, и той, которая читала туториалы) действительно влияет на проверяемую переменную (количество смертей). Если выяснилось, скажем, что игроки, осваивавшие игровые механики в контексте, погибали реже, чем те, кто читал текстовое описание тех же механик, и эта разница имела статистическую значимость, то ее можно объяснить, например, тем, что чтение в среднем занимает меньше времени, чем практика. Соответственно, результаты зависят не от типа обучения, а от разного времени обработки. Поэтому протоколы должны быть строго стандартизированы, чтобы гарантировать, что выводы сделаны верно.
Результаты научных экспериментов принято описывать в статьях и публикациях, которые проверяются рецензентами и, если методология не вызывает вопросов, публикуются в журналах, чтобы все научное сообщество могло использовать эти результаты в своих теориях и последующих экспериментах. По крайней мере, в идеале. Беда в том, что когда нулевую гипотезу отбросить не удается, ученые либо вообще не пишут статей об исследовании, либо их статьи не принимают к публикации. И это, вероятно, заставляет ученых изо всех сил держаться за свои экспериментальные гипотезы (от внесения бессознательных искажений до намеренной фальсификации), что лишает все сообщество интересных результатов.
Отсутствие результатов (т. е. невозможность опровергнуть нулевую гипотезу) само по себе интересно. В своей увлекательнейшей книге «В поисках памяти. Возникновение новой науки о человеческой психике»[53] нейробиолог, психиатр и лауреат Нобелевской премии Эрик Кандель приводит слова нейрофизиолога Джона Экклса, получившего в 1963 году Нобелевскую премию за работу по синапсам: «Более того, я научился <…> даже радоваться опровержению своих излюбленных гипотез, потому что это тоже научные достижения и потому что такие опровержения позволили нам многому научиться».
В настоящее время множество научных дисциплин переживают «кризис воспроизводимости» [см. Przybylski, 2016], хотя в основном говорят именно об области социальной психологии. Действительно, отдельные результаты первоначального исследования не всегда воспроизводимы, даже если другие исследователи (а иногда и сам автор исследования) применяют тот же протокол. Возможность повторить эксперимент крайне важна, поскольку означает, что методология выбрана верно, число искажений сведено к минимуму, а полученные результаты не случайны. Невозможность повторения, соответственно, вызывает беспокойство и, вероятно, отчасти объясняет недоверие общественности – особенно потому, что СМИ зачастую тиражируют исследования сенсационными заголовками еще до того, как их воспроизводимость была проверена.
Некорректные протоколы, нерепрезентативные выборки и грубо проведенные эксперименты тоже подрывают репутацию науки. Прибавьте сюда фальсификации, к которым нередко прибегают корпорации в попытках убедить людей, что их продукция не опасна. В частности, широко известен факт, что табачные компании подкупали ученых и специалистов, чтобы те опровергали установленную взаимосвязь между курением и раком [см. Saloojee, Dagli, 2000]. Или вспомните, как возникло заблуждение, будто вакцинация увеличивает риск развития аутизма. Всего одного исследования (хотя впоследствии его и его гипотезу полностью опровергли за отсутствием тщательности) хватило, чтобы посеять в родителях страх и сомнения.
Рост недоверия к науке – серьезная проблема, так как способствует появлению фейков (они же «альтернативные точки зрения») и создает простор для новых форм манипуляции общественным сознанием, а это может затруднить жизнь UX-аналитику. Наука – это приверженность поиску истины, а не соревнование в том, кто прав, и уж тем более не инструмент контроля умов. Поэтому крайне важно, чтобы ученые сохраняли непредвзятость. Они не продвигают ничью точку зрения и не дают своего «мнения». Они анализируют ситуацию, пользуясь доступными знаниями и данными.
Задача UX-аналитика – предоставлять объективные данные, помогающие разработчикам принять взвешенные решения. Если он хочет оставаться беспристрастным, ему нельзя «влюбляться» в игру. Хотя я убеждена, что UX-аналитики должны быть частью команды и выстраивать доверительные отношения с разработчиками, не менее важно, чтобы они поддерживали эмоциональную дистанцию между собой и проектом либо поручали проведение тестов сторонним исследователям, чтобы не искажать результаты. Напомню главное: изучение игроков – крайне эффективный способ раннего распознавания насущных проблем, оценки их серьезности и поиска решений.
14.2. Методы и инструменты изучения игроков
Для изучения игроков используется научный метод, но игровая студия – это не научная лаборатория. Она занимается не исследованиями, а разработкой игр, причем обычно в сжатые сроки. Таким образом, изучение игроков нуждается в компромиссе между скоростью и строгостью. Ян Ливингстон называет такой подход «достаточно хорошо» [Livingston, 2016].
Допустим, вы разрабатываете тест, чтобы с его помощью оценить влияние одного условия на другое: например, сколько времени (в минутах) игрок тратит на прохождение уровня с одной раскладкой управления (условие А) и с другой (условие Б). Измерив показатели по каждому условию и вычислив величину стандартного отклонения (т. е. разброс) внутри каждой группы, вы можете изучить результаты по разным доверительным интервалам (т. е. по тому, сколько неопределенности заложено в ваши данные). На рис. 14.1 приведены вымышленные данные, где в интервале 95 % (обычный минимум для серьезных исследований) различия между двумя условиями не статистически значимы. Однако в интервале 80 % уже видно расхождение в показателях эффективности игроков. Хотя в научной работе доверительный интервал 80 % определенно неприемлем, для выбора, какое управление поставить по умолчанию, оно «достаточно хорошо». По крайней мере, так точно лучше, чем гадать совсем без данных.
Рис. 14.1. Доверительные интервалы (за основу взят слайд из презентации Яна Ливингстона на Саммите по игровому UX 2016 г.)
Необходимо отметить, что обычно у нас нет возможности пригласить в UX-лабораторию достаточно большое количество участников, чтобы собрать полноценную статистику. Однако при массовой рассылке опросников или при сборе данных телеметрии во время закрытого бета-тестирования с изменением отдельных переменных (т. е. А/В-тестирование, когда сравниваются показатели эффективности или конверсия при условиях А и Б) очень важно определить для себя приемлемый уровень неопределенности (см. главу 15).
UX-исследование не может быть таким же строгим, как научное, – прежде всего потому, что нельзя собрать достаточно большую выборку для каждого быстрого теста. Это одна из неизбежных вещей, с которыми приходится мириться из-за ограничений геймдева (особенно ограничением по времени). Вот почему протоколы тестов следует составлять весьма тщательно, чтобы предупредить как можно больше потенциальных искажений. Например, участники должны соответствовать профилю целевой аудитории; разработчики не должны общаться с участниками, чтобы не завышать их ожидания (геймеры и без того сами рады прикоснуться к разработке и побывать в офисе студии); участники не должны видеть, что делают другие (чтобы избежать давления окружающих, не узнать что-либо заранее, наблюдая за другими, и т. п.); участникам всегда необходимо сообщать, что тестируется сама игра, а не их умение в нее играть.
Полезно дать участникам понять, что любые трудности и сомнения (даже самые незначительные), о которых они сообщат, сделают игру лучше для всех игроков, особенно менее опытных (иначе участники могут умолчать о чем-нибудь из-за боязни показаться неумелыми игроками). Обязательно сообщите, что исследователи и организаторы теста не имеют непосредственного отношения к разработке, так что любые отзывы, в том числе критические, никого не обидят. По моему опыту, игроки склонны к поблажкам, потому что и так рады прикоснуться к игре на стадии разработки, особенно если им за это еще и заплатят. Напомните, чтобы они не стеснялись давать беспристрастные, прямолинейные отзывы, а также четко формулировали, что им понравилось или не понравилось и почему. Что бы ни происходило, наблюдатели за UX-тестом никак не должны реагировать на происходящее: не смеяться, не вздыхать, не поздравлять участников, когда у тех что-то получилось, и т. п. Участники должны по возможности забыть, что за ними следят, и ни в коем случае не должны чувствовать, что их оценивают, иначе это может повлиять на их поведение (см., например, «эффект Пигмалиона», или «эффект Розенталя», когда ожидания учителя влияют на показатели ученика; Rosenthal, Jacobson, 1992).
Наблюдающие за UX-тестами также не должны делать выводов о намерениях игроков по их поведению. Например, если кто-то из игроков долгое время провел перед экраном, скажем, выбора названия базы, в отчете так и нужно пометить – «долго выбирал название базы», а не делать поспешные выводы вроде «интерфейс выбора названия базы непонятный». Возможно, интерфейс ни при чем; игрок просто думал, какое название будет лучше звучать. Намерения и трудности можно выявить, только проанализировав заметки наблюдателей, показатели игроков и их ответы на опросники. Однако если есть искажения в наблюдении, то будут испорчены и результаты. Поэтому, описывая поведение игроков, сохраняйте нейтральность.
Следите, чтобы разработчики, сидящие за полупрозрачным зеркалом, сами не делали поспешных выводов. Очень хорошо, когда разработчики наблюдают за тестом, но им нужно объяснить, что их собственные знания и ожидания могут окрасить их интерпретацию действий (и бездействия) игроков. Поэтому, прежде чем делать выводы о поведении игроков, лучше дождаться отчета от UX-аналитика. Суть научного метода – избавиться от искажений. Добейтесь, чтобы все это понимали.
Наконец, пусть участники подпишут соглашение о неразглашении (NDA). Напомните им, что они ни с кем не должны обсуждать ход теста. Мне не приходилось сталкиваться с утечками после UX-тестов, но такой риск есть, и утечка может подорвать доверие остальной студии к аналитикам. Поэтому не зазорно попросить участников, чтобы они выложили из карманов посторонние предметы, особенно записывающие устройства (смартфоны, флешки и т. д.), и заперли их в отдельном шкафчике.
Ниже я кратко опишу основные методы и инструменты изучения пользователей, применяемые в игровой индустрии [см. также Lewis-Evans, 2012]. В большинстве случаев вам нужно набирать контингент из вашей целевой аудитории (а для этого требуется хорошо ее представлять). Поиск участников особенно времязатратен, так как необходимо найти игроков требуемого возрастного диапазона (помните, что если привлекаете несовершеннолетних, то нужно соблюсти ряд юридических проволочек), которые играют в игры, похожие на вашу, с требуемой частотой (время от времени либо часто). Также им должны быть удобны дата и время проведения теста. В общем, планируйте поиск заранее; обычно на хорошую выборку уходит минимум неделя.
14.2.1. UX-тесты
UX-тесты – основной метод изучения пользователей. Вы набираете участников со стороны (представителей целевой аудитории) и смотрите, как они взаимодействуют с теми или иными элементами вашей игры (сайта, приложения и т. п.). Перед началом теста необходимо удостовериться у команды разработки или даже у отдела качества, что текущая сборка стабильна (т. е. не зависает и не вылетает каждый раз) и не содержит багов, мешающих воспринимать тестируемые механики. Прочие недоработки не столь страшны; главное, чтобы вы знали, как их обойти. Например, если определенный герой или определенная способность ломают игру, просто скажите участникам теста их не использовать.
В зависимости от стадии разработки и того, что именно тестируется, выделяют следующие типы UX-тестов.
• Анализ задач. Вы смотрите, получается ли у игроков выполнить конкретную игровую задачу, – например, собрать карточную колоду. Это обычно короткие тесты, нацеленные на измерение конкретных параметров, таких как затраченное время или число совершенных ошибок. Их лучше всего проводить на тестовых уровнях, созданных под определенную задачу: посмотреть, как быстро игроки прицеливаются, перескакивают ли они цель или не достают до нее и так далее. Также на этапе прототипирования механики можно использовать специфические задания вроде сортировки карт. Вернемся к примеру с колодой. Перед тем как реализовывать эту механику в коде, дайте игрокам бумажные карты и предложите собрать колоду для определенного героя. Видя, как игроки раскладывают карты по категориям, вы сможете воплотить интуитивную для них систему. Такого рода задачи часто применяют в веб-дизайне при разработке информационной архитектуры сайта (распределение страниц по категориям). В анализе задач участник и исследователь работают один на один. Для объективных результатов, как правило, нужно не менее 15 участников, но, если прототип или механика должны быть сделаны быстро, это может оказаться неоправданно долго, так что ориентируйтесь на свои условия.
• Юзабилити-тест, он же плейтест. Участники играют в определенные отрезки игры (не в игру целиком), а оценке в первую очередь подлежат аспекты юзабилити (впрочем, и вовлекательности тоже). Если какие-то элементы (скажем, туториалы) еще не реализованы, опишите их на бумаге. В таких тестах обычно участвует несколько человек за раз (как правило, около шести, но для многопользовательских игр пять на пять участников может быть больше). И пускай многозадачность – это миф, один контролер вполне способен наблюдать за двумя игроками. Также полезно вести видеосъемку игрового процесса, к которой в случае чего можно будет обратиться позднее.
• Комментированное прохождение – это особый подвид анализа задач или плейтеста, где вы просите участников озвучивать каждое действие и ход мыслей. Оно очень полезно, когда нужно понять первую реакцию на интерфейс, поскольку вскрывает основные ожидания игрока. При использовании этой методики постарайтесь разговорить участников, чтобы им было комфортно. Скажите, что любая их мысль имеет ценность, что выполнить эту задачу неправильно нельзя, что тестируют не их, а программу. Пусть участники тоже задают вопросы – так будет понятно, что сбивает их с толку, – однако упомяните, что вы не всегда сможете ответить, так как должны увидеть, получится ли у них разобраться во всем самостоятельно. Например, можно сказать: «А вы как думаете?» Наконец, если участник замолкает на середине предложения, не договаривайте за него (это исказит ход мыслей), а просто повторите последние слова. Например, если участник говорит «Я не понимаю, как…» и замолкает, просто скажите: «Вы не понимаете, как – что?» Этого обычно достаточно. У данной методики есть существенная особенность: когда человек вынужден мыслить вслух, то сосредоточивается на задаче куда больше, чем если бы был предоставлен сам себе, а потому скорее разберется, как работает та или иная механика. Поэтому важнее учитывать не сам факт того, получилось разобраться или нет, а сколько на это ушло времени. Такие тесты следует проводить индивидуально, как правило, на шести добровольцах.
• Тест-прохождение подразумевает, что игрокам предлагают пройти игру целиком или какой-то ее значимый кусок. Хотя, конечно, наблюдатели будут следить за проблемами с юзабилити, основная задача таких тестов – выявлять проблемы с вовлекательностью (игра слишком легкая, слишком трудная, игроки отвлекаются, игнорируют поставленные цели и т. д.). Для таких тестов нужна, как правило, более крупная выборка, которая охватывала бы как можно больше разных игроков. Кроме того, нужно, чтобы участники имели возможность приходить в лабораторию в течение нескольких дней (а то и недели), и таких людей найти будет непросто. Впрочем, в последнее время все больше распространение получают закрытые бета-тесты (и даже альфа-тесты), в которых может поучаствовать куда больше людей. Но даже в этом случае стоит подыскать хотя бы человек восемь для теста-прохождения – это лучше, чем ничего. Такие тесты прекрасно дополняют аналитические выкладки, поскольку помогают объяснить массовое поведение игроков согласно данным телеметрии (см. главу 15).
В каждой студии эти виды тестов могут называться по-разному. Более того, некоторые разработчики называют «плейтестами» даже те случаи, когда сами играют в игру, чтобы обсудить потом механики. Я согласна с гейм-дизайнером Трейси Фуллертон в том, что правильнее говорить в этом случае о «внутренней оценке дизайна» [Fullerton, 2014], тогда как для всех UX-тестов, описанных выше, нужны сторонние участники, которые ничего об игре не знают (хотя иногда полезно приглашать и тех, кто игру уже видел).
Любые тесты требуют серьезной подготовки. Исследователи, проводящие тест (или ассистенты, например контролеры и аналитики), должны сами поиграть в билд[54] (а значит, он должен быть готов заранее) и подготовить протокол наблюдений, где будут выделены основные потенциальные проблемы. Во время теста также важно удержаться от желания записывать все подряд, а сосредоточиться на конкретных параметрах. Какие-то механики еще могут быть не доделаны, какие-то – забагованы, так что эффективнее обращать внимание только на то, что готово (да и наблюдать за всем сразу попросту невозможно). Более того, разработчиков очень раздражает обратная связь по механикам, которые еще не вполне реализованы (если только они конкретно об этом не попросили). Обратите внимание, что речь не идет о том, чтобы механика была эстетически привлекательна и сбалансирована. Она может быть корявой, полной плейсхолдеров[55], но при этом работающей. Так что пусть разработчики конкретно распишут задачи теста (подробнее см. ниже).
Важно, чтобы разработчики тоже наблюдали за ходом теста – предпочтительно через полупрозрачное зеркало. Так они смогут, оставаясь невидимыми, заглянуть игрокам через плечо и лучше их понять, что способствует формированию ориентации на игрока. Кроме того, когда разработчики наблюдают за тестом все вместе в одном помещении (а не каждый на своем экране), у них неизбежно завязывается разговор о том, почему игроки ведут себя непредсказуемо и что нужно исправить. Это, пожалуй, моя любимая часть UX-тестов: слушать, чего разработчики хотели добиться и что, на их взгляд, игроки делают неправильно. По моему опыту, UX-исту крайне важно наладить доверительные отношения с разработчиками. Кроме того, приглашая их на тесты, вы сможете задать вопросы о задумках и ожиданиях от конкретных механик и систем.
На рис. 14.2 показано устройство UX-лаборатории в Epic Games: помещение, где сидят участники, а наблюдатели в это время следят за игровым процессом через специальные экраны. А еще там видна наша «тайная комната» (та самая), в которой ведущий исследователь и разработчики обсуждают происходящее. Это помещение полностью звукоизолировано, чтобы разработчики могли ругаться в голос: неудивительно, когда то, что, как тебе казалось, должно работать, но на деле не работает.
Во время UX-тестов можно пользоваться различными вспомогательными средствами. Самое важное – это заметки, сделанные наблюдателями. После теста заметки сравнивают и сводят воедино, чтобы ведущий исследователь хорошо представлял, с чем игроки легко справились, с чем испытали трудности, что поняли неверно, а что вообще упустили.
Рис. 14.2. Лаборатория по исследованиям UX в Epic Games. Публикуется с разрешения Билла Грина, © 2014, Epic Games, Inc.
Также полезно делать записи тестовых сессий, чтобы их можно было просмотреть заново и смонтировать для отчета. Тут пригодится бесплатная программа Open Broadcaster Software (OBS), которая позволяет транслировать и записывать потоковое видео с нескольких источников, – например, с экрана компьютера и веб-камеры, направленной на лицо игрока (хотя, как уже упоминалось в главе 7, без мощных инструментов распознавания микровыражений легко ошибиться в выводах).
Отличное средство для повышения качества наблюдений – это айтрекинг[56]. Сейчас есть дешевые окулографические камеры, которые можно подключать напрямую к OBS: тогда наблюдатели в качестве наложенного слоя увидят на своем экране, куда именно смотрят игроки. Правда, не забывайте, что направление взгляда не обязательно совпадает с тем, на чем сосредоточено внимание. Некоторые приложения для айтрекинга позволяют строить тепловые карты, на которых видно зоны, куда больше всего смотрят игроки. Такие карты особенно полезны для неподвижных элементов (например, экранного интерфейса) или коротких отрезков (например, трейлеров). В противном случае затраты (особенно временны´е) часто неоправданны по сравнению с просто внимательным наблюдением.
Далее, в OBS стоит добавить накладку с виртуальным контроллером или клавиатурой (например, NohBoard). Благодаря ей наблюдатели увидят на своем экране, какие клавиши нажимают игроки. Наконец, с помощью приложения Snaz вы можете выводить на видео с OBS локальный таймер, позволяющий более точно рассчитывать, сколько времени уходит у игроков на выполнение той или иной задачи.
Большая часть перечисленных средств (за исключением окулографических камер, отдельных экранов и компьютеров для нескольких участников) бесплатна. Пример того, как выглядит запись UX-теста, показан на рис. 14.3 (это я играю в Fortnite в UX-лаборатории Epic Games, так что ничья приватность не затронута). Если у вас большой бюджет, можете добавить биометрические сканеры: например, измерители электрической активности кожи, замеряющие выделение пота на кончиках пальцев игроков с целью фиксации эмоционального возбуждения (но не его знака – положительного или отрицательного). Впрочем, на данный момент такие приборы не очень практичны: они дороги, а на анализ данных уходит много времени. Поэтому их интересно использовать для коротких сессий или трейлеров. В остальном же лучшим из имеющихся средств было и остается тщательно подготовленное и проведенное наблюдение.
Рис. 14.3. Снимок процесса UX-тестирования в Epic Games. Публикуется с разрешения компании
Ну и последнее средство, о котором я упомяну, – это опросники, периодически рассылаемые участникам. Грамотный опросник эффективнее беседы, потому что создает меньше искажений (ввиду исключения контакта с другим человеком). Подробнее об опросниках и анкетах я расскажу в следующем разделе, но использовать их нужно регулярно в течение тестовой сессии. Включайте в них скриншоты того, с чем игроки только что взаимодействовали, и просите их описать, какие элементы показаны и каковы их функции. Такие опросники покажут, что было понятно, а что – нет.
После того как тест завершен и данные проанализированы, ведущий UX-исследователь готовит отчет, в котором все проблемы классифицируются по типам (интерфейс, обучение, метагейм и т. д.) и серьезности (критические, серьезные и не очень). Серьезность зависит от важности элемента и того, насколько проблема мешала игрокам играть и какую степень раздражения вызвала. Если проблема в кор-геймплее (от англ. core – «основной») или монетизации, степень серьезности может быть выше, даже если игроки в итоге нашли обходной путь. Такие механики должны быть максимально гладкими, иначе нетерпеливые игроки быстро бросят играть – других игр полным-полно.
Отчет должен содержать краткие пояснения по проблемам, а также подробные их описания, предпочтительно сопровождаемые скриншотами или фрагментами видеозаписей. Также должны быть предложены возможные варианты исправления в соответствии с задачами разработчиков. Главное – проследите, чтобы эти рекомендации не звучали назидательно. Плохо, если разработчикам покажется, будто вы хотите сделать игру за них. И вообще, включайте в отчет и позитивные наблюдения тоже! Если тестировался экранный интерфейс, не ограничивайтесь проблемами – укажите, какие элементы интерфейса сработали как надо. И наконец, если в прошлой сборке была выявлена проблема в UX, а теперь она решена, не поленитесь упомянуть и об этом тоже. Очень важно праздновать любые победы, даже небольшие!
14.2.2. Опросы и анкетирование
Опросники можно раздавать во время самого UX-теста, а можно, например, рассылать участникам закрытого бета-тестирования. Анкеты бывают очень полезны, но применять их следует с осторожностью. Нейробиолог Джозеф Леду [1996] отмечал: «Самосозерцание – это взгляд на работу сознания через мутное стекло. С уверенностью можно сказать только одно: мы сами не понимаем, почему чувствуем то, что чувствуем».
Если хотите узнать, что игроки думают о вашей игре, формулируйте вопросы максимально конкретно. Спрашивая, например, показалась ли игра им сложной, интересной или непонятной, обязательно просите объяснить причину. Пусть перечислят в трех пунктах, что им понравилось больше всего, а что совсем не понравилось и почему. Также пусть попытаются описать игру, как будто рассказывают о ней другу. Это поможет респондентам сосредоточиться на конкретных аспектах, а не на абстрактных эмоциях, которые с трудом поддаются описанию.
Старайтесь задавать вопросы максимально объективно, особенно по юзабилити. Вместо того чтобы спрашивать, была ли обучающая миссия понятна, просите пересказать, чему она учила. По поводу интерфейса можно сначала спросить, был ли он понятным и удобным вообще, а затем показать скриншот, на котором отдельные элементы подписаны буквами, – и пусть игрок опишет, что каждый из них делает.
Формулируя вопросы, ограничивайтесь ровно одним пунктом. Не надо спрашивать, скажем, «Была ли эта способность мощной и ясной в использовании?»: как понять, что имел в виду игрок, отвечая «да» или «нет»? Избегайте так называемых наводящих вопросов. Например, вместо «Показалась ли [способность] вам мощной?» спрашивайте «Как бы вы описали [способность]?» и оставьте поле для развернутого ответа. Однако, если опросник рассылается сотням (или того больше!) респондентов, подобными ответами лучше не злоупотреблять (их придется долго анализировать). Лучше предлагать игрокам «шкалу Лайкерта» из семи градаций (или из пяти, если у вас не очень большая выборка или мало нюансов). Например, пусть игрок укажет, насколько согласен с утверждением вроде «Способности в игре давали мне чувство превосходства» (вариантов пять: да; скорее да, чем нет; ни да, ни нет; скорее нет, чем да; нет).
Такие вопросы очень полезны при оценке увлекательности игры и помогают понять, что нуждается в доработке. Ориентируйтесь на кор-геймплей, основной опыт, который должна предлагать игра, а также основы вовлекательности. Спрашивайте игроков, насколько им интересно было достигать тех или иных целей; как они оценивают помощь сокомандников; хотелось ли им помогать другим; видели ли они свой прогресс; было ли комфортно взаимодействовать с интерфейсом; насколько сложной или простой показалось игра; не было ли ощущения, что их ведут за руку; чувствовали ли они, что принимают значимые решения, и так далее. Это поможет определить сильные и слабые стороны игры с точки зрения ее вовлекательности, а затем решить, заняться ли исправлением недостатков или сосредоточиться на доработке достоинств.
Вы можете составить собственный опросник или воспользоваться готовым: например, каталогом игрового опыта [см. Abeele и др., 2016], анкетой игрового вовлечения (можно запросить онлайн на http://www.gamexplab.nl/), опросником по иммерсивности опыта (можно найти онлайн на сайте UCL Interaction Centre; см. тж Jennett и др., 2008) или опросником по удовлетворению потребностей игрока (защищен авторским правом; см. Przybylski и др., 2010). Было проведено исследование, показавшее, что последние три демонстрируют значительную степень сходства результатов [Denisova и др., 2016].
Какой бы тип опросника вы ни выбрали, старайтесь сделать его кратким и пользуйтесь четкими формулировками. Добавьте также полосу прогресса, потому что, как вы знаете, люди любят наблюдать, как растет процент сделанной работы.
14.2.3. Эвристическая оценка
Эвристическую оценку юзабилити и вовлекательности игры проводит специалист по UX (а лучше несколько), исходя из практических правил. Основные перечислены в главах 11 и 12, хотя у профессионалов может быть более обширный список. Отчет по завершению оценки направляется команде разработки.
Этот метод полезен, когда нужно оценить игру в очень сыром состоянии или когда нет возможности проводить UX-тесты. Однако обратите внимание, что выявить большинство проблем без тестов все равно нельзя, так как ничто не может заменить наблюдение за тем, как представители целевой аудитории пытаются разобраться в игре.
14.2.4. Быстрые внутренние тесты
Быстрые внутренние тесты можно проводить вместе с коллегами, которые ничего не знают о конкретной добавленной механике. Это отлично работает с прототипами: вы тестируете очередную итерацию, вносите исправления по своим наблюдениям и отзывам другого разработчика, потом повторяете тест с другим коллегой и так далее. Подробно такой подход был разработан в Microsoft Games Studios [Medlock и др., 2002], где его назвали RITE-метод (от англ. rapid iterative testing and evaluation – «быстрое итеративное тестирование и оценка»). По своей сути он очень похож на анализ задач, только в центре внимания один конкретный аспект игры, и итерации быстро сменяют одна другую. Вы можете привлекать участников извне (это всегда лучше!), хотя данный метод я все же рекомендую применять именно с коллегами, просто потому что поиски посторонних людей для тестов отнимают много времени и потому иногда нецелесообразны. Конечно, нельзя забывать, что разработчики смотрят на игры совсем не так, как игроки, к тому же у них есть личное отношение к автору механики. Однако до тех пор, пока игра не готова к полноценным плейтестам, их фидбэк будет весьма ценен.
14.2.5. Метод персон
Вы придумываете вымышленного игрока – «персону», которая будет олицетворять собой целевую аудиторию. Для этого необходимо объединить нишевый анализ рынка, подготовленный командой маркетинга, с тем опытом и геймплеем, который хочет предложить команда разработки. После этого проводят беседы с представителями примерной аудитории, чтобы узнать их цели, желания и ожидания от разрабатываемой игры данного типа. Итогом становится искусственно созданный персонаж с именем, фотографией, предпочтениями, желаниями и так далее. Такой персоне гораздо легче сопереживать, чем рыночной сводке, к тому же удобнее ориентироваться на конкретного человека, чем на нишу. Процесс создания, кстати, мне даже интереснее, чем итог, поскольку заставляет искать точки соприкосновения между отделами разработки и маркетинга. Если обе эти команды выработают единое представление о пользователе, получится отличное начало для эффективной UX-стратегии на проекте.
Данный метод обычно применяют на стадии задумки или пре-продакшена. Полезно придумать несколько персон: основную – для целевой аудитории, дополнительную – для более широкого охвата, а также анти-персону – для тех, кто вам не подходит. Главное помните, что персона – это не реальный человек, хотя благодаря имени и биографии может таковым казаться. С одной стороны, это хорошо; главное, чтобы игра в итоге не создавалась для кого-то абстрактного. Поэтому я рекомендую сделать все исходные данные персоны доступными, точными и регулярно обновляемыми. Ну и, конечно же, приглашайте разработчиков наблюдать за UX-тестами: пусть смотрят, как в их игру играют реальные люди.
14.2.6. Аналитика
Аналитика – очень мощный инструмент, особенно в сочетании с UX-тестами и опросами. С помощью телеметрии вы удаленно собираете данные о поведении игроков вне лаборатории и не под надзором наблюдателей. Подробнее об аналитике и данных мы поговорим в главе 15.
14.3. Советы по проведению исследований
Какой бы метод вы ни применяли, перед самим исследованием стоит поработать с людьми, которые потом будут читать ваш отчет или пользоваться результатами. Измерить и оценить все невозможно, поэтому сосредоточьте усилия на важном. Спрашивайте у разработчиков, что они хотят узнать для того, чтобы улучшить игру, какие параметры пока в фидбэке не нуждаются, и так далее. Чем активнее они вовлечены в подготовку исследования, тем более полезным будет результат и тем более доверительные отношения вы сможете построить.
Не думайте, что с отправкой отчета ваша работа заканчивается. Проведите совещание с заинтересованными сторонами, чтобы обобщить выявленные проблемы и комментарии по проведенному исследованию. Так вы узнаете, что исправлять не будут, поскольку механику планируется переделать целиком, а какие исправления следует проверить на очередном тесте. Проконтролируйте этот процесс, предложив внести их в базу управления проектами, используемую в студии, чтобы вся команда видела прогресс, ведь ощущение продвижения важно не только для игроков, но и для разработчиков!
Если UX-аналитиков в вашей компании нет и вы не можете организовать специализированную лабораторию, все равно старайтесь регулярно анализировать игру с точки зрения аудитории. Тестируйте задумки, прототипы и ранние сборки на тех, кто ничего о вашей игре не знает (конечно, при условии, что они входят в вашу целевую аудиторию), адаптируя описанные выше методики. Тестировать никогда не рано, а вот упустить промежуток времени, после которого внести изменения уже нельзя, легче легкого! Главное – избавьтесь от максимально возможного числа искажений, иначе они приведут вас к неверным выводам. Постарайтесь не привлекать к тестам друзей и родных, потому что эти люди вас любят и постараются сделать все, чтобы вас не расстраивать. В частности, их отзывы будут гораздо более мягкими.
Сейчас существует немало хороших источников, посвященных вопросам изучения игроков [см., например, Amaya и др., 2008; Laitinen, 2008; Shaffer, 2008; Bernhaupt, 2010]. Также можно связаться с онлайн-сообществом UX-аналитиков (gamesuserresearchsig.org). И не забывайте о принципах юзабилити и вовлекательности: это ваши ориентиры, помогающие понять, что именно в игре работает вопреки расчетам и ожиданиям.