Геймдизайн. Канал "Заметки игродела.
#gamdesign #gd

Сегодня необычный вариант поста, вместо того чтобы разобрать очередную статью - расскажу про один из тематических каналов, которые сам читаю. Называется - "Заметки игродела" (он же @zametki_igrodela ). Автор - Булат Даутов, в свое время стоял за разработкой механоидов (одна из немногих отечественных игр, за которую не было стыдно) и имеет 20-летний стаж в геймдеве. В канале периодически постит любопытные размышления на тему геймдизайна.

Из недавнего заинтересовал материал про так называемый feeling в играх. Данным термином описывается то, что заставляет игрока получать удовольствие от происходящего в игре. Он отличается от спорного термина fun, который периодически форсят в разных источниках тем, что имеет большую предметность. Чем реальнее выглядит то, что на экране, чем проще мозгу подстроиться под это.

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

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

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

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

Источник: https://t.me/zametki_igrodela

КДИ. Аналитика. Софтлонч и глобальный запуск.
#kdi #softlaunch #globallaunch #product

Тема во многом перекликается с недавней статьей про метрики на запуске с мэйловой конференции (tbd).

Цель раннего доступа, запуска на отдельные страны, да и вообще всех вариантов софтлончей - проверить все функционалы, метрики продукта, прежде чем официально представить его аудитории. Начинать нужно с маленьких объемов. Важно до софтлонча продумать все метрики, на которые будем смотреть.

Выделяют 3 фазы софтлончей:

Tier 0 (technical).
Проверить технические аспекты игры, краши, аналитику и т.д. Обычно для этого брали Филиппины. Kpi по нему строится на основе конверсии в прохождение туториала.

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

Tier 1 (retention).
Запуск на страны, похожие паттернам поведения пользователей на целевую. К примеру для штатов такими странами можно считать страны северной Европы и выводы будут релевантны.
Если уже есть данные по ретеншну других проектов, можно найти дешёвые страны с поведением как сша и на них проверить удержание игры.  Если вы льете немного трафика, то получаете самых лучших пользователей сначала, дальше цифры проседают ~15%.

Tier 2 (monetization).
На данном этапе хорошо проводить a/b-тесты монетизации, поскольку после глобального запуска можно поймать негатив от разных цен у разных игроков, особенно при активном комьюнити.

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

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

Смартфоны ниже iPhone 6 вызывают проблемы. Палка о двух концах выходить ли с поддержкой всех девайсов и потом отключать проблемные или опасаясь за отзывы отключить заранее.

Некоторые чтобы избежать этой проблемы софтлончат под другими брендами. К примеру кинг так делает.

Кейс.
Рейтинг очень важен как минимум для получения фичеринга, гугл не фичерит ребят ниже 4+. У ребят был фичеринг, в нём рейтинг упал ниже, гугл выкинул из фичеринга.

По LTV смотрят на полгода(фермы), а для казуалок 3 месяца. В расчете LTV покупного трафика стоит закладывать пришедшую с ним органику, чтобы оценивать окупаемость.

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

Глобал лонч.
Для того чтобы получить фичеринг в глобал лонче нужно чтобы игра локализована на основные языки мира.
Она должна хорошо работать и выглядеть на всех целевых девайсах, включая формфактор iphoneX, настроены взаимодействия аналитиков+тестировщиков+ГД, настроена система атрубуции трафика, чтобы отделить покупных пользователей от органики.
Для appstore должны присутствовать фичи стора, которые в данный момент усиленно ими продвигаются.
Для google play более важны цифры и рейтинг.

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

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

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

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

С большим фичерингом можно подавать игру на фичер ориентировочно раз в пол года. Subway surfers и candy crush делают патч ориентировочно раз в 3-4 недели.

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

Источник (2 часа): https://www.youtube.com/watch?v=T8YXB8_igCA

​​Карточные механики в играх.
#gd #gamedesign

Карточные игры и элементы сбора колоды встречаются в играх уже долгие годы, на гамасутре опубликовали пост с советами от ребят, выпустивших сравнительно успешные игры, с советами. Очень много воды, постараюсь выделить основные моменты.

Узнаваемость.
Опыт, который игрок получает играя в игры типа MTG, hearthstone и netrunner во многом схож с тем, который он получает в классических RPG. Игрок берет на себя роль героя, у которого есть заклинания, оружие, существа или любой другой способ победить врага. Карточные игры меняют лишь способ того, как игрок будет воспринимать и взаимодействовать с уже знакомыми сущностями. К примеру карта "удар героя", где нарисована рука с мечом, одним своим видом дает приблизительно понять, что произойдет. Это очень важный момент в онбординге игрока.

Более сложные сущности следует вводить постепенно, чтобы не отпугнуть нового игрока. При это нужно следить, чтоб сложность росла одновременно с пользовательским опытом, не давая ему заскучать.

Кейс.
Довольно частой проблемой является нежелание пользователя экспериментировать с синергиями карт, нежелание держать  в руке и сбрасывание их сразу, как приходят. Как решение (использовано в grand/fate order) - давать дополнительные  бонусы за несколько использованных карт. От себя замечу, что данную проблему в HS практически не встречал, играя душными OTK колодами. Скорее всего имеется в виду, что данная проблема характерна для новых игроков.

Баланс.
Баланс является одним из наиболее сложных и важных моментов в карточной игре. У создателей Book of demons ушло два с половиной года в раннем доступе и тысячи итераций, чтобы привести его в порядок. Постоянно находятся слишком сильные и слишком слабые карты и комбинации.
Пользователи будут постоянно просить усилить те или иные карты. Они чаще всего понятия не имеют хороша ли та или иная карта, а говорят скорее о том, что играть ею неинтересно. Нужно менять то, как она играется.

Внедрение механик в свою игру.
Карточная система может увеличить вовлеченность и позволить преподнести различные абстрактные правила игроку. Сам когда-то внедрил в рудиментарном состоянии такую схему в tower defense и получил неплохой рост показателей. Главный совет - сделайте прототип с небольшим количеством базовых карт. Если он будет плохо играться добавление новых карт и сложных механик не решит эту проблему.

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

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

Игры авторов высказываний:  SteamWorld Quest, Book of demons, Hand of fate, Cultist simulator.

Источник (англ.): http://www.gamasutra.com/view/news/339445/Designing_for_deckbuilding_in_video_games.php

​​Hustle castle и war robots. От идеи к запуску.
#product #tbd #softlaunch

В оригинале данное выступление называлось "Цифры против креатива", но эта тема практически не раскрыта, зато очень неплохо рассказано о построении процесса запуска новых проектов в компаниях Nord (Hustle castle) и Pixonic (War robots).

Nord.
Как построен процесс выбора идеи для нового проекта:
1. Сначала подумали для кого хотят делать - выбрали штаты и Европу, поскольку это большие рынки и относительно близки по ментальности к нам.
2. Проект должен обладать минимальным порогом вхождения, чтобы охватить как можно большую аудиторию.
3. Посмотрели на тренды и отметили для себя популярность american dad, the simpsons и других ситкомов такого типа. Решили остановиться на этом в плане сеттинга.
4. По геймплею решили делать PvP, он позволяет углубить геймплей.
5. В мете у них был опыт реализации прокачки поселения, поэтому решили, что стоит реализовать данное решение и в hastle castle.
6. Опционально хотели, чтобы пользователь генерировал игровой контент.

Устроили небольшие вечерние совещания, анализируя идея и сверяя их с чеклистом. В итоге получили несколько идей на основе которых сделали прототипы, один из которых стал HC. Заняло 2 месяца.

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

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

Ребята столкнулись с кризисом веры в проект незадолго до софтлонча, но увидев retention hastle castle поняли, что проект будет успешен. Дальше был долгий путь к монетизации.

Ориентируются на минимальную длину сессии, составляла порядка 7 минут и возрастает во время ивентов. Измеряют эффективность ивентов по 3м параметрам:
- росту конверсии в плательщиков
- росту количества платежей от ядра аудитории
- увеличению активности игроков.


Pixonic:
Идею war robots принесла студия извне и сумела ей заразить. В принципе любой сотрудник может сгенерировать идею. На этапе подготовки прототипа каждый описывал, как видит эту и в результате получались совершенно разные варианты.

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

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

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

Решение о запуске нового продукта принимается, когда текущий вышел на плато роста.

Источник (45 мин., рус.): https://youtu.be/1URKrGkTfrE

​​Проверка идей на пользователях. Сплит тесты, плэйтесты.
#product #test

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

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

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

После нужно определиться с аудиторией, которая по вашему плану должна будет полюбить вашу игру. Для этого можно попробовать посмотреть на конкурентов и использовать fb audience.


Методы проверки гипотез.

A/B тестирование.
Хорошо знакомый большинству метод сплит-тестирования, когда даем 2 варианта одного контента и смотрим на результат.

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

Онлайн опросы.
Способ посмотреть на поведение игроков и сделать выводы, обратившись в компанию, помогающую с проведением.

Пример компаний:
https://www.playtestcloud.com/
https://www.sekg.net/ (если нет подводных камней, то можно прогнать через игру 50 юзеров за $500, по сравнению с остальными ценниками, что я видел, это большой шаг в сторону доступности)
https://www.playerresearch.com/

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

Минусы:
- есть вероятность неверно трактовать результаты
- при использовании опросников можно упустить детали

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

Плюсы:
- помогает определить долгосрочные тренды в поведении пользователей
- позволяет изучить процессы обучения и вовлечения
- более глубокий фидбэк

Минусы:
- времязатрантность
- требование к навыкам игрока в вопросах аккуратности записей и оценки впечатлений
- более сложный и дорогой процесс

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

Минусы:
- плохо масштабируется
- не всегда объективно, возможно предвзятое отношение

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

Источник (англ.): https://gameanalytics.com/blog/user-research-prototype-stage-game.html

​​Оптимальный размер кнопок.
#UX #UI

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

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

- резкое ухудшение попадания по кнопкам начинается с размеров меньше 42px (11mm). Кнопки такого размера стоит использовать для функционалов низкого приоритета
- для большинства пользователей оптимальным будет размер ~60px (16mm)
- для самых важных функционалов и для аудитории старшего возраста рекомендуют использовать ~72px (19mm)
Пример в скрине под заголовком.

Отступы.
Тут работает прицип - чем больше кнопка, тем легче по ней попасть, соответственно тем меньшие отступы можно использовать не потеряв в удобстве.
- 12-24 px большие кнопки
- 24-36 px средние
- 36-48 px маленькие

Те же правила работают и для кнопок.

Источник (англ.): https://uxmovement.com/mobile/optimal-size-and-spacing-for-mobile-buttons/

​​Path o Exile на GDC 2019. Action RPG как сервис.
#gamedesign #gdc #product #poe

Недавно прошел GDC 2019 и одно из самых любопытных выступлений на мой продактовский взгляд - Designing Path of Exile to Be Played Forever от Chris Wilson. Говорил он быстро и по делу, так что времени на перевод и выжимку потребовалось чуть больше обычного. Из доклада можно выделить 2 основных состовляющих успеха:

Вариативность игрового процесса.
Для увеличения реиграбельности нужно увеличивать вариативность, особенно в рутинных действиях:
- Механика боя. Как пример давая возможность игроку суметь вывести персонажа из-под атаки
- Уровни. Если планируете выпускать регулярные обновления очень  желательна процедурная генерация. Она позволит создавать контент к каждому обновлению в меньшие сроки. Большей вариативности можно добиться, если ввести её как на уровне генератора в рамках одного архетипа карты, так и на уровне подборки пачки архетипов на каждый случай. Визуального разнообразия на уровнях можно добиться, используя визуальные эффекты, поэтому делать смену дня и ночи просто чтобы были - расточительно.
- Предметы. Рандомная генерация свойств вносит больший элемент неожиданности, игрок не знает получил ли он топовый предмет или есть к чему стремиться. Само собой она добавляет вариативности. Сами предметы должны давать достаточный прирост характеристик, чтобы игроку хотелось их находить. Возможность торговли между игроками сильно поднимет стоимость предметов для пользователей, но очень важно вместе с этим защитить экономику от взлома, иначе результатом будет лишь негатив.
- Персонаж. Множество вариантов развития, отсутствие жесткой привязки к классу и регулярное появление свежих навыков - всё это создает основу для возвращения в игру.

Оперирование.
- Регулярные обновления. Причем регулярные это подчиненные четкому плану, игрок должен понимать когда сможет вернуться в игру и зачем. В PoE пришли к 13-недельным периодам между релизами.
- Маркетинговая поддержка обновлений и понимание желаний игрока. Важно определить свои USP, точно понимать, что нужно каждому типу ваших пользователей и сообщать им об этом. Важно не забывать про потребителей high level контента, несмотря что пользователей может быть немного. В PoE это около 10%. Помимо того, что они приносят достаточно большую долю дохода, ими также создается контент для стримов, а это гарантирует приток новых игроков. Также стоит приглядеться к аудитории, образующейся в сообществах вокруг игры, с большой вероятностью это большая часть игроков грядущего апдейта.
- Оптимизированный процесс разработки. Помимо процедурной генерации и повторного использования ассетов важно не затягивать с интеграцией новых идей и подготавливать контент заранее, когда высвобождаются ресурсы. Не стоит пытаться готовить несколько последовательных релизов одновременно, иначе вы медленно реагируете на реакцию игроков на каждый релиз.
- Грамотный подход к окупаемости. Точных цифр он конечно не называл, но упомянул, что они окупают разработку обновлений в PoE при DAU=10k.

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

Источник (1 ч., англ): https://www.youtube.com/watch?v=pM_5S55jUzk

Как и обещал - лонгрид.
https://dtf.ru/gamedev/46940-doklad-ot-razrabotchikov-path-of-exile-na-gdc-2019-action-rpg-kak-servis?comments

​​Playkot. Маркетинг - задачи и кейсы.
#marketing #tbd #product

Сегодня материал с мэйловой конфы TBD. Маркетолог из playkot рассказал несколько кейсов и поделился мыслями.

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

Задачи маркетолога:
- Работа с трафиком.
Занимает 80 % времени работы маркетолога. Есть проблема когда маркетинг оторван от разработки, не понимает сути продукта, не имеет расписания обновлений. В итоге не эффективно решает задачи привлечения. Чтобы её решить внедрили маркетолога в команду.

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

- Проведение A/B тестов, подбора иконок и т.д.


Кейсы.

Проверка успешности жанров.
Решение делать дальше ферму или ситибилдер делали по appanie, смотрели растет рынок по данному жанру или стагнирует. Аудитории ситибилдеров и ферм в fb показывали рекламу и вели на фэйковый стор. Померили конверсию, выяснилось что обе аудитории с большим удовольствием идут в ферму. Это подтвердилось и данными в appannie.

Провели исследование, батл рояли заработали на 320млн больше, чем мобы в 2018. Все мобы просели. Если в команде есть человек с видением мобы и батл рояля, то лучше делать батл рояль.


Мониторили hustle castle, увидели рост на 20%, проанализировали изменения:
- они купили больше трафика чем обычно
- запустили клановые войны через 11 месяцев после релиза
- через месяц после этого внесли изменения и добавили чат
То же самое c last day in earth, только рост 14%:
- была годовщина, запустили специальный ивент
- добавили крутой лут за нового босса, причем босс high-end ориентированный
Внедрили.

ГД хотели продать пак за $8, он предложил поставить за $30 и в это один из самых продаваемых паков. Почему $30 сразу не могут ответить, всё делалось в спешки и не a/b тестировалось, вполне вероятно, что можно было поставить большую сумму.

Дополнительно.
Добавили в стор плашки типа best price, дало результат.
Для определения своей ЦА они закупают в FB по широкому таргетингу, а потом смотрят на параметры оставшейся core-аудитории.
Из гипотез ~70% срабатывает, остальные откатываются.
Первый день проверяют сеттинг, первые несколько дней проверяют core gameplay. Рекомендуют тестировать прототип на 1-3 дня.
В age of magic всё было хорошо с retention первого дня и плохо 14го и 30го.
Китайские пользователи лучше играют и платят первые 7 дней, но затем выгорают быстрее, чем ребята из штатов.

Источник (30 мин.): https://www.youtube.com/watch?v=B166hTKHymE

​​Прототипирование. MVP. MLP. RAT.
#UX #product #mvp #mlp #rat

Тема сегодня - тестирование прототипов игры. Оно необходимо, чтобы уменьшить риски выхода на рынок с продуктом, который никому не нужен. Конечно есть свои нюансы и если вы делаете клон успешного проекта без серьезных изменений, создавать прототип большого смысла нет. Если сильно меняете стиль арта, можно протестировать креативы и посмотреть конверсию. Но речь сегодня не про тест креативов, а про подход RAT, если точнее, то про возможности его применения в игровой индустрии. Но обо всём по порядку.

Подходы к прототипированию.
Первым популярность приобрел подход создания MVP (Minimum Valuable Product), то есть минимально жизнеспособного продукта. Но на практике очень часто оказывается, что MVP представляет из себя альфа версию игры, продукт слишком дорогой и сложный для быстрого тестирования гипотезы, но при этом слишком сырой для тестирования гипотез.

Чтобы решить проблему сырости появился термин MLP (Minimum Lovable Product), минимально привлекательный продукт, более репрезентативный, но еще более дорогой в производстве. В итоге мы только удаляемся от задачи максимально быстро протестировать гипотезу.

В попытке решить эту проблему был придуман подход RAT (Riskiest Assumption Test), тестирование наиболее рискованных гипотез. В статье источнике оно описано довольно абстрактно, я попробую передать суть с учетом специфики геймдева. Сводится она к тому, что на этапе определения жизнеспособности концепции не стоит делать прототип всех циклов игры и смотреть на retention, а стоит проверить самые рискованные из гипотез в их наиболее атомарном виде. Успех гиперказуалок показал, что игра может удерживать внимание игрока продолжительное время, имея при этом всего одну механику. Собственно продолжительное время нам не нужно, если мы хотим проверить инновационный гемплей или необычное сочетание арта и механик. Достаточно просто сделать небольшое вступление, чтобы не оттолкнуть игрока и дать несколько итераций эту механику, померив потом конверсию. После залить в ранний доступ в google play, поскольку там нет отзывов и закупаем небольшой объем трафика, на котором смотреть цифры.

Основным недостатком данного метода в отличие от того же MLP является гораздо более высокое требование к опыту дизайнера теста. Нужно очень точно сформулировать гипотезу и не менее точно определить условия её доказательства. В идеале работать командой и придя к идее теста задаваться вопросом как можно еще проще протестировать данную гипотезу.

Источник (рус.): https://ux-journal.ru/mvp-umer-da-zdravstvuet-rat.html

​​Книга. Роб Фицпатрик. Спроси маму.
#ux #custdev #product #book

Наконец дошли руки сделать вычитку по книге "Спроси маму". Книга считается настольным пособием для продактов, сталкивающихся с задачами получения фидбэка от пользователей, customer interview и т.д.

Основные идеи.
Продукты чаще проваливаются не потому, что плохо сделаны, а потому что никому не нужны.

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

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

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

При подготовке к общению с пользователем подготовьте с командой 3 основные цели сбора информации. После интервью проанализируйте вместе полученные данные и на основе сделанных выводов скорректируйте дальнейший план действий.
Разделите обязанности - один сотрудник общается, второй конспектирует. Обычно достаточно 10-15 минут, чтобы узнать всё необходимое.

Сколько проводить интервью - до тех пор, пока узнаете что-то новое, по опыту автора 3-5 встреч обычно достаточно.

Найти аудиторию можно через холодные звонки и сообщения.

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

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

Бесполезные ответы:
"Я мог бы" - гипотетические рассуждения.
"Я делаю что-то постоянно, часто, иногда" - любое отсутствие конкретики.
"Я сделаю" - обещания действий в будущем.

Чтобы пригласить пользователя:
- Расскажите о том чем занимаетесь и к чему стремитесь.
- Расскажите как они смогут вам помочь подчеркнув значимость собеседника, попросите о помощи.

Риски.
Связанные с рынком - нужно ли это пользователям, много ли их, сколько могут они заплатить.
Связанные с продуктом - возможно ли его создать, сложно ли развивать, как долго им будут пользоваться.

Важно сегментировать свою аудиторию, понимать кто гарантирует большие объемы аудитории  или обладает большей платежеспособностью и решая их проблемы.

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

В целом рекомендую ознакомиться, есть любопытные моменты, написана легко.

Источник (рус., 150 стр.): https://www.ozon.ru/context/detail/id/140446253