Базис для будущего развития закладывается
еще до выхода на рынок. Инструменты и принципы в команде следующие:
· Кастдев до запуска;
· А/В и юзабилити тесты до подачи продукта юзерам;
· Заложенные в приложение аналитика и трекинг;
· Выпуск на стадии SRP (sales-ready
product).
Основная идея заключается в том, что улучшать и развивать имеет смысл только то
приложение, у которого есть потенциал для развития. Следуя этой мысли, мы
стремились выпустить не столько качественный, сколько интересный и перспективный
продукт, которым пользователь захочет продолжать пользоваться и завтра,
и в отдаленном будущем.
Пройдемся подробнее по
инструментарию:
Кастдев до запуска
Кастдев
(customer development) — тщательное, профессиональное исследование потребностей,
«болей» потенциальных клиентов и проверка гипотез разработчика — мастхэв любого
проекта перед стартом. Еще на стадии оформления идеи, до того как будет введен
первый символ кода, стоит определить свою ЦА, найти ее потребности и понять,
как выпускаемый продукт может их удовлетворить, провести анализ предложений
конкурентов и рынка субститутов, найти и сформулировать УТП — уникальное
торговое предложение («очередной мессенджер, только прикольный» не является УТП
«мы не висим» — тоже не оно, хотя сам по себе слоган забавный).
Важно определить, кого заинтересует продукт: взрослых
или подростков, руководителей или подчиненных, профи или любителей и т.д., — и
изначально «бить» в эту аудиторию, а не тратить бюджеты после выхода на рынок,
«переупаковывая продукт», когда выяснится, что реальная аудитория — не та, что
предполагалась. Иногда бывает, что приложение, написанное для профессионалов,
больше интересует любителей, а приложение для детей — их родителей. Мы
постарались это учесть.
А/В и UX/UI тесты до подачи продукта юзерам
На удивление, некоторые выкладываются в
стор без внутреннего тестирования продукта и даже не пользуются
предоставляемыми магазинами приложений возможностями, например, Google
Play Developer Console позволяет не только провести A/B-тесты и получить отчеты
по ним, но и поэкспериментировать с
рекламными материалами для маркетинговой кампании (инструмент «Эксперименты»),
загрузив несколько визуальных вариантов решений и выбрав из них оптимальный.
Юзабилити
— это степень удобства и простоты использования. И она просто должна быть.
Вспомните ощущение радости и волнения при установке нового продукта и досаду,
вызванную непониманием того, как воспользоваться той или иной функцией («Как
вернуться в чат?», «Где кнопка „Коллаж“?») Проверять юзабилити желательно на
сторонних, но лояльных пользователях (друзьях/золотое ядро и т.д.) —
желательно, тех, кто скажет правду, но не разгромит вас публично на страничке
своего блога или в отзывах.
Заложенные в приложение аналитика и трекинг
Анализ
данных и поведения помогает отследить, где, почему и на каком этапе
пользователь теряется и что его, наоборот, привлекает и удерживает. Все эти
данные позволяют оперативно подстраиваться под интересы клиента. Мы используем
Amplitude, Facebook Analytics и Firebase, поскольку для нас они наиболее
понятны и доступны, но есть и другие неплохие сервисы: например, Adjust,
AppMetrica и Mixpanel.
Трекеры
показывают, откуда приходят самые лакомые, самые «наши» пользователи. В свою
очередь, сервисы аналитики подсказывают, какими устройствами они пользуются,
считают поведенческие факторы и напоминают о внутренних ошибках приложения. Мы,
таким образом, ориентируемся на интересы целевой аудитории и подстраиваемся под
них, а также пытаемся предугадать желания топовых пользователей и предотвратить
возникновение ошибок. С недавних пор мы пользуемся трекером Branch . Не нравится Branch — есть
Adjust, AclX и множество аналогичных программ.
Неплохо
заложить в приложение возможность обратной связи: обычно пользователь не любит
совершать лишние действия и вряд ли добровольно посетит стор, чтобы поставить
оценку приложению, функционал и работа которого, в целом устраивают, но есть
небольшие недочеты, которые можно устранить. Вместе с фидбэком вы получаете
возможность общения с пользователем для выяснения деталей проблемной ситуации и
можете отследить проблему работы приложения на конкретном устройстве. Есть и
приятный психологический эффект: чувствуется небезразличие разработчика к тому,
что происходит с его «детищем» и готовность это разбушевавшееся «детище» в
случае необходимости усмирить.
Подача продукта на стадии готовности SRP
(sales-ready product).
Идея выпуска MVP (minimum viable product —
минимально жизнеспособный продукт) очень заманчива, экономически обоснована и у
некоторых компаний отлично работает.
К сожалению, чаще идея понимается неправильно и, когда
речь заходит об MVP, разработчики, маркетологи и авторы статей, пытаясь оправдать
существование ультрабюджетного, едва подающего признаки жизни продукта,
апеллируют к подобным иллюстрациям:
Мы считаем, это в корне
неверный подход и понимание процесса выпуска MVP. Если пользователь хочет
приобрести автомобиль — задача производителя предложить ему именно автомобиль,
а не скутер и, тем более, не колесо. Пусть на первых порах авто нужно будет
подталкивать и часто загонять на СТО — это все равно должен быть полноценный
автомобиль.
Т.е. мы готовим полноценную, но все еще «пробную
версию», на которой проверяется сама идея приложения, проводим анализ реакции
рынка, в соответствии с которой дорабатываем и переделываем приложение, после
чего снова «отдаем» его на тест реальным пользователям, а затем снова
переделываем и т.д. Это и есть процесс MVP.
Мы не могли себе такого позволить, поскольку
мессенджер для переписки картинками без широкой базы картинок и настроенных
вербально-визуальных связей никогда не будет хорошо принят широкой публикой,
даже если наши пользователи по результатам предварительных данных были
заинтересованы в подобном мессенджере, а формировать мнение о Funtome,
как «еще об одном приложении, от которых уже трещит телефон, — только хуже и
непонятнее» мы не хотели. Поэтому тестирование проводили своими силами в
небольшой группе друзей и знакомых, а на рынок вышли с полностью готовым
нетиповым продуктом и запаслись бюджетом для продвижения и «доформирования»
рынка. Такая стратегия довольно рискованна и не всем подходит: мы не
рекомендуем ее разработчикам софта и приложений для реального бизнеса.
Это то, что нужно сделать до релиза. Дальше, когда базис заложен и продукт выпущен, начинается самое интересное:
взаимодействие с пользователем. После публикации продукта его улучшение
происходит примерно по следующей схеме (порядок пунктов не важен):
Внутренние процессы:
а) QA, внутренний контроль качества;
б) Работа со статистикой и анализ данных.
2. Работа с пользователями:
а) Опросы и интервью;
б) Работа с отзывами.
Внутренний контроль качества, работа со статистикой
и анализ данных
QA (Quality Assurance — обеспечение качества),
или тестировщики, нужны для того, чтобы искать и устранять ошибки до того, как
их найдут пользователи, и решать, готов ли продукт/его новая сборка к выкладке
в стор.
Тестировщики пишут кейсы, составляют чек-листы,
тестируют продукт и фиксируют все найденные ошибки. Затем эти сведения
поступают разработчикам. В процессе контроля за устранением дефектов
тестировщики следят за своевременным исправлением ошибок и вносят
соответствующие отметки в систему. Также тестировщики осуществляют сбор и
анализ данных об ошибках, в том числе, полученных от службы поддержки.
Сбор и анализ статистических данных осуществляют как
тестировщики, так и маркетологи, которые которые вносят коррективы в стратегию
развития, исходя из полученной информации.
Но самое интересное, конечно, — взаимодействие с
реальным пользователем . С пользователем общаются аналитики и служба
поддержки. Чаще всего общение происходит в следующих форматах:
а) Опросы и интервью
Опросы и интервью могут быть как живыми, так и
проводиться в электронном виде. Нам удобны Google Forms: достаточно создать
опрос и отправить его подписчикам или разместить на своем веб-сайте, в
соцсетях.
Как показала практика, Google Forms хорошо работают и
не вызывают у пользователей негатива, который может быть перенесен на компанию
в отличие от некоторых других «подвисающих» платформ и сервисов для
опросов.
Полученные данные обрабатываются, и команда
делает определенные выводы о проделанной работе. В результате опросов мы видим
основные боли нашего пользователя и выстраиваем гипотезы о том, куда дальше
масштабировать функционал продукта. Благодаря подобным исследованиям в
интерфейсе появились некоторые изменения, например была добавлена возможность
редактирования отправленных сообщений и доработана система обучения.
б) Работа с отзывами
Важность отзывов и скорость реагирования на них
почему-то до сих пор сильно недооценивается. Отзыв — это не только мнение
пользователей о работе приложения и сообщение об ошибках, но и то, из чего
складывается оценка в магазине приложений. Грамотная работа с отзывами
помогает улучшать как продукт, так и репутацию на рынке. Нам приходят разные, в
том числе и негативные комментарии: от «отстой» до «здесь можно было бы улучшить
то-то и то-то», и мы реагируем на все.
Главные принципы работы с отзывами :
1. Скорость реакции
Мы стараемся отвечать как можно быстрее, но
иногда из-за разницы во времени реагируем не сразу — в любом случае, в течение
24 часов пользователь получает ответ на оставленное сообщение. Отзывы,
пришедшие через форму обратной связи на сайте и в приложении, обычно получается
обрабатывать быстрее.
2. Ответ обязателен
Даже если пользователь пишет лаконичное «фу». В
таком случае мы благодарим за мнение и спрашиваем, что именно «фу». Как ни
странно, иногда пользователь не отвечает, но оценку повышает.
Для нас обратная связь и мнения пользователей очень важны:
они дают возможность отследить реальные реакции на нововведения, понять, где
возникли или могут возникнуть какие-то сложности и проблемы, помогают понять
желания нашей аудитории и дают представление о том, как работает приложение на
разных устройствах. Увидеть наш мессенджер и познакомиться с ним поближе можно здесь или в Google
Play и App Store . Получите
фанум за регистрацию и проверьте сами, как работает наша обратная связь, —
будем благодарны за ваше мнение.