Как правильно использовать MVP и научиться понимать желания ленивого пользователя

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

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

MVP: что, зачем и как

Аббревиатура MVP расшифровывается как minimum viable product — минимально жизнеспособный продукт. В теории данная концепция приносит свою положительную выгоду тем, кто пытается ее внедрить в жизнь. Не всегда это получается удачно (особенно в России), но об этом чуть позднее.

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

Фото: ShutterStock

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

Но что вы потеряете? Если так примитивно трактовать модель минимально жизнеспособного продукта, то вы потеряете все: и время, и деньги, и нервы.

Давайте рассмотрим конкретный, не метафоричный пример: фирма «А» решила создать сервис по доставке продуктов из сетевых магазинов города. Сервис кросс-платформенный: есть веб-версия, приложения для iOS, Android и даже Windows, а также админ-панель для обработки заказов, сервер и база данных. Но это все в планах. Ребята начитались статей про MVP и решили, что минимально жизнеспособный продукт надо делать только в веб-версии. Правильное решение, на первый взгляд. Таким образом, они серьезно и действительно сэкономили средства и время на разработку приложений, значительно облегчили разработку бэкэнда.

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

Фото: ShutterStock

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

А какое направление будет нужным? Естественно, пользователь.

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

Поэтому множество разработчиков на свой «экспертный» взгляд предлагают заказчику во время разработки урезать функционал лайка, чата, возможности оплатить через смс и прочего, так как это скорее «дополнения» к основному функционалу. Но на основании чего они делают такие предложения? На основании чего, какой-то функционал признается основным, а какой-то дополнительным? Разве пользователя уже кто-то о чем-то успел спросить? Нет. Есть предположения, анализ, чужие платформы и чужой опыт. Ну, так на то он и чужой и, скорее всего, менее успешный, раз вы решили развивать свой сервис в противовес конкурентам.

Что такое LUC и с чем его едят

Поговорим о Lazy User Concept или концепции ленивого пользователя. Ее суть сводится ко взгляду на любую бизнес-модель со стороны ленивого пользователя.

Кадр из мультфильма WALL-E

Основные положения LUC:

1. Пользователь всегда стремится к состоянию комфортного покоя (ничего не делать, ничего не платить, получать удовольствие). То есть его раздражает все, что его хоть как-то беспокоит, даже если эти изменения будут положительными.
2. Пользователь готов сделать изменения только в том случае, если они в ближайшем будущем принесут ему еще большее состояние комфортного покоя.
3. Пользователь готов заплатить за изменения только в том случае, если планируемый профит значительно улучшит его положение.
4. Пользователя нельзя просто спрашивать, ему надо предлагать и анализировать реакцию на предложенное.

Исходя из рассмотренных гипотез, автор концепции предлагает использовать такой инструмент, как pre-function. Это когда у вас есть кнопка «обрезать фото», но нет самой функции. И стоит просто счетчик. Пользователь кликнул, вы посчитали.

По стандартной пользовательской статистике вы можете исследовать и внедрять любой пользовательский функционал, которым хотите насытить свой сервис: как только более 2% пользователей тыкнут в соответствующую кнопку pre-function — вы тут же бросаетесь реализовывать данный функционал в полном объеме. Не тыкают — ваше счастье: вы ведь все сделали по правилам — деньги сэкономили, время сэкономили и даже пользователя спросили.

Фото: ShutterStock

Кроме pre-function, есть еще несколько немаловажных моментов, вытекающих из принципов поведения ленивого пользователя:

1. Вам необходимо определить одну (максимум две) пользовательские цели, которых вы хотите достичь в рамках одной пользовательской сессии (поделиться, сохранить, обрезать, выбрать, заказать и так далее);
2. При разработке и визуализации вам нужно по всем правилам UI/UX эти цели поставить настолько близко к носу пользователя, чтобы он не смог пройти мимо них;
3. Гиперважный момент: при разработке пункта №2 необходимо убрать все лишнее, что может отвлечь пользователя от поставленной вами пользовательской цели. Про это забывают почти все. Запомните: пользователя нельзя отвлекать.

Итак, рассмотрим на конкретном примере, как это работает. Вы — заказчик, пришли к разработчику. Делаете заказ на навигационное приложение, которое показывает, где находятся ваши друзья и знакомые, у которых также установлено это приложение. В прототип приложения вы уже «напихали» чат, обмен фотографиями и другими файлами, кнопку «заказать такси» и кучу всякой всячины, которую разработчик в первом релизе в рамках модели MVP предлагает вам не делать. А сделать сначала «сухую» карту и точки на ней. Максимум с именами, чтобы пользователи видели, кто есть поблизости и как его зовут. Прибавляем к модели MVP еще Lazy User Concept и задаем себе вопросы:

1. Какую цель я ставлю для себя в первом релизе?
2. Что я должен сделать для пользователя?
3. Что пользователь должен сделать для меня?

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

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

Надеюсь, мои объяснения с примерами помогут вам разобраться в том, как делать первый релиз и в каком направлении его развивать. MVP + Lazy User Concept шикарный инструментарий для создания и выпуска в жизнь любых цифровых продуктов, потому что позволяют вам не только делать предположения, но и проводить анализ поведения целевой аудитории в реальном времени.

Материалы по теме:

Почему вашему приложению нужен MVP?

Шесть этапов MVP: разбираем реальные кейсы

«Смотрите на услуги глазами клиента»: просто сказать, сложнее — сделать

Как «притянуть» потенциальных клиентов с помощью лид-магнитов