Для кого эта игрушка или как определить целевую аудиторию

Многие разработчики затрудняются ответить на вопрос “для кого вы это создаете?”. Как показывают опросы и богатый личный опыт в большинстве своем ответы на подобные вопросы звучат слишком расплывчато или вообще являются догадками.



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

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

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



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



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



Я бы хотел остановится немного подробнее на этом вопросе. Давайте попробуем оживить пользователей.





Самая известная проблема на сегодняшний день — это уверенность разработчиков что их игра подойдет для всех. Можно встретить много игр, которые завоевали популярность среди игровых критиков, но так и не смогли откусить большой кусок пирога популярности среди игроков. Игрушка может быть сколь угодно замечательно сделана, только вот для кого? Вывод, который напрашивается сам собой — все могут играть в твою игру, но совсем не обязательно что она всем понравится. “Моя игра подойдет абсолютно всем типам игроков” – фраза, которая не дает абсолютно никакой полезной информации с точки зрения принятия верных дизайн решений.

Персоны

Но как принимать решения, влияющие непосредственно на опыт игрока, без понимания для кого ты собственно их принимаешь? Для решения этой задачи нужно обратиться к потребностям пользователей. Последние 20 лет в индустрии разработки ПО эффективно применялся один инструмент. Имя ему – ПЕРСОНЫ.

Пионер дизайна ПО и программист Алан Купер всегда стремился к тому, чтобы на выходе получить простой в использовании продукт. Его трясло от одной только мысли, что пользователи будут считать его софт слишком сложным и запутанным.

В то время при создании ПО в первую очередь думали о технической эффективности. Алан понял, чтобы получить годный софт нужно разорвать этот шаблон и начать учитывать потребности пользователей. Так и получилось, что вначале он спрашивал потенциальных пользователей чего они хотят, а потом уже приступал к дизайну. В результате, после бесконечных интервью и тонн собранной информации он разделял пользователей на группы с похожими значениями. Каждую группу он обзывал – ПЕРСОНА *имя персоны*.



Купер понял, что ПЕРСОНЫ – это идеальный инструмент для создания действительно удобного ПО. Имея такие объемы информации на руках можно свернуть горы. Стало понятно какие функции нужны пользователям, почему они хотят их, в каком виде их преподнести, трудности с которыми они могут столкнуться. Нужно оценивать эффективность решений в отношении каждой персоны и тогда будет понятно, кто из них ближе всего к понятию “наша ЦА”.

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

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

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

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



Не так страшен черт, как его малюют. Вы уже поняли про самые сложный и трудоемкий процесс – интервьюирование потенциальных пользователей для создания персон. Но есть способы достижения хорошего результата попроще. Один из таких способов – аналитика существующих данных. Еще один способ – наблюдение за игроками, которые похожи на вашу ЦА. Посмотрите так ли они играют в вашу игру, как вы ожидали. Единственный недостаток — для работы с аналитикой или наблюдением за игроками нужен более-менее рабочий продукт.

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

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

Давайте рассмотрим ситуацию, что вы провели плейтестинг и включили в него 3 персоны, каждая персона состояла из десяти похожих на вашу ЦА человек. В итоге вы поняли, что две персоны пользовались вашим продуктом ожидаемо и сделали полезные замечания, в то время как третья персона кардинально отличалась от ваших ожиданий. Теперь вы можете решить — доработать продукт, чтобы удовлетворить все 3 персоны или выкинуть лишнее и сосредоточится на двух персонах. В любом случае у вас будут реальные доказательства любых ваших действий.

Пример создания персоны

1. Демографические данные.

— место жительства
— пол
— какое образование
— уровень доходов
— размер семьи
— каковы потребности

2. Образ жизни.

— уровень доходов
— как они принимают решение о трате своих денег
— транжиры или консерваторы

3. Интересы.

— как проводят свободное время
— наличие хобби
— предпочтения в спорте

4. Влияние.

— самостоятельный или подвержен влиянию
— на основе чего принимает решения

5. Личные цели.

— чего хотят добиться в жизни
— какие потребности недостаточно удовлетворены

6. Эмоции.

— реакция на позитивные события
— реакция на негативные события

7. Поведение.

— Как и когда они готовы тратить деньги
— Какое это имеет отношение к моему проекту
— Отношение к скидкам

8. Что хотят получить от вашего проекта.

— нужен ли им туториал
— нужны ли им дополнительные сервисы
— нужно коммуницировать с другими игроками

...............

Заключение

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

Вам должно быть стыдно, если после прочтения этой статьи вы не будете создавать персон. Очевидно, это поможет сделать ваш продукт лучше, сократить время разработки и снизить риск провалиться на столь конкурентном рынке.