Зачем мобильному приложению нужно предпроектное исследование

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

Делать всё и сразу — не лучшая идея, так как множество фич в первом же релизе могут не окупиться и затягивают time to market. Поэтому разработка приложения начинается с MVP, который можно в дальнейшем развивать. Но чтобы было что улучшать, нужно построить крепкую основу — фундамент.

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

Как мы изучаем рынок и конкурентов и формулируем задачу

Как определяем функциональность приложения

Зачем составляем CJM

Чем помогают глубинные интервью — Сustdev

Зачем собираем Job stories

Как формируем схему Userflow

Как мы кастомизируем предпроектное исследование под клиента

Чтобы планировать долгосрочное развитие, важно не ошибиться в самом начале и правильно выстроить стратегию продукта. Успех продукта и его ключевые метрики: месячная и дневная аудитория, возвращаемость в продукт (Retention Rate), срок жизни пользователя в продукте (CLT — Customer Life Time) — напрямую связаны с бизнес-целями. И как следствие, с тем, насколько продукт будет прибыльным.

Предпроектное исследование мы разделяем на несколько этапов:

Давайте рассмотрим каждый из них.

Что делаем на этом этапе. Внимательно слушаем заказчика и то, что он рассказывает о своём бизнесе и своих клиентах: кто они, как любят совершать покупки, довольны ли приложением, если оно уже есть. Работаем в тандеме: наша команда и команда заказчика. Для того чтобы структурировать ответы:

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

Что делаем на этом этапе. Тут нет отдельной команды заказчика и команды Surf. Мы объединяемся в единую с общей целью — построить успешный продукт, который решает задачи и бизнеса, и потребителей. Для этого мы изучаем пользователя: его текущий опыт, боли, потребности, мотивацию. Продолжаем углубляться в рынок: исследуем существующие решения, конкурентов, их недостатки, достоинства и проблемы.

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

Что делаем на этом этапе. Составляем карту пути пользователя — CJM (customer journey map). Используем универсальный маркетинговый инструмент, который может сослужить хорошую службу при проектировании мобильного приложения. В формате воркшопа:

Мы работаем в формате двухдневного воркшопа — мозгового штурма, в котором участвуют и специалисты Surf, и сотрудники компании-заказчика из разных отделов, так или иначе вовлечённых в продукт.

Для чего это нужно. С помощью CJM-воркшопа мы собираем рабочую группу проекта, задействуя наших специалистов и сотрудников со стороны клиента. На выходе получаем чёткий план действий — остаётся только реализовать задуманное.

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

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

Кейс Surf. Этап CJM крайне важен, так как он позволяет определить слабые места приложения. Поэтому мы подробно останавливаемся на негативных юзкейсах. Рассмотрим на примере приложения доставки еды. Когда пользователь заказывает еду, он голоден и не хочет долго ждать. Любая негативная ситуация вызывает у него особенно острую реакцию. Поэтому тут важно определить все возможные негативные сценарии и свести их к минимуму.

В концепте приложения для KFC мы предложили реализовать инструмент быстрой связи со службой поддержки, это важно, когда заказ задерживается. Для контроля доставки мы разместили подробную информацию о статусе заказа и вывели её на главный экран. Чтобы после оформления заказа не оказалось так, что какие-то блюда недоступны, мы предложили сделать фильтр с возможностью выбора ресторана, где гарантированно есть нужные блюда.

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

Чаще всего опрашиваем от 15 до 30 респондентов из разных сегментов. Количество определяется для каждого проекта индивидуально, в зависимости от числа сегментов аудитории.

Дополняем процесс методологией Jobs To Be Done — это актуальный продуктовый фреймворк. Он позволяет наблюдать и анализировать потребности людей на разных уровнях: от жизненных целей до небольших рутинных действий.

Для чего это нужно. С помощью глубинного интервью мы определяем и приоритезируем сегменты аудитории будущего продукта. В результате клиент получает подробный документ с выводами и гипотезами. Мы узнаём:

Кейс Surf. В работе над приложением Бетховен на этапе Сustdev с клиентами зоомагазинов мы выяснили, что есть два основных фактора, которые привлекают их в приложение конкретного магазина:

Самое важное на этапе касдева — бережно собрать все найденные инсайты и артефакты. Одним из инсайтов кейса Бетховен стал тот факт, что у пользователей нет привязки к бренду, а есть потребность в быстрой и удобной покупке ходовых товаров для своих питомцев. Это и реализовали в приложении: мы детально проработали весь флоу заказа, сделав покупку лёгкой и быстрой.

Что делаем на этом этапе. Тщательно собираем все артефакты и инсайты, касающиеся потребностей пользователей. Мы изучаем открытые источники и исследования, аналитику, определяем вектор движения бизнеса.

Для чего это нужно. Следствием каждого этапа является набор Job stories — инсайтов, определяющих точки исходных потребностей. В дальнейшей работе мы с ними постоянно сверяемся — проверяем, соответствует ли то, что мы собираемся сделать, основным запросам пользователей. Это ориентир, позволяющий компактно хранить всё самое важное и верифицировать всё, что мы хотим сделать.

Что делаем на этом этапе. Создаём схему — графическое дерево функциональных возможностей приложения. Чтобы не растерять по пути главное, нужно собрать все полученные материалы и артефакты.

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

Дальше проект переходит уже на первые этапы разработки, к ним мы относим прототипирование и UX-тестирование. Кратко остановимся и на них. На основе собранных артефактов мы создаём прототип приложения: проектируем экраны в Figma, собираем кликабельные прототипы в Invision/Figma.

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

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

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

Например, в e-commerce мы больше внимания уделяем флоу заказа, так как конечная цель торгового приложения — это покупка — лёгкая и быстрая. О том, как мы это делаем, можно прочитать в нашем блоге. Фудтех работает с одной из самых «опасных» аудиторий — голодной и нетерпеливой. Поэтому тут важно проработать все возможности, связанные с быстрой доставкой — именно этот фактор является одним из определяющих в фудтех-приложении.

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

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

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

Однако, в целом, методология проведения CJM и касдева от отрасли к отрасли не сильно меняется. В каждом проекте мы следуем по одному и тому же пути. Может меняться только сложность сценариев и ролей пользователей.

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

За предпроектные исследования в Surf отвечает Product Lab — наше консалтинг-подразделение, которое выпустило в свет уже не один десяток успешных приложений. Они формируют и проверяют гипотезы, помогают настроить работу продуктовых команд, строят roadmap продуктов.