В главе 10 я упоминала о заблуждениях, связанных с UX, однако и сами UX-исты не лишены предубеждений по поводу разработки. Хезер Чандлер, старший продюсер Fortnite (Epic Games), рассказывала о них в нашем совместном выступлении на GDC-2016. Например, разработчики игнорируют замечания по UX обычно не потому, что не хотят их слышать, а потому, что и без того нагружены работой, да еще и сроки поджимают. Ввиду этого у них физически нет времени на чтение мучительно длинных отчетов. Им нужна прикладная конкретная обратная связь. Исследователям же порой тяжело жертвовать дотошностью, но нужно идти на уступки. Подготовьте большой подробный отчет, как привыкли, но приложите к нему краткую выжимку, где перечислены пять проблем, требующих немедленного решения.
Также обратная связь должна быть подстроена под цикл разработки. На первый план необходимо выдвигать то, что можно сделать прямо сейчас, в ущерб механикам, которые будут переделываться только через месяц. Главное, когда наступит время, не забудьте достать соответствующие наработки, чтобы в новой итерации не повторялись те же ошибки.
В целях эффективности и чтобы не подвергать команду дополнительному давлению, необходимо грамотно внедрить UX в график разработки. Например, UX-тесты следует планировать загодя на каждую веху проекта, когда обычно готовятся более или менее стабильные сборки, а согласованные после тестов исправления необходимо распределить по ответственным специалистам. Если в студии высокая степень UX-ориентированности, то разработчики сами нацелены на качественный опыт, а не то, чтобы набить в игру как можно больше механик вне зависимости от того, поддерживают они кор-геймплей или нет. В любом случае UX-стратегия и процессы должны подстраиваться под ритм разработки и учитывать ее ограничения.
На разных этапах используются разные инструменты (см. главы 14 и 15). Ниже я даю обзор этих этапов и привожу кое-какие примеры. Главное, учтите, что это не строгие указания, поскольку жестких границ между этапами нет.
На этапе задумки UX-исты могут помочь с созданием персон (см. главу 14) и формулировкой целей разработки для руководства. Все знают, как непросто бывает объяснить основные принципы сложноустроенной игры издателю, который не всегда хорошо разбирается в гейм-дизайне.
UX нужен не только для конечного пользователя; он помогает улучшить коммуникацию внутри студии. Порой UX-исты даже могут помочь разработчикам определиться с тем, какой именно опыт они хотят преподнести игрокам. Например, если нужно вызвать у игрока сочувствие, поставить перед ним моральную дилемму, заставить ощутить себя победителем, то специалисты по UX, основываясь на своем знании психологии, подскажут, на что следует обратить внимание, чтобы этих целей достичь.
На этом этапе проводят много быстрых внутренних тестов для оценки ранних прототипов (бумажных или интерактивных). По мере воплощения механик в коде можно переходить к анализу задач (см. главу 14) и кратким юзабилити-тестам на тренировочных уровнях, чтобы подкорректировать ощущение от игры – в частности, управление, камеру и персонажа (см. главу 12). Параллельно можно тестировать иконографику на соответствие формы и функции и конфигурацию экранного интерфейса (например, посредством опросов).
К концу пре-продакшена полезно составить план всей игры, визуализирующий итоговый опыт «с высоты птичьего полета». Мой бывший коллега по Ubisoft Жан Гесдон, креативный директор франшизы Assassin’s Creed, придумал интересный метод: вы печатаете большой плакат, на котором в общем виде представлены все геймплейные циклы, системы, ключевые механики, цели игрока, его продвижение и так далее. Это поможет команде не терять полную картину, особенно когда они сосредоточены на решении конкретной задачи и не вполне представляют, как она встраивается в проект. Кроме того, подобный плакат облегчит координацию небольших подразделений («ударных групп» в методике Agile[60]), не давая им «замкнуться в себе». Полезен он будет и для тех, кто причастен к проекту, но непосредственно разработкой не занимается: например, для маркетологов и бизнес-аналитиков.
Конечно, общая концепция игры может не раз трансформироваться из-за открытий, сделанных на этапе прототипирования, или при коренной смене курса разработки. Поэтому плакат следует периодически обновлять.
Жан Гесдон, творческий директор в Ubisoft
Философия приближения/отдаления
Пытаясь сформулировать свой подход к дизайну – 10 лет назад, когда я вступил в семью Assassin’s Creed, – я понял, что мою «философию» или, если угодно, «метод» (который, вероятно, разделяют многие) можно определить как бесконечную череду «приближений и отдалений».
Представьте себе вертикальную ось: это континуум от оригинальной задумки до реалистических ограничений. НАВЕРХУ расположен уровень ВИДЕНИЯ, где возможно все и где вы задаете общие цели. Эта оконечность оси – вид сверху, глобальное мышление, идеи и смысл. Здесь вы отвечаете на вопрос «зачем?».
В СЕРЕДИНЕ – уровень ОРГАНИЗАЦИИ, где вы изыскиваете средства для достижения высокоуровневых целей. Здесь все связано с системами и подсистемами, взаимодействием между компонентами, организационными схемами, диаграммами и рационализацией. Здесь же находится ответ на вопрос «как?».
Наконец, ВНИЗУ ось проникает в реальный мир. Это уровень ВОПЛОЩЕНИЯ, где все мечты должны быть вписаны в рамки, иначе не смогут осуществиться.
Сюда относятся планы, списки ассетов, чек-листы, Excel-таблицы и все ограничения, в пределах которых вам приходится творить (технические, юридические, человеческие и т. п.). Здесь вы отвечаете на вопрос «что?».
И главное: перемещаться по этой оси нужно максимально быстро и плавно. Чем лучше у вас получается сочетать дерзкие мечты с приземленным рационализмом, тем вероятнее у вас получится реализовать обещанное. На это в той или иной степени способен каждый, но, думаю, чем быстрее вам удается скользить по данной оси, тем легче вам будет создавать что угодно.
На этом этапе UX-тесты идут полным ходом. Поначалу главный акцент делается на юзабилити и ощущении от игры, но по мере того как механики начинают обретать форму и цепляться друг за друга, следует переключиться на вовлекательность. Ближе к концу также нужно будет определиться с гипотезами и вопросами для анализа (как геймплейного, так и коммерческого), чтобы внедрить и протестировать соответствующие флаги телеметрии.
Как только все механики реализованы (а лучше – и перед этим), полезными становятся тесты-прохождения, показывающие, как игроки продвигаются в игре и где наблюдается падение интереса. Результаты этих тестов помогают добавить недостающие телеметрические флаги. С этого момента также большую роль начинают играть интересы маркетологов и издателей, поэтому должна быть готова и отлажена процедура сбора статистики.
Как только игра попадает к реальным игрокам, за которыми нельзя наблюдать из-за плеча, пора переходить к сбору и анализу статистики, опираясь на результаты UX-тестов. Основной упор делается на балансировку сложности и прогресса, монетизацию и т. п. – при условии, что самые серьезные проблемы UX, выявленные на предыдущих этапах, уже решены (хотя такое бывает редко).
Наблюдать за успехами игры на этапе бета-тестирования или релиза очень волнительно. Без продуманных гипотез есть риск запаниковать и принимать решения импульсивно, во вред пользовательскому опыту и прибыли. Быстро реагировать, конечно, важно, но скоропалительные выводы могут в итоге стоить вам больше времени (и денег), чем вдумчивый анализ всех релевантных факторов. Помните, что прежде всего необходимо выявить проблемы, которые на самом деле нуждаются в решении.