(Перевод статьи "Usability Breakthroughs: Four Techniques To Improve Your Game")

Эрик Прейс (Eric Preisz) директор компании Torque (aka Garagegames) и два доктора наук из исследовательского центра Full Sail представляют 4 метода юзабилити-тестирования, которые помогут сделать вашу игру лучше, даже если в вашем распоряжении нет огромной лаборатории и двух десятков исследователей.

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

Когда дело доходит до проектирования игр с удобным интерфейсом, важно определить не только реакцию целевой аудитории на те или иные фичи, но и то, как к ним отнесутся другие группы пользователей (на языке профессионалов – «хардкорные» игроки и «нубы»).

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

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

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

Заблаговременное проведение юзабилити-тестов может сыграть большую роль в финансовом благополучии проекта – практика показывает, что перерасход бюджета происходит в основном из-за проблем с юзабилити продукта, которые не были обнаружены в процессе разработки. 80% затрат на исправление и поддержку приходятся на исправление непредвиденных проблем с юзабилити.

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

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

1. Мысли вслух

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

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

Позитивные аспекты использования:

• Разработчики получают возможность понять ход мыслей игрока. Методика позволяет определить и задокументировать проблемные для игрока (или нескольких игроков) моменты.
   
• Метод хорошо работает при «поточном» тестировании. Исследования показали, что 75% недочетов в дизайне UI может быть обнаружено небольшой группой испытателей (пяти человек достаточно). Результаты тестирования могут быть получены, обработаны и переданы разработчикам на исправление в течение одного рабочего дня.
   
• Члены команды разработки (программисты, дизайнеры, руководители проектов) могут лично присутствовать на тесте и убедиться в наличии ошибок в игре. Это позволяет сэкономить время на объяснения и помогает разработчикам понять, зачем необходимы те или иные правки. Иногда важно наглядно продемонстрировать, как игрок сталкивается с затруднениями в ситуациях, на которые сами разработчики в жизни не обратили бы внимания.

Сложности, возникающие при использовании техники:

• Обычно у играющих не возникает проблем с комментированием своих действий, но некоторым не удается справиться с этой задачей. «Неразговорчивые» игроки никак не помогут в тестах, и с ними вы просто потеряете время.
   
• «Думать вслух» – непривычно для игрока. В нормальных условиях геймер редко комментирует то, что делает. Вполне возможно, что, пытаясь вербализировать каждый свой шаг в игре, испытуемый начинает озвучивать выдуманные причины своего поведения вместо настоящих.
   
• Некоторым не хватает ума, чтобы ходить и жвачку жевать, не то чтобы играть и параллельно об игре говорить. Часто подопытные скатываются к чему-то одному, что прямо влияет на результаты теста. Вы можете исправить ситуацию, спрашивая игрока, что он делает, в моменты, когда тот замолкает.

 

2. Эвристический анализ

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

Методология. Существует ряд «эвристик», или эмпирических правил, которые четко определяют, из чего состоит «хорошая игра» . Якоб Нильсен опубликовал целый свод «эвристик» для UI программного обеспечения (о них можно прочесть тут), но существуют и альтернативные версии, в том числе адаптированные под игровую разработку.

Одна из таких «эвристик», состоящая из адаптированных практик Нильсена, была разработана Мелиссой Федеров (Melissa Fedefoff ) – их список можно найти на сайте автора. Если ни одна из эвристик не пришлась вам по душе, всегда можно разработать собственную, специально под вашу игру.

Что для этого нужно?

Во-первых, расспросите экспертов гейм-девелопмента, а также игроков (в крайнем случае, разработчиков и бета-тестеров) какие аспекты важны для успеха игры вашего жанра (сюжетная линия, определенные игровые механики, геймплей, и т.п.)

Затем, пока эксперт или геймер играют в игру, попросите другого эксперта проследить за испытуемыми и проанализировать, насколько нагляден и понятен игровой интерфейс, исходя из важных аспектов, которые вы выделили ранее.

Обратите внимание, что отталкиваться необходимо от жанра игры – вам понадобятся разные эвристики для шутера от первого лица (first-person shooter) и для массовой многопользовательской ролевой онлайн-игры (MMORPG)

Пример. Один из пунктов эвристики Нильсена гласит: «Если процесс затягивается более чем на 10 секунд (к примеру, экран загрузки), нужно сделать так, чтобы пользователь получал однозначную информацию о ходе процесса (анимация, прогресс-бар)». Это поможет игроку не только понять, долго ли ждать загрузки игры, но и определить момент, если что-то пойдет не так (системный сбой).

Позитивные аспекты использования:

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

Сложности, возникающие при использовании метода:

• Эвристики сами по себе могут казаться простыми, но их применение требует участия эксперта с наметанным глазом и значительным опытом оценки интерфейсов. Если ваша команда недостаточно опытна – это может стать проблемой.
   
• Использование собственной команды для оценки интерфейса может исказить результаты – в конце концов, они уже имеют представление о том, как игрок «должен» использовать управление и трактовать главный интерфейс игры (HUD). В идеале вам нужен специалист, который разбирается в гейм-девелопменте и юзабилити, но не знаком с вашим игровым проектом.
• Найти подходящего человека не просто. Это вдвойне проблематичнее при разработке собственных эвристик, т.к. вам понадобится больше специалистов для создания в первую очередь своего списка аспектов. Если экспертов нет, выходом для студий, одновременно разрабатывающих несколько игр, может стать вариант, когда разработчики одного игрового проекта становятся юзабилити-тестерами другого, в рамках компании.
   
• Трудно решить, что и по какому принципу включать в список эвристик. К примеру, наличие мини-карты, которая позволяет игроку определить местонахождение своего игрового аватара, кажется очевидным для игр в жанре «шутер от первого лица», но как нам это расценивать? Решается ли этот вопрос ответами «да» и «нет», десятибалльной шкалой Ликерта, или субьективным мнением эксперта? Хуже того, эксперты могут разойтись во мнениях о выборе метода опроса в целом или оспорить какой-то вопрос в частности.
   
• Строгое следование эвристикам может привести к ограничению творчества. Спросите себя, все ли игроки хотят играть в MMORPG с одинаковыми игровыми элементами, механиками и сюжетными линиями?
   

3. Фокус-группы

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

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

Позитивные аспекты использования:

• Несколько голов лучше одной. Фокус-группы способствуют обмену идеями между участниками. В процессе такого обмена могут рождаться новые идеи и мнения, равно как и стратегии дизайна, что ведет к повышению эффективности геймплея, игровых механик и сюжетных линий.
   
• Все отзывы от участников фокус-группы собираются в течение нескольких часов. Метод хорош при «поточном» тестировании, вы можете быстро собрать и обработать данные и уже на следующий день, либо через неделю, провести новую фокус-группу для оценки новых концепций или даже новых прототипов.
   
• Дизайнеры, разработчики и руководители проектов могут непосредственно следить за фокус группой или ознакомится с результатами с помощью видео- и аудиоматериалов. Отзывы игроков, полученные членами команды разработки, могут произвести потрясающий эффект – «Не могу поверить, что они затролили эту особенность геймплея, мы её считали необыкновенно клевой!». Более того, когда дизайнеры, разработчики и руководители лично наблюдают за реакцией аудитории, это снимает всякую необходимость тратить время на анализ и составление докладов.

Сложности, возникающие при использовании метода:

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

4. Наблюдение за игроком в естественных условиях

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

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

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

Позитивные аспекты использования:

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

Сложности, возникающие при использовании метода:

• Иногда исследователь не может определить, почему пользователь произвел то или иное действие, так как он не может прочесть мысли игрока.
   
• Среда, в которой происходит наблюдение, может повлиять на то, как ведут себя игроки. Если одно из условий турнира – победа любой ценой, без заботы о потерях, то данная вводная может крепко изменить стиль игры, в отличие от стандартных условий.
   
• Иногда сложно проследить за тем, что именно и как игрок делает, особенно это относится к мелким деталям в его поведении, будь то выбор иконки или управление ползунком.
   

Подача докладов по юзабилити

Перед тем как передать свой отчет об исследовании юзабилити проекта команде разработчиков, учтите пару вещей, которые помогут вам представить эти данные наилучшим образом. Помните, что каждый элемент игры – это чей-то «ребеночек», и никто не хочет слышать о том, что его «ребенок» урод. Если в своем отчете вы будете излишне критичны по отношению к некой игровой механике, может оказаться, что разработчик, ответственный за решение данной проблемы, не собирается вам содействовать или попросту игнорирует необходимость правок.

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

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

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

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

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

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

К примеру, в рамках юзабилити-исследования, заказанного крупным производителем бытовой техники, запутанное управление холодильником часто приводило к тому, что у пользователей возникали проблемы с диспенсером льда. Инженеры, разрабатывающие диспенсер, скептически отнеслись к докладу и обвинили исследователей в преувеличении проблемы – пока не увидели на видео реакции «живых» потребителей, на которых в процессе использования холодильника валился лед.

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

И, наконец, если вы можете вычислить статистические данные о случаях воспроизведения ошибки – это поможет подчеркнуть важность вопроса. Фраза «40 процентов ваших игроков попыталось зарядить ракетную установку бутылкой воды, когда их попросили найти боеприпасы к оружию» будет иметь большее воздействие, чем «некоторые пользователи путают бутылку воды с боеприпасами для ракетницы».

Вывод

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

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

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

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

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

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

Знания и опыт, из-за которых они являются хорошими разработчиками игр, параллельно делают их отличными от большинства игроков, которые, как правило, думают иначе, чем гейм-девелоперы и не обладают специализированными навыками. Игнорирование проблемы, с которой сталкиваются игроки по причине того, что «пользователи глупы», повредит студии в долгосрочной перспективе, когда игроки начнут предпочитать покупке игры размещение озлобленных комментариев на ваш продукт.

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