ТехноLive: Игрок и игра, интерфейс как связующее звено, Ольга Шуберт
Мы продолжаем публиковать расшифровки наших трансляций о разработке игр. Как сделать игровой опыт максимально комфортным? Об этом расскажет UX/UI-дизайнер Игрового направления Mail.Ru Group Ольга Шуберт, которая обладает девятилетним опытом разработки интерфейсов и игровых механик.
Прошлые выпуски:
- Как продвигать свою игру среди тысяч конкурентов, Максим Самойленко
- Как создать успешную мобильную игру, Иван Федянин
- История игровой индустрии, Александр Кузьменко
Видеозапись: https://youtu.be/dcmVUIOfy-A
Александр Кузьменко: Добрый вечер, уважаемые зрители. В эфире «Технострим» и сегодня у нас заключительная часть нашей серии по видеоиграм. Сегодня у нас последний гость, но далеко не последний по важности, связанный с разработкой электронных игр — сегодня у нас в гостях Ольга Шуберт, специалист в UX-проектировании игровых проектов компании Mail.Ru Group. Извините, у нас у всех очень длинные должности. Ольга — самый главный человек в нашей компании, который разбирается в UX относительно к играм. Привет.
Ольга Шуберт: Привет!
А.К.: Слушай, UX — это нечто новое в игровой индустрии. Обычно начинают от сохи:»30 лет назад в Японии появилась индустрия видеоигр». Понятное дело, что UX тогда не существовало. У нас стримы с человечным подходом. То есть, мы не начинаем сразу сыпать технологическими терминами и так далее. Очень много людей, причем не только среди наших зрителей, но и среди просто людей или сотрудников нашей компании, которые любят игры, даже не знают, что такое UX. Ты можешь в двух словах сказать, что это такое?
О.Ш.: Да, мне первым делом задают такой вопрос, когда я пытаюсь объяснить, кем я вообще работаю. Обычно говорят: «А, ты программист, наверное». Я говорю: «Нет» — «Но ты же компьютерщик». Я говорю: «Нет».
А.К.: Сантехник по железу.
О.Ш.: Да, примерно что-то такое. На самом деле, пока расскажу небольшую предысторию о том, как я вообще пришла в игровую индустрию. Как UX появился в моей жизни и потом плавно перейду к ответу на вопрос, если ты не против.
А.К.: Это было как раз моим вторым вопросом. Отлично. Я обожаю таких гостей, которым даже вопросы можно не задавать.
О.Ш.: Да. Я пришла в игровую индустрию 9 лет назад. Тогда на российском рынке было очень много игр, и тогда только-только появилась браузерная игра «Легенды наследия драконов».
Я вообще не геймер, но кто-то случайно мне ее показал. Я так: «Что-что? Подождите». И меня она страшно зацепила. И так все пошло-поехало. Я стала играть, активничать на форуме и принимать живое участие в какой-то игровой социальной жизни. Я еще не работала здесь, но уже меня тянуло анализировать происходящее. Игровой рынок тянул меня в эту сторону.
А.К.: Получается необычное явление. Обычно мальчики любят раскрывать мишку, чтобы посмотреть, как он устроен. И паровозик разбирают.
О.Ш.: Да. Тут я, как мальчик, решила разобрать, и с этого все и началось. Какой-то игрок написал какие-то квесты на форум и предложил их разработчикам, как это обычно водится: «Сейчас я вам расскажу, как тут надо». И я написала здоровущую разгромную статью по этому поводу, что «Все у тебя здесь неправильно, все не так, все работает не так». К этому времени я уже тянулась сюда, написала письмо на свободную вакансию, что хочу работать писателем. Пришла писателем-редактором. К этому времени на форуме появляется разгромная статья, и во мне просыпается раскурочиватель мишек. С тех пор чем только я ни занималась. Путь мой был долог и тернист. Я занималась и разработкой квестов, и большими игровыми сценариями, и просто гейм-дизайном, администратором, продюсированием.
А.К.: Я как раз хотел сказать, что перебрав все профессии в игровой индустрии, можно становиться продюсером. Теперь ты умеешь все.
О.Ш.: Да. Потом я стала продюсером браузерной игры «Территория».
Потом мы занимались оперированием. В общем, много чем занимались. И на протяжении этого пути я все еще тянулась к раскурочиванию мишек. Та-дам! Мне все еще хотелось понять суть вещей. И в это же время вместе со мной, как нельзя более удачно, стало развиваться UX-проектирование в играх. И я к этому прикоснулась довольно плотно несколько лет назад, когда стала заниматься разработкой мобильных игр. Поняла, что пора. Теперь плавно перехожу к вопросу, что же такое UX.
А.К.: Что же такое UX?
О.Ш.: Очень часто UX путают с UI. Считают, что это все связано с разработкой интерфейса как такового. На самом деле, все обстоит не так. UX — это сокращение от user experience. Если переводить на русский язык, то получится, что это изучение пользовательского опыта. То есть это разработка, которая построена на поведении пользователя, на его ожидании, на понимании этих ожиданий и на попытку соответствовать этим ожиданиям.
А.К.: А UI — это user interface, это разработка непосредственно интерфейса.
О.Ш.: Все так и есть. Стали разбираться, копаться. На самом деле, когда в наших продуктах разрабатывались интерфейсы, то они придумывались разными гейм-дизайнерами. Так уж получалось. Каждый гейм-дизайнер, пытался как-то визуализировать свои идеи, кто на что горазди. В результате что-то доходило до конечного пользователя. Но когда мы сравнивали наши продукты с топовыми зарубежными конкурентами, то качество уходило в пользу конкурентов.
А.К.: Тогда уже были какие-то критерии сравнения? Или сравнивали так: понравилось, нет?
О.Ш.: Ну, не столько понравилось… Ведь мы же говорим о пользовательском опыте. Поиграли в наше, поиграли в чужое, и стало очевидно, что тут вкуснее, здесь удобнее, здесь информативнее, здесь ничего нет лишнего. А у нас все еще какие-то устаревшие решения, взятые из браузерных игр. Конечно, анализировали это со всех точек зрения. Смотрели, как юзеры играют в наши и зарубежные продукты. И постепенно приходили к тому, что нужно выработать иную концепцию разработки. И, как выяснилось, этим уже занимаются наши зарубежные коллеги. В общем, стали изучать.
Оказалось, что в России этим почти никто не занимается. У нас есть UX-лаборатории, совершенно потрясающие технологии, которые позволяют исследовать пользователя и его реакцию на происходящее. Но не каждый разработчик может себе это позволить, и не в каждую разработку можно это правильно внедрить.
UX-проектирование предполагает итерационный подход к разработке. Что это значит? Тут хочется прояснить. Когда мы создаем продукт, то мы ориентируемся на его образ для конечного потребителя. На то, как эта сухая изначально идея, гейм-дизайнера, математика (который там занимается балансом), художников, будет соответствовать нашим ожиданиям. Как она будет решать какие-то наши бизнес-задачи, и как пользователь будет решать свои задачи, чтобы получить от этого удовольствие.
А.К.: А нет ли в этом вечного противоречия? Зачастую, ты знаешь, как это бывает. Давай начнем с великих, например, Facebook. Все мы прекрасно знаем, что справа колонка нужна для того, чтобы пролистывая на iPad, ты тыкал постоянно пальцем в эту рекламу. Это бизнес-задача или это просто неправильно спроектированный интерфейс? Извини, что я тебя перебью. Ты очень интересно рассказываешь, но я периодически буду оживлять наш диалог какими-то вопросами, потому что Олю очень тяжело остановить, и у нее очень классные истории. И, кстати, я подсказываю, что у нас во время стрима идет чатик. Пожалуйста, используйте это не как место для выяснения, какой UX лучше, какие подходы, а для того, чтобы нашей замечательной гостье задавать вопросы.
Итак, Оль, я тебя перебил.
О.Ш.: Да, спасибо.
А.К.: Извини. У тебя такой классный монолог, что я теперь помолчу еще минут 15.
О.Ш.: Я могу рассказывать долго. Хочу сказать, что каждый разработчик принимает какие-то соответствующие решения в ту или иную сторону. Иногда он перетащит, чтобы себе было удобно, иногда по-другому. Но, как правило, все это происходит на стыке. UX-проектирование нужно для того, чтобы связать задачу разработчика и задачу пользователя. Это как раз золотая середина, которую нужно найти. По сути, интерфейс — это способ взаимодействия между разработчиком и конечным пользователем.
А.К.: Это очевидно.
О.Ш.: Но тут надо сказать, что тут очень часто путают подходы к разработке интерфейсов как таковых, разработке usability. Буквально недавно мы общались с одной из наших команд, и выяснилось, что разрабатывается какая-то гейм-дизайнерская идея, на основе нее гейм-дизайнер, а может быть, главный дизайнер команды формирует какой-то очень условный прототип, некую «рыбу». Дальше эта «рыба» отправляется к дизайнеру, он не понимает изначальную задачу, которую ставил перед собой гейм-дизайнер (автор этой какой-то макрофичи). Так до конечного пользователя доходит совсем не то что задумывалось. И это как раз то, что не решает задачи ни разработчика, ни пользователя.
Вот почему очень важно чувствовать разницу между UX и UI.
А.К.: Когда мы говорили про разницу UX и UI, то тут появлялось несколько вопросов сразу. Из чатика я зачитываю всякие провокационные вопросы или образовательные. Вот тут пишут, что зачем морочиться над разработкой интерфейса (в проектах не каких-то мега-инновационных), когда его можно, цитирую, «спереть у более успешных разработчиков»?
О.Ш.: Спереть можно. Безусловно, research — очень важная штука. И я бы даже сказала, что очень вредно изобретать велосипеды.
А.К.: Не украл, а вдохновился.
О.Ш.: Совершенно верно. Очень вредно изобретать велосипеды, и тратить ресурсы на то, что уже сделано, готово, понятно. Еще раз выводить теорему Пифагора — дорогая задача, которая никому не нужна.
А.К.: Проще купить учебник.
О.Ш.: Тут совершенно точно.
А.К.: Не проще ли спереть?
О.Ш.: Спирая, нужно понимать, что мы спираем. У всех разработчиков — у хороших и у плохих, у больших топовых компаний, и у каких-то инди-разработчиков — есть плохие и хорошие решения. Я не смогу назвать ни одного продукта, который сделан идеально, что в нем нельзя найти ничего плохого. Всегда есть что-то плохое. И я всегда смогу это найти. И здесь нужно очень четко понимать, чем мы вдохновляемся. Если мы в чистую передираем чужой опыт без всякого понимания, то можно наломать дров из-за испорченного телефона. Если взять одни решения, и без понимания переложить их в другой продукт, то там они могут вести себя совсем иначе. Там могут быть другие пользователи, и пошло-поехало. В общем, получается какой-то снежный ком, и этим можно запороть продукт.
Почему важно это делать? Мне часто задают вопрос: «А зачем вообще UX? Как-то все работает и без этого». Хочу сказать, что в этом заложено качество продукта. Вы можете потратить уйму денег на разработку, нанять самого классного в мире программиста, нанять просто гениального маркетолога, вложить тучу денег, кучу ресурсов…
А.К.: А кнопку «включить» потом не найдете.
О.Ш.: … да. В итоге кнопку «включить» у вас пользователи не найдут, не найдут банк, на поймут, как пользоваться вашей игрой. Этим можно испортить все усилия.
А.К.: Ты же помнишь игры 15, 20, 30-летней давности. Первая игра была — это понять, как в это играть. Причем это было подано не в легком процессе обучения, а ты должен был пробираться через 1000 интерфейсов. Все было сделано на коленке, и никто не заботился о тебе.
О, интересный вопрос. Тут его задают в рамках «Что такое UX?», но уже: «Как происходит UX-проектирование?», спрашивает нас Дмитрий Валыхин. Как происходит рабочий день у Ольги? Очень интересно. В UX-проектировании каким образом, какими процессами ты приносишь такую колоссальную пользу, как мы теперь выяснили?
О.Ш.: На самом деле, это бесконечный процесс. Я всегда говорю о том, что ни одна задача UX-проектировщика не может считаться окончательно завершенной. Это камень преткновения, вечная серьезная головная боль линейного продюсера в проекте, потому ему хочется задачу завершить. Это входит в зону его ответственности. Я начала говорить про итерационный подход, и сейчас это немножко проясню. По идее, когда мы решаем задачу… К нам приходит гейм-дизайнер с каким-то ТЗ (талмудом документов), то есть он придумал и разработал какую-то фичу. И первый вопрос, на который нужно ответить — какие бизнес-задачи изначально мы решаем? Какие проблемы в проекте мы решаем этой фичей и что это даст пользователям? Как пользователи хотят это видеть?
Очень важно не забывать вопрос о том, нужна ли реально эта задача. Иногда он актуален.
А.К.: А можешь конкретный пример привести?
О.Ш.: Бывает какой-то субъективный подход гейм-дизайнера. Он считает, что мы делаем рейтинги. Он считает, что в рейтинге есть какой-то сложный фильтр. То есть он сам играет, у него есть какая-то субъективная оценка. Он говорит: «Давай мы сюда впилим». Потом начинаешь разбираться в процессе, что нужно это только ему. Всем остальным это не нужно. Нужно понимать, что разработчики мыслят совершенно не так, как пользователи. Поэтому и нужна эта оценка. Нужна UX-экспертиза, потому что мы пытаемся навязать какие-то собственные паттерны пользователю, и он нас не понимает.
Начали мы с задачи: «А что мы здесь делаем?». Бывают ситуации, когда я неделю смотрю в документы… Мне приносят такой документ, и я понимаю, что это гигантская задача. Первым делом ее нужно понять. Причем понять даже глубже, чем ее понимает гейм-дизайнер. Я ему задам 3 млн. вопросов, буду днем и ночью дышать ему в трубку. Сяду, как безумный профессор, обложусь бумажками и неделю буду смотреть в документ. Естественно, так происходит не всегда. Как правило, у нас очень живая и динамичная разработка. У нас нет времени, и все это нужно сделать очень быстро. Мы делаем бизнес-продукт, а не просто продукт для своего удовольствия. Но некоторые задачи требуют такого внимания и объема времени. Я сижу, вникаю в документ, молчу, а потом как задам поток вопросов, просто бесконечный.
Когда я получу для себя все ответы на эти вопросы, то приступаю к проектированию. Я использую достаточно простые графические редакторы, какие-то инструменты прототипирования. Почему так? Многие меня спрашивают: «Какие инструменты ты используешь?». Никогда…
А.К.: Хорошо с тобой общаться. Ты все банальные вопросы, которые я заранее подготовил, про инструменты и так далее, сама поднимаешь. Я, пожалуй, пойду.
О.Ш.: Да-да-да.
А.К.: Так что насчет инструментов?
О.Ш.: Я не люблю советовать инструменты. Их много всяких — платных и бесплатных. Я очень много, но — у них ограничены библиотеки. Это все годится для каких-то неигровых проектов. А игра — это такой придуманный мир, где чаще всего используются какие-то дополнительные штуки, которых нет в библиотеке. И приходится полдня заниматься расширением библиотеки этого инструмента для того, чтобы сделать нормальный детальный прототип. Либо получится рыба — это условный прототип, где я условно визуализирую свою идею. Но в результате я не донесу ее до дизайнера. Он не сможет сделать то, что придумала я, и уж тем более то, что придумал гейм-дизайнер. Суть будет потеряна.
Когда мы разрабатываем этот прототип, когда мы уже поняли, как все это визуально будет выглядеть, раскладываем предварительно информационную архитектуру. То что это значит? Мы понимаем, какие сценарии в рамках решения задачи есть у пользователя: что он будет делать, в какой последовательности, какие взаимосвязи могут быть между окнами, сколько окон нужно будет пройти, сделать этапов, и так далее. Когда мы все это поняли, то начинаем присваивать каждому окну какие-то конкретные задачи. Понимать, что «Вот-вот давайте еще сюда добавим вот это, потому что оно нужно для решения этой задачи, и хорошо бы это видеть перед глазами. А это давайте уберем. А тут давайте сократим. А это вообще сейчас отпилим, отрежем и больше не вспомним». Вся эта гигантская работа делается достаточно долго. Почему? Потому что в результате от этого зависит, поймет ли это юзер.
На этапе прототипа, формирования информационной архитектуры мы проверяем на юзерах, понятны ли наши задумки. Насколько они правильны, гибки и насколько хорошо решают поставленную задачу.
Вот наконец мы получили архитектуру прототипа. Обязательно проверяем, сверяемся с гейм-дизайнером. Надо сказать, что постоянная отсылка на каждом этапе работы — это постоянное возвращение к гейм-дизайнеру. Он автор идеи, он хранитель знаний в рамках одной фичи, и поэтому нужно с ним постоянно синхронизироваться. Вот мы выполнили задачу — визуализировали гейм-дизайнерскую идею, которую он пытался внести.
А.К.: Тут немного уточню. В этом процессе ты не подменяешь собой гейм-дизайнера? То есть ты непосредственно с проектом общаешься в процессе?
О.Ш.: Естественно. Я обязательно общаюсь с гейм-дизайнером.
А.К.: Нет, я имею в виду с проектом. Ты играешь ли непосредственно в тот момент, когда…?
О.Ш.: Обязательно.
А.К.: Потому что, мало ли, может это специально сторонний подход.
О.Ш.: Нет. Невозможно, не зная проект, внедрить в него какую-то отдельно взятую фичу.
А.К.: Мы ответили сразу на несколько вопросов, которые только что были заданы.
О.Ш.: Отлично.
А.К.: Раз уж ты готова отвечать на вопросы, то я периодически буду прерывать твой монолог.
О.Ш.: Да, пожалуйста.
А.К.: У нас все-таки интерактив. Я напоминаю, что сегодня у нас в гостях Ольга Шуберт, специалист по UX-проектированию игровых проектов в игровом направлении Mail.Ru Group. То есть человек чрезвычайно исключительный на рынке, больше таких нигде не найдете. Как тебе такой вопрос от Юры Чумакова: «Есть ли что-то вроде сложившейся традиции в интерфейсах игр, зависящей от жанра, вида, может быть, движка?»
О.Ш.: Да, разумеется, традиции есть. Это те самые паттерны, о которых я говорю. Причем очень важно с этими паттернами уметь работать. Пользователь, если он привык — мы же говорим о пользовательском опыте, — то он этот опыт уже где-то получил. В каких-то продуктах или используя какие-то платформы. Мы очень часто берем какие-то готовые платформенные решения, которые есть изначально. Обязательно смотрим на жанр, пытаемся понять, насколько хардкорна аудитория этого жанра, и насколько она готова к каким-то изменениям. Иногда бывает так, что нельзя выезжать все время на старых решениях. Иногда инновационный продукт требует инновационных подходов. И в этом случае нужно очень аккуратно проверять аудиторию, прощупывать ее на возможность каких-то нововведений, которые она может принять или не принять. Все это обязательно тестируется. На этапе, когда мы отдаем наш прототип гейм-дизайнеру, он уже протестирован. Мы уверены в том, что он будет правильно работать, и что он будет правильно воспринят конечным пользователем. Когда это отдается гейм-дизайнеру, то там уже все по полочкам. Мы знаем, что эта часть окна наиболее приоритетна. Она должна обладать такими-то, такими-то характеристиками. Здесь должно быть ярко, здесь подсвечено, а здесь задумана анимация.
Почему все это важно держать в голове? Потому что когда человек делает отдельно взятое окно, то дизайнер просто визуализирует одно окно. Что в нем важно, что неважно, какая будет анимация, как это все будет озвучено, куда мы придем из этого окна дальше. В отрыве от всего этого дизайнер неспособен решить задачу правильно. Поэтому приходится изучать и пользователей, и чужие решения, и собственные какие-то наработки. Обязательно должен быть какой-то опыт, какая-то экспертиза проектировщика. Я очень часто вижу молодых разработчиков, общаюсь с молодыми командами, которые говорят правильные решения, но не обладают своей собственной экспертизой. Они плохо знают рынок, и в результате решение звучит правильно, но я знаю, что юзер его не скушает. Он его не поймет и не осилит.
А.К.: Получается что-то слишком инновационное?
О.Ш.: В общем, да.
А.К.: Бывали ли случаи, когда интерфейсы были изобретены гораздо раньше и получили популярность?
О.Ш.: Да, все так. Что значит слишком инновационное? Тут спорный вопрос. Нет слишком инновационного. Есть то, к чему пользователь готов или не готов в рамках какого-то конкретного продукта.
А.К.: Слишком нейтрально все сказала. Например?
О.Ш.: Можно экспериментировать где-нибудь в танках. Это более сложная игра, она где-то мидкор, где-то хардкор. Сравни, например, танки и какую-нибудь игру Match 3.
А.К.: Например «Armored Warfare: Проект Армата» или «World of Tanks»? Или неважно что?
О.Ш.: Неважно. Мы сравниваем аудиторию.
Все совершенно разное. Хотя есть, наверное, есть пересечения где-то в возрасте от 30 до 40 лет. Когда некоторые мужчины любят повтыкать на телефон, но при этом не хотят иметь хардкор на телефоне.
А.К.: Может быть, да.
О.Ш.: Но при этом необязательно держатся за мидкор, потому что шарики можно по-разному рассмотреть.
А.К.: Пересечение достаточно небольшое. Я убеждена, что какое-то пересечение есть, но оно небольшое. Что касается решений, то мы можем в танках сделать что-то сложное. Так мы поймем, что пользователь готов с этим жить, готов это осознать. И даже если что-то где-то не получилось, то он готов подумать и принять решения, которые мы ему предлагаем. Если то же самое происходит с Match 3, то пользователь предпочитает никак это не осознавать, не бороться с этим и не думать об этом. Ему проще сказать: «Ой-ой, что это? Я здесь ничего не понимаю», и быстро свалить из этой игры. Тут имеет значение усидчивость пользователя и его готовность к каким-то более сложным вещам.
О.Ш.: Даже в рамках одного проекта, если говорить про мидкор, мы работаем с пользователями по-разному. Естественно, на младших уровнях. Мы даем самую что ни на есть казуальщину, насколько можно упрощаем процесс. А на более старших уровнях позволяем себе немножко разгуляться, расшатать этот механизм. И тут понимаем, что там юзер ведет себя иначе. Он уже привязан к игре, и знаком с ее основной частью, и поэтому какие-то новые более сложные вещи его не испугают.
А.К.: До этого в разговоре у тебя прозвучала отличная фраза, что очень сложно применить какие-то готовые паттерны к инновационной вещи, абсолютно новой и не изобретенной. Мы поговорим не совсем про суперинновации, но этот вопрос очень интересный, особенно в рамках наших предыдущих «Теностримов» про игры. Спрашивает нас Юрий Дорофеев: «Есть ли кардинальные отличия UX у обычных игр и VR?»
О.Ш.: Хороший вопрос, потому что я пока еще не разрабатывала VR-продукты. Но у меня есть по этому поводу некоторые соображения. Конечно, VR выглядит немножко иначе. В VR пользователь себя чувствует по-другому, поэтому здесь есть кое-какие отличия.
А.К.: Знаешь, у нас был прошлый стрим с нашими разработчиками, нашими VR-ребятами. Они рассказывали, что самая страшная проблема — проблема прицела. На каком расстоянии он должен быть от тебя? 5 сантиметров, 10, 15? А если ты к стене упрешься, то где будет прицел? И они бьются целой лабораторией, потому что не могут решить эту проблему.
О.Ш.: Я уверена, что они справятся с этой задачей. Но хочу сказать, что сейчас у VR огромные возможности с точки зрения даже не интерфейсов, а интерфейсов как среды взаимодействия. Есть огромные возможности, но все упирается в ощущения. Если бы можно было передать человеку какие-то тактильные ощущения… Например, он не просто подошел и нажал просто рукой за кнопку, а прямо взялся за ручку, повернул ручку, открыл дверь за ручку. Это привело бы нас к совершенно иному формату. И тут бы мы начали какой-то новый этап разработки, для которого еще решения не было.
А.К.: Я бы даже больше сказал, что начался новый этап развития человечества, в случае появления таких технологий.
О.Ш.: Да. А пока этого не произошло, и мы привязаны к технологии. Мы вынуждены ограничивать себя. Очень многие решения в VR взяты из привычной нам разработки, из привычных нам проектов, но существуют нюансы. Ты сам знаешь, что здесь возможностей больше.
А.К.: Дмитрий Грязин задает нам логичный вопрос: «Каким образом вы проверяете идеи, рыбы, прототипы на пользователях? Как часто это стоит делать в случае разработки своего проекта?»
О.Ш.: Начну с конца, как я люблю.
А.К.: И об инновациях.
О.Ш.: И об инновациях, да. Как часто — это вопрос очень хитрый. Все зависит от проекта, сроков. Если разработка идет в спокойном режиме, то можно себе позволить разогнаться, протестировать от души.
А.К.: И где же идет такая разработка?
О.Ш.: В какой-то сказочной игре.
А.К.: Я слышал что-то про компанию Blizzard. Но мне кажется, это все рассказывают.
О.Ш.: Да я думаю, что у них тоже не все так просто.
А.К.: Это только витрина, мне кажется.
О.Ш.: Да. В общем, в какой-то сказочной стране можно разогнаться и сказочно протестировать.
А, как правило, все упирается в сроки, в какие-то бизнес-задачи, в планирование. Тем самым, мы вынуждены себя ограничивать. Естественно, все протестировать вообще невозможно. Если говорить о тестировании в UX-лаборатории, то оно ограничено каким-то небольшим объемом. Например, мы берем какой-то кусок из игры, его тестируем и получаем ответы на какие-то заранее конкретно поставленные вопросы. Это не просто: «Давайте протестируем игру». А это реально фронт, который мы хотим изучить. Какие-то конкретные гипотезы, которые мы хотим подтвердить или опровергнуть. И уже на основе этого сделать какие-то дальнейшие выводы, как-то переделать вот этот кусок игры, который нас больше всего смущал. Нужно будет круглосуточно сидеть в лаборатории, выгнать всех, встать и сказать: «Не пущу!». И не вылезать оттуда для того, чтобы все время в режиме нон-стоп тестировать все, что можно. Но это дорого и сердито.
А.К.: Ты несколько раз упомянула «UX-лаборатория». Большинство людей, когда говорят слово «лаборатория», представляют себе что-то с колбами, пробирками, измерительными приборами, осциллографом в углу. А что такое UX-лаборатория в современном понимании этого слова? Какие там применяются технологии?
О.Ш.: Очень много ходило разговоров про нашу лабораторию, и не только про нашу.
А.К.: Не просто ходило, об этом даже федеральная пресса писала.
О.Ш.: Да-да-да. Можно загуглить много чего про это. Это такая комната.
А.К.: Секретная.
О.Ш.: Секретная, да.
А.К.: Полусекретная, ладно, хорошо.
О.Ш.: Да. Куда можно привести наших подопытных тестируемых, и проверить на них наши гипотезы. Тестирование бывает разное. Но это отдельная тема для обсуждения. Думаю, для этого нам понадобится еще несколько часов.
А.К.: Отлично, у нас есть время. Это жанр такой, называется «стрим». По 8, по 10 часов.
О.Ш.: Человеку дают поиграть в продукт. Это может быть мобильная версия продукта, браузерная версия продукта или клиентская игра. Зависит от того, что мы тестируем. Затем наблюдаем за поведением этого человека. Мы можем исследовать его психофизиологические показатели, общаться с ним или просто следить, куда он кликает, куда он смотрит, и так далее. Как вообще понимать, по какому сценарию и как он движется, насколько он понимает задачу, какая стоит перед ним? Тут огромное множество вариаций поведения в лаборатории.
Как правило, лаборатория доступна только узкому кругу жирующих разработчиков. И меня постоянно спрашивают: «Что же делать, когда лаборатория недоступна?». И большинство исследований по проекту происходит вне лаборатории, маленьких локальных исследований. Это дорогой и длительный процесс, он предполагает какое-то время для исследования. И оно тормозит, в общем-то, последующую разработку. Или мы понимаем, что у нас есть ровно два дня на решение какой-то срочной задачи, а у нас проблема, что пользователь не понимает происходящего.
Не все можно протестировать заранее. Я говорила, что мы чаще всего тестируем на этапе прототипа. Проходим по сценарию, пытаемся понять, как испытуемый себя ведет. Но в живой игре на реальном контенте, на посчитанном балансе, на реальных пользователях все это происходит несколько иначе, чем было задумано.
А.К.: Вдруг не работает.
О.Ш.: Да, чем оно было задумано. Когда определенная доля усилий изначально вложена в исследования, то так минимизируются риски, что в бою это не полетит. Точнее оно полетит, но где-то могут быть какие-то шероховатости, которые потом хочется дотюнить, как-то дополишить. И в этом случае мы используем все доступные нам методы, привлекаем друзей, коллег, знакомых, соседей, бабушек на улице ловим. В зависимости от задачи. Иногда я просто устраиваю засаду у кофе-поинта. Ловлю всех проходящих коллег, показываю им телефончик, и говорю: «Так, что здесь нарисовано, что это значит?»
А.К.: И нажать, куда хочется, да?
О.Ш.: Да. Если я понимаю, что человек отвечает корректно… Мы как-то спорили с одной из команд. Там были иконки, которые находились в списке ежедневных квестов. И мы пытались понять, похожи ли они на иконку квеста или это воспринимается как награда квеста. Можно долго спорить или просто половить людей у кофе-поинта, показать им. Причем тут надо очень четко формулировать для себя задачу…
А.К.: Все зависит от уровня этой задачи.
О.Ш.: Да. Нужно очень четко формулировать задачу. Ставить ее очень четко перед пользователем и ловить правильных пользователей в этом исследовании. Если спрашивать хорошо прошаренных коллег, то они сразу включают какие-то свои аналитические способности. Так не пойдет.
А.К.: Лучше это делать за переделами офиса Mail.Ru Group, все-таки?
О.Ш.: Да. Им хочется раскурочить игрушку. Когда ты им показываешь окно, ты ожидаешь от них, что они тебе скажут: «Ну, наверное, это награда за квест». А вместо этого они говорят: «Ну, это могла быть награда за квест, но здесь рамка не того цвета, и вообще, здесь немножко все сдвинуто на 3 пикселя, поэтому, наверное, это с этим не связано». В общем, начинается какой-то мыслительный процесс, включается разработчик.
А.К.: И вообще я видел это в World of Warcraft в 2004.
О.Ш.: Да. А ты совершенно не этого от него ожидаешь. Поэтому нужно очень правильно выбирать аудиторию для таких вопросов. А когда речь идет о каких-то фундаментальных задачах. Например, какие-то совсем базовые: костяк, что-то нужно протестить — допустим, бой, core gameplay. Мы хотим понимать, что бой — это самая важная, ключевая фича в нашей игре. Она должна цеплять, постоянно возвращать людей в игру. Этот бой должен по всем своим параметрам цеплять. Понятно, что все это берется не с потолка. Субъективный опыт разработчика здесь не канает абсолютно никак. И тогда нужна лаборатория, нужно четкое понимание аудитории, привлечение правильных людей с правильными девайсами, правильные вопросы и правильный подход к исследованию. Обычно оно комплексное и вырабатывается заранее. Что и как мы будем проверять, исходя из задачи, которая перед нами стоит.
А.К.: Если проводить аналогию, то у вас работа похожа на работу следователя-криминалиста. С одной стороны, вы работаете в поле, если задачи не очень сложные. А с другой стороны, вы применяете технологии, все эти гаджеты, которые навешиваются на человека и что-то определяют. Кстати, существуют такие штуки, мои самые любимые, когда я какие-нибудь UX-исследования смотрю, то они называются «тепловые карты».
О.Ш.: Я тоже их обожаю.
А.К.: Я тоже обожаю. Особенно на своих каких-нибудь проектах. Например, на сайте или еще на чем-нибудь. Смотришь такой: «Господи, а почему они сюда пялятся? Здесь же зеленая кнопка нарисована». Думаешь после этого. То есть UX, в принципе, показывает психологию поведения. То, как человек ведет себя на вашем сайте, в вашей игре, в вашем проекте и так далее.
О.Ш.: Совершенно верно. А ты, в общем, про технологию же спрашиваешь меня, правильно?
А.К.: Конечно. А что за технологии? Ты говоришь сейчас очень правильные вещи: что должен делать пользователь, и что мы решаем бизнес-задачи. Но как мы их решаем? Мы протоны в космос запускаем? Мы же все-таки шлем вешаем на голову.
О.Ш.: Вешаем шлем и запускаем протоны в космос.
А.К.: И его в этот момент на протоне запускаем в космос.
О.Ш.: Да.
А.К.: Очень похоже, кстати, на методику разработки видеоигр.
О.Ш.: Мы можем много чего проверить: проследить за эмоциями пользователя, изменениями его мимики в процессе. Увидеть, куда он смотрит, проанализировать, куда он пытается нажимать. Отследить его поведение в рамках каких-то сценариев, то есть он постоянно возвращается к одной и той же задаче. Ты видел, как тестируют всяких роботов. Когда он старается, а на ступенечку ступить не может.
А.К.: Его шваброй еще сзади подталкивают.
О.Ш.: Да. А иногда пользователь ведет себя примерно так же. Перед ним лежит решение, а он начинает тупить.
А.К.: У меня есть поговорка в связи с тем, что я очень давно и долго играю в видеоигры. Если я на каком-то месте затупил больше, чем на 15 минут, то не я дурак, а где-то гейм-дизайнер ошибся.
О.Ш.: Да. Тут дело даже не в 15 минутах. Если ты вообще затупил, то очень высок шанс, что в этом месте затупит другой человек. Поэтому я стараюсь обращать внимание на такие моменты. Если ко мне даже коллеги подойдут с вопросом: «Слушай, этот значок здесь появился. Что он значит?», то для меня
