UX-ориентированность включает в себя не только стремление дать игрокам насыщенный опыт, но и хорошие бизнес-практики [Hartson, Pyla, 2012]. Благодаря им вы сможете выпустить игру с меньшим количеством проблемных пунктов и более увлекательную, а значит, имеющую больше шансов охватить широкую аудиторию и принести прибыль. Кроме того, не забывайте: чем раньше выявлены проблемы, тем дешевле их исправить. Таким образом, опыт пользователя должен стать основой стратегии проекта как на всех этапах разработки, так и на уровне студии.
Создание отличного пользовательского опыта требует скоординированных усилий всей команды. UX – это не только графика, дизайн, программирование, задумки и реализация; это не только маркетинг, определяющий целевую аудиторию; это не только BI, выбирающий стратегию монетизации; и это не только руководство, задающее коммерческие цели и продвигающее корпоративные ценности. UX – это все вместе. Пользовательский опыт должен объединять эти направления и живо заботить всех сотрудников студии. В конце концов, главное ведь то, как аудитория примет ваши игры, продукты и услуги. Восприятие, понимание, поведение и эмоции ваших игроков – вот что важно. Именно поэтому просто наличие в студии самостоятельного UX-отдела (пусть это и неплохое добавление для начала) едва ли принесет ощутимую пользу. UX-исты могут давать бесценные советы и инструменты, но самим подходом ради достижения общей цели должны пользоваться все.
16.1. UX на уровне команды разработчиков
UX-ориентированность помогает команде разработчиков сосредоточиться на том, что важно как для опыта игроков, так и для финансового благополучия студии. Скажем, нельзя разрабатывать free-to-play игру так же, как разрабатывают платные игры. Точно так же, если проект заточен под командную игру, то PvP-режим явно не так важен. Разработка игры включает в себя необходимость делать выбор и идти на компромиссы. Но чтобы ваши тактические решения были осмысленными и соответствовали поставленным целям, необходимо помнить, какой опыт вы хотите предложить пользователям.
Например, издатель может потребовать добавления механики сезонных акций, которые должны способствовать монетизации. В то же время UX-аналитики бьют тревогу по критическим проблемам, которые могут навредить удержанию игроков. Да и разработчики, по моему опыту, наверняка тоже хотят перед дедлайном реализовать как можно больше всего. Однако времени мало, а значит, добавить, исправить или реализовать получится лишь что-то одно. Чему вы отдадите предпочтение?
Универсального ответа нет, однако, думаю, этот пример показывает, почему так нужна общая для всей студии UX-стратегия. Все должны понимать, что приобретается, а что теряется, уметь расставлять задачи по приоритету в зависимости от воздействия на пользовательский опыт и извлекать максимум из каждого решения.
Стоит также отметить, что для создания игр часто используются специальные инструменты и среды, разработанные внутри студии. А значит, важно учитывать и пользовательский опыт самих разработчиков, чтобы их работа с этими инструментами была не только эффективной, но и максимально комфортной (а еще лучше – приятной) [см. Lightbown, 2015]. Если инструменты неудобны в использовании, теряется много драгоценного времени, так что проследите, чтобы те, кто создает обеспечение для разработчиков, тоже разбирались в UX.
16.2. UX в процессе разработки
В главе 10 я упоминала о заблуждениях, связанных с UX, однако и сами UX-исты не лишены предубеждений по поводу разработки. Хезер Чандлер, старший продюсер Fortnite (Epic Games), рассказывала о них в нашем совместном выступлении на GDC-2016. Например, разработчики игнорируют замечания по UX обычно не потому, что не хотят их слышать, а потому, что и без того нагружены работой, да еще и сроки поджимают. Ввиду этого у них физически нет времени на чтение мучительно длинных отчетов. Им нужна прикладная конкретная обратная связь. Исследователям же порой тяжело жертвовать дотошностью, но нужно идти на уступки. Подготовьте большой подробный отчет, как привыкли, но приложите к нему краткую выжимку, где перечислены пять проблем, требующих немедленного решения.
Также обратная связь должна быть подстроена под цикл разработки. На первый план необходимо выдвигать то, что можно сделать прямо сейчас, в ущерб механикам, которые будут переделываться только через месяц. Главное, когда наступит время, не забудьте достать соответствующие наработки, чтобы в новой итерации не повторялись те же ошибки.
В целях эффективности и чтобы не подвергать команду дополнительному давлению, необходимо грамотно внедрить UX в график разработки. Например, UX-тесты следует планировать загодя на каждую веху проекта, когда обычно готовятся более или менее стабильные сборки, а согласованные после тестов исправления необходимо распределить по ответственным специалистам. Если в студии высокая степень UX-ориентированности, то разработчики сами нацелены на качественный опыт, а не то, чтобы набить в игру как можно больше механик вне зависимости от того, поддерживают они кор-геймплей или нет. В любом случае UX-стратегия и процессы должны подстраиваться под ритм разработки и учитывать ее ограничения.
На разных этапах используются разные инструменты (см. главы 14 и 15). Ниже я даю обзор этих этапов и привожу кое-какие примеры. Главное, учтите, что это не строгие указания, поскольку жестких границ между этапами нет.
16.2.1. Задумка
На этапе задумки UX-исты могут помочь с созданием персон (см. главу 14) и формулировкой целей разработки для руководства. Все знают, как непросто бывает объяснить основные принципы сложноустроенной игры издателю, который не всегда хорошо разбирается в гейм-дизайне.
UX нужен не только для конечного пользователя; он помогает улучшить коммуникацию внутри студии. Порой UX-исты даже могут помочь разработчикам определиться с тем, какой именно опыт они хотят преподнести игрокам. Например, если нужно вызвать у игрока сочувствие, поставить перед ним моральную дилемму, заставить ощутить себя победителем, то специалисты по UX, основываясь на своем знании психологии, подскажут, на что следует обратить внимание, чтобы этих целей достичь.
16.2.2. Пре-продакшен
На этом этапе проводят много быстрых внутренних тестов для оценки ранних прототипов (бумажных или интерактивных). По мере воплощения механик в коде можно переходить к анализу задач (см. главу 14) и кратким юзабилити-тестам на тренировочных уровнях, чтобы подкорректировать ощущение от игры – в частности, управление, камеру и персонажа (см. главу 12). Параллельно можно тестировать иконографику на соответствие формы и функции и конфигурацию экранного интерфейса (например, посредством опросов).
К концу пре-продакшена полезно составить план всей игры, визуализирующий итоговый опыт «с высоты птичьего полета». Мой бывший коллега по Ubisoft Жан Гесдон, креативный директор франшизы Assassin’s Creed, придумал интересный метод: вы печатаете большой плакат, на котором в общем виде представлены все геймплейные циклы, системы, ключевые механики, цели игрока, его продвижение и так далее. Это поможет команде не терять полную картину, особенно когда они сосредоточены на решении конкретной задачи и не вполне представляют, как она встраивается в проект. Кроме того, подобный плакат облегчит координацию небольших подразделений («ударных групп» в методике Agile[60]), не давая им «замкнуться в себе». Полезен он будет и для тех, кто причастен к проекту, но непосредственно разработкой не занимается: например, для маркетологов и бизнес-аналитиков.
Конечно, общая концепция игры может не раз трансформироваться из-за открытий, сделанных на этапе прототипирования, или при коренной смене курса разработки. Поэтому плакат следует периодически обновлять.
Жан Гесдон, творческий директор в Ubisoft
Философия приближения/отдаления
Пытаясь сформулировать свой подход к дизайну – 10 лет назад, когда я вступил в семью Assassin’s Creed, – я понял, что мою «философию» или, если угодно, «метод» (который, вероятно, разделяют многие) можно определить как бесконечную череду «приближений и отдалений».
Представьте себе вертикальную ось: это континуум от оригинальной задумки до реалистических ограничений. НАВЕРХУ расположен уровень ВИДЕНИЯ, где возможно все и где вы задаете общие цели. Эта оконечность оси – вид сверху, глобальное мышление, идеи и смысл. Здесь вы отвечаете на вопрос «зачем?».
В СЕРЕДИНЕ – уровень ОРГАНИЗАЦИИ, где вы изыскиваете средства для достижения высокоуровневых целей. Здесь все связано с системами и подсистемами, взаимодействием между компонентами, организационными схемами, диаграммами и рационализацией. Здесь же находится ответ на вопрос «как?».
Наконец, ВНИЗУ ось проникает в реальный мир. Это уровень ВОПЛОЩЕНИЯ, где все мечты должны быть вписаны в рамки, иначе не смогут осуществиться.
Сюда относятся планы, списки ассетов, чек-листы, Excel-таблицы и все ограничения, в пределах которых вам приходится творить (технические, юридические, человеческие и т. п.). Здесь вы отвечаете на вопрос «что?».
И главное: перемещаться по этой оси нужно максимально быстро и плавно. Чем лучше у вас получается сочетать дерзкие мечты с приземленным рационализмом, тем вероятнее у вас получится реализовать обещанное. На это в той или иной степени способен каждый, но, думаю, чем быстрее вам удается скользить по данной оси, тем легче вам будет создавать что угодно.
16.2.3. Разработка
На этом этапе UX-тесты идут полным ходом. Поначалу главный акцент делается на юзабилити и ощущении от игры, но по мере того как механики начинают обретать форму и цепляться друг за друга, следует переключиться на вовлекательность. Ближе к концу также нужно будет определиться с гипотезами и вопросами для анализа (как геймплейного, так и коммерческого), чтобы внедрить и протестировать соответствующие флаги телеметрии.
16.2.4. Альфа-тестирование
Как только все механики реализованы (а лучше – и перед этим), полезными становятся тесты-прохождения, показывающие, как игроки продвигаются в игре и где наблюдается падение интереса. Результаты этих тестов помогают добавить недостающие телеметрические флаги. С этого момента также большую роль начинают играть интересы маркетологов и издателей, поэтому должна быть готова и отлажена процедура сбора статистики.
16.2.5. Бета-тестирование/релиз
Как только игра попадает к реальным игрокам, за которыми нельзя наблюдать из-за плеча, пора переходить к сбору и анализу статистики, опираясь на результаты UX-тестов. Основной упор делается на балансировку сложности и прогресса, монетизацию и т. п. – при условии, что самые серьезные проблемы UX, выявленные на предыдущих этапах, уже решены (хотя такое бывает редко).
Наблюдать за успехами игры на этапе бета-тестирования или релиза очень волнительно. Без продуманных гипотез есть риск запаниковать и принимать решения импульсивно, во вред пользовательскому опыту и прибыли. Быстро реагировать, конечно, важно, но скоропалительные выводы могут в итоге стоить вам больше времени (и денег), чем вдумчивый анализ всех релевантных факторов. Помните, что прежде всего необходимо выявить проблемы, которые на самом деле нуждаются в решении.
16.3. UX на уровне студии
Чтобы сделать студию UX-ориентированной и направленной на игрока, руководству необходимо признать важность пользовательского опыта в разработке, понять возможности и ограничения этой дисциплины. Убедить менеджеров в том, что такой подход позволит студии выпускать увлекательные и более прибыльные игры, может быть непросто.
Внутри команды всегда есть разработчики, заинтересованные в UX и готовые к экспериментам. После нескольких небольших побед, демонстрирующих пользу UX-практик (что благодаря итеративному подходу может произойти быстро), доверие обычно возрастает. А вот менеджеры видят преимущества только после релиза, когда собрана статистика и когда проблемы в UX очевидно связаны с падением удержания и прибыли. Впрочем, даже в этом случае доказать свою правоту UX-исту будет непросто.
Вы можете попробовать просчитать норму доходности от UX, но успех не гарантирован. Убедить других в правильности UX-ориентированного подхода – это долгий путь, на котором нужно придерживаться научного метода и давать непредвзятые выводы исходя из данных и когнитивной науки.
UX-зрелость студии требует времени. Якоб Нильсен [2006] выделяет восемь этапов, через которые проходит организация: от отторжения юзабилити (первый этап) до UX-ориентированной корпорации (восьмой этап). Нильсен предполагает, что на достижение седьмого этапа, когда UX интегрирован во все процессы и производится контроль качества предоставляемого опыта, у компании уходит около 20 лет. А переход с седьмого этапа на восьмой занимает еще 20 лет.
Модель UX-зрелости, на которую опираюсь я, – это «модель зрелости Keikendo», описанная специалистом по UX Хуаном Мануэлем Карраро [2014] по итогам более чем десяти лет работы в разных организациях (см. рис. 16.1). Эта модель – наглядная визуализация различных стадий зрелости. Ее удобно использовать в обсуждениях UX-стратегии с высшим руководством, так как она демонстрирует преимущества каждого уровня, а также препятствия и способы их преодоления.
Модель зрелости Keikendo включает в себя пять уровней.
• Неосознанный
О пользовательском опыте задумываются только из необходимости. Главное препятствие – это незнание о UX или его отторжение (вероятно, из-за заблуждений; см. главу 10). Способы преодоления – просвещение сотрудников, активные попытки объяснить, что такое UX (и чем он не является).
Рис. 16.1. Схема модели зрелости Keikendo
• Самоцентрированный
Пользовательский опыт учитывается, но разработчики все меряют по себе, как если бы их поведение и образ мышления совпадали с пользовательскими. Осознания, что ментальная модель игрока отличается, нет. Основные препятствия: нехватка времени, средств и ресурсов. Главный способ продвижения – изучение пользователей (отдельно добавлю, что предпочтительнее проводить исследования на небольших проектах или задачах, чтобы быстро продемонстрировать преимущества).
• Экспертный
Есть отдельная группа UX-истов или один ведущий специалист. На этом уровне процессы еще недостаточно отлажены и в цикл разработки полноценно не внедрены. Основной способ продвижения – квантифицировать изучение пользователей и регулярно сравнивать проекты, включающие UX-тесты, с проектами без них, чтобы продемонстрировать преимущества подхода.
• Централизованный
UX представлен разными специалистами: дизайнерами интерактивности, дизайнерами информационной архитектуры, UX-аналитиками, не ограниченными рамками одной команды. На этом уровне изучение пользователей выделяют в самостоятельный этап разработки, однако проблема масштабируемости остается. На UX-ориентированность выделяется еще недостаточно ресурсов и специалистов. Пока это полезная внутренняя функция, но не стратегическая область со своим бюджетом, такая как разработка или маркетинг. Главный способ продвижения – соотнесение UX-метрик с KPI (например, демонстрация связи между проблемами в UX и падением удержания игроков).
• Распределенный
UX стоит на одной ступени с финансами, разработкой и маркетингом. Высшее руководство одобряет выделение UX в качестве самостоятельной стратегической области внутри организации.
Первые уровни в контексте игровой индустрии преодолеваются довольно быстро: небольшие победы, приносящие пользу разработчикам, создают доверие. Однако последние два уровня – особенно самый последний – покорить гораздо труднее. В своем выступлении на саммите по игровому UX Дон Норман высказал мысль [Norman, 2016], что за UX должен отвечать самостоятельный руководитель. Для этого и топ-менеджеры должны пересмотреть свои взгляды, и руководители UX-направления должны быть готовы взять на себя ответственность. До этого, конечно, еще далеко, однако позиции UX в игровой индустрии значительно укрепились. Нашу дисциплину наконец начали воспринимать всерьез.
Если вы «одинокий гордый UX-ист» и хотите сформировать в студии UX-процессы, поделюсь советом из собственного сольного опыта: перед тем как что-то внедрять, прислушайтесь к проблемам, трудностям и задачам, которые должны решать разработчики. Объясните им, в чем суть UX, развейте заблуждения, продемонстрируйте когнитивные ограничения (например, покажите видео с баскетболистами и гориллой, упомянутое в главе 5). Дайте понять, что вы не собираетесь придумывать игру за них, а просто помогаете достичь поставленных целей рекомендациями, основанными на науке. Вводите концепции UX легко и не ведите себя как «полиция юзабилити», сдавая нерадивых разработчиков руководству. Нет, вы с ними по одну сторону баррикад, так что доказывайте свою полезность (например, протестируйте иконки и обозначьте проблемы с юзабилити, чтобы дизайнер интерфейса в новой версии их исправил) и отмечайте все достижения в области UX, даже самые небольшие.
Как только разработчики заинтересуются изучением пользователей, вам будет проще добиться разрешения на специальное пространство для тестов и наблюдений. Впоследствии, возможно, вам даже удастся выбить бюджет на оборудование целой UX-лаборатории с полупрозрачными зеркалами, чтобы разработчики тоже могли присутствовать на тестах и обсуждать их в прямом эфире. Тогда же можно начать убеждать высшее руководство в том, что наем новых UX-дизайнеров повысит эффективность разработки.
Когда число запросов на UX-тесты вырастет, вам легче будет протолкнуть создание отдельной команды. После этого вы сможете начать планировать UX-процессы. По мере их интеграции в работу студии координируйтесь с другими сотрудниками, ориентированными на пользовательский опыт, например с аналитиками, и постепенно наладьте коммуникацию во всей компании.
Ну и последний шаг – это получить право голоса за столом руководства и пользоваться этим правом на благо игроков.
За UX стоит серьезная наука, но это не значит, что ваше направление должно быть унылым. Будьте проще, и люди к вам потянутся! Во-первых, так просто-напросто веселее, а во-вторых, другие сотрудники скорее прислушаются, когда увидят, что вы здесь не только за тем, чтобы их критиковать (образно говоря).
Например, когда в Epic Games была создана UX-лаборатория, наша команда решила устраивать в «тайной комнате» вечерние посиделки. Мы приглашали туда и разработчиков – просто послушать музыку и выпить пива. Поскольку находиться в UX-лаборатории не всегда приятно (особенно когда смотришь, как игроки мучаются с интерфейсом), мы попытались создать ассоциацию, что это еще и веселое пространство, где можно говорить не только о проблемах. Я думаю, это важно (впрочем, может быть, я просто очень люблю вечеринки!).
И последнее, что помогло мне в коммуникации с разработчиками: я постоянно спрашивала, для чего целевой аудитории новая фича, акция, маркетинговая компания или распродажа [см. Sinek, 2009]. Например, если команда хочет добавить механику (которая, вероятно, отнимет время и усилия у исправления других проблем в UX), спросите, а нужна ли она игрокам. Если руководство требует ввести в игру новый режим, спросите, будет ли он интересен игрокам и впишется ли в общий опыт. И так далее в том же духе.
Игровая разработка – это принятие компромиссных решений в условиях неопределенности. За каждым отдельным выбором легко потерять из виду конечную цель. Конечно, цели порой приходится пересматривать, да и общая стратегия игры по ходу разработки может (и, скорее всего, будет) меняться. Однако если гнаться за несколькими зайцами сразу, то наверняка получится посредственный продукт, не дающий глубокого опыта ни на каком уровне. Поэтому перед принятием радикальных решений крайне важно вспомнить, а зачем целевая аудитория, собственно, будет играть в вашу игру. Не забывайте, что время, бюджет и технические возможности ограничены.
Этот вопрос – «зачем?» – позволит ориентировать мыслительный и итеративный процесс на игрока, что очень важно для осмысленности, мотивации и вовлечения (см. главу 12). Ориентация на игрока также важна для маркетинга: согласитесь, рекламировать доступные в игре действия (например, перестрелки, исследование, крафт и т. п.) не так интересно, как осмысленные цели (например, захватить мир, стать преступным гением, спасти королевство и т. п.). Неслучайно я начала книгу не с рассказов о том, что такое пользовательский опыт, а с попытки объяснить, почему он важен.
Самое важное для формирования UX-зрелости в компании – заручиться доверием сначала команды разработчиков, а затем и всех остальных. В своей книге «Корпорация гениев. Как управлять командой творческих людей»[61] Эд Кэтмелл рассказывает, что в Pixar есть специальное подразделение, которое собирается каждые несколько месяцев для оценки лент в разработке [Catmull, Wallace, 2014]. И хотя творческий процесс в Pixar отличается от того, что принят в видеоигровой индустрии, этот кейс все равно интересен с точки зрения UX-стратегии. Например, группа сотрудников, выступающих за проработку пользовательского опыта, может периодически собираться и оценивать игры студии (как выпущенные, так и разрабатываемые в данный момент).
Для UX-стратегии также важно сформулировать четкое креативное видение студии и определить его связь с пользовательским опытом. В заключительном эссе этой главы Серж Хаско, креативный директор Ubisoft, рассказывает о важности простоты в дизайне.
В любом случае главная задача UX-менеджеров – поддерживать усилия разработчиков и помогать студии в достижении коммерческих целей. Если они будут в нужное время давать нужные инструменты нужным людям, тем самым демонстрируя пользу UX-ориентированности, к ним в конечном счете прислушаются.
Серж Хаско, креативный директор Ubisoft
«Труднее всего на свете простота», – Леонардо да Винчи
Давным-давно кнопок у игровых контроллеров не было вовсе. Потом появилась одна, затем две, три… на современном геймпаде их уже двадцать одна. Человеку отлично удается создавать эффективные инструменты, позволяющие творить чудеса. Увы, он не менее искусен в усложнении этих инструментов.
Почему так происходит? Творческие пути неисповедимы. Мы порой принимаем сложность за новаторство. Вместо того чтобы делать имеющиеся инструменты более универсальными, мы создаем новые, узкоспециализированные. Мы бездумно добавляем действия и кнопки, считая себя гениями инновации, а между тем кнопок уже не хватает! Приходится делать так, чтобы одна кнопка отвечала сразу за несколько действий: для первого ее нужно нажать, а для второго – зажать. Чтобы объяснить эти неинтуитивные правила, мы вынуждены писать туториалы, что, в свою очередь, перегружает кривую обучения и может в конечном счете отвадить игроков от игры.
Многие считают, что игры слишком сложны, и это правда. Стоило нам вернуться к более простым интерфейсам и более естественным схемам управления, как происходил массовый приток игроков: вспомните появление Wii Remote, сенсорных экранов и Minecraft.
Я считаю, что стремиться к простоте разумно с точки зрения не только аппаратного, но и программного интерфейса. Необходимо четкое видение, в центре которого стоит пользователь. Именно оно должно лежать в основе творческого процесса. Чем точно нельзя поступаться, так это простотой использования и понимания. Сейчас мы стоим на пороге эры виртуальной реальности, в которой естественные движения наших тел, рук, головы, а вскоре и пальцев откроют нам невероятный опыт.