Как выбрать фичи для вашего приложения: используем модель Кано

в 11:08, , рубрики: game development, Gamedev, mobile development, Блог компании KamaGames Studio, мобильные игры, фичи, метки: , , ,

Итак, вы задумали делать продукт. Не проект, а именно продукт, который через Х месяцев должен появиться в сторах и начать свое движение к звездам. Вы уверены в своих силах и знаниях, а количество новых идей, которые могут превратиться в настоящие киллер-фичи, просто зашкаливает. Самое время сказать себе “стоп!” и разобраться в том, что должно войти в комплект вашей самой первой релизной версии.

После того как вы расписали все характеристики будущего продукта, необходимо определить приоритеты в разработке. Первое желание – ранжировать по сложности реализации. Логично, тем более если ресурс ограничен – нет смысла строить “Титаник”, когда для первого преодоления Рубикона нужна просто шустрая и устойчивая лодка. Следуя заветам customer development, вы в будущем будете только наращивать функционал: главное – в архитектуре не промахнуться.

Итак, делаем шуструю лодку. Но выбор все еще непрост – даже из относительно простых деталей нужно определить тот набор, который и станет вашим release candidate. И здесь вам на помощь придет модель, которую придумал в 70-е годы прошлого века японский ученый Нориаки Кано. На “Хабре” уже был текст об использовании его модели для решения задач UX. Этот подход вполне применим и к продуктовым функциям – ведь они тоже отвечают за эмоциональные реакции потребителей. Кано предположил, что таких реакций бывает пять типов: от полной неприязни до прямо-таки восхищения. Эти типы японец изложил на одном графике, где по вертикальной оси отобразил эмоциональную реакцию пользователя (неприязнь – восхищение), а по горизонтальной – “количественное” значение характеристики (нет – много).

Как выбрать фичи для вашего приложения: используем модель Кано


Типы характеристик продукта. Изображение с сайта fdfgroup.ru

Типы характеристик по Кано

Мнения расходятся, сколько же всего типов характеристик стоит выделять. Самый расхожий вариант – три, менее популярный – пять. Для начала – о каждом из них с примерами из области мобильных продуктов.

1. Привлекательные. Ваши киллер-фичи. Их нет пока ни у кого (возможно, у кого-то просто не расставлены акценты на данную характеристику). Пока таких характеристик в продукте нет, пользователь не переживает, он просто не знает, что может быть так круто.
Примеры: У Snapchat это – исчезающие сообщения, у Twitter – мобильное обновление на старте проекта, у Candy Crash Saga – новая форма социализации.

2. Одномерные. Линейная зависимость. Если характеристик мало – это плохо, если много – хорошо.
Пример: Скорость загрузки первого активного экрана. Чем быстрее человек дождется окончания вращательных движений разного рода “шестеренок” как символа того, что “приложение думает”, – тем лучше будет его эмоциональная реакция. Неслучайно сейчас многие “прячут” основной контент в “докачку”, отложив пользовательский негатив на потом. Спорное решение.

3. Обязательные. “Это не обсуждается, детка”. Эта характеристика есть у всех ваших конкурентов и, что более важно, также ожидается вашими пользователями в вашем продукте.
Пример: Уведомление о статусе сообщения в мессенджерах – “Доставлено”, “Прочитано”. Стоит ли исключать эту опцию из вашего IM? Сомневаемся. Как и опцию видимого окна для ввода текста. Тоже стандарт.

4. Неважные. Всем пофиг. Есть характеристика, нет ее – никого она не радует, но и не раздражает. Увеличивая ее количественные показатели или уменьшая, вы не получите никакого эффекта. Хорошо заметны во время А/В тестирования.
Пример: Раздел “Авторы” внутри приложения (не путать с прелоадером, который скорее обязательная характеристика: никто не любит noname продукты). Ваше тщеславие мало волнует пользователя, конечно, если вы не вываливаете на первый экран список участников проекта.

5. Нежелательные. “Уберите это, немедленно”. Чаще всего эти опции весьма полезны вам как разработчику, но бесят юзеров.
Пример: Мы к таковым относим жесткие блокеры “плати или уходи”. Есть популярное решение в виде “Продай друга” – смотрите на относительно свежем примере Jelly Splash от Wooga. Другой вариант – “вес” приложения в мегабайтах. Хотя эту характеристику можно отнести и к одномерным, только с примечанием “чем меньше – тем лучше”.

Как этим пользоваться

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

— Неважные и нежелательные характеристики часто убирают из списка типов. Решать вам. В любом случае характеристикам первых трех типов стоит уделить ключевое внимание при разработке.

— Четко разделяйте эмоциональное отношение к характеристикам – ваше и ваших пользователей. Кому будет легче от того, что “гений остался непонятым”? В книге “Вальсируя с медведями” Том ДеМарко и Тимоти Листер утверждают, что выбор версий для ранних стадий поставки основан на двух критериях: ценность для заказчика и подтверждение гипотез о возможных рисках. Первое – про вас, второе – про ваших пользователей.

— Не гадайте, проверяйте. Для этого и существуют фокус-группы, А/В тесты и легендарные soft launch на маленькой аудитории, максимальной релевантной вашей целевой. Главное – четко ставить гипотезу и не допускать смешения переменных.

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

Все типы характеристик на примере одной игры

Попробуем провести небольшой анализ характеристик на примере Jelly Splash. На наш взгляд, игра является примером удачного клонирования. Взяв от хита Candy Crush Saga простую линейную историю с вовлечением социального графа, в wooga подтвердили привлекательность данной характеристики. А вот само использование социального графа через активно пропагандируемое подключение Facebook-аккаунта – характеристика одномерная. Пользователь может увидеть друзей на timeline – через их достигнутые уровни усиливаются долгосрочные цели игрока. При помощи друзей игрок сможет разблокировать переход на новую локацию или получение “энергии”: отсутствие жестких блокеров “плати или уходи” стало еще одной обязательной характеристикой современных игр. Результаты друзей на каждом конкретном уровне – третье их использование внутри продукта, влияющее на среднесрочные цели. Итого: чем чаще и органичнее используется социальный граф – тем лучше.

Как выбрать фичи для вашего приложения: используем модель Кано

К обязательным характеристикам необходимо отнести кроссплатформенность игры – с той же авторизацией через Facebook можно сохранять прогресс на iPhone, iPad и Facebook. О том, чем отличается клон от оригинала, пишет автор популярного блога Deconstructor of fun (ссылка www.deconstructoroffun.com/2013/08/how-jelly-splash-beats-candy-crush-saga.html) – в Jelly Splash введена хард-валюта и убрана возможность прямой покупки контента или расходников.

Ссылки по теме

marketnotes.ru/marketing-research/kano-method/ — Использование модели Кано на примере пульта от телевизора.
www.fdfgroup.ru/?id=281 — Детальная статья о том, как определить тип той или иной характеристики путем опроса пользователей. Интересное дополнение в виде сегментации вашей аудитории.
lookback.io/ — Сервис записи пользовательского поведения в мобильном приложении в видеоролик.
www.appprivacy.net/ — Генератор Privacy Policy для вашего мобильного приложения. Это обязательная характеристика, никуда не деться.
mockuphone.com/ — Просмотр мокапов на эмуляторах экранов мобильных телефонов
www.yozio.com/ — Использование адресной книги в качестве канала виральности.

Автор: kamagames

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js