Onboarding как отражение продукта

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

Мы как команда роста должны постоянно искать точки развития продукта, нам свойственно придумывать что-то кардинально новое. В это статье речь пойдет о том, как мы переделывали онбординг, опираясь на метрики, анализ пользовательских интервью и «ux-коридорки». Давайте начнем.

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

Говоря другими словами - важно понимать в какой категории находится ваш продукт с точки зрения функционала.

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

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

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

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

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

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

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

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

Рассмотрим дизайн онбординга и выпишем его минусы:

К примеру онбординг является частью первой сессии юзера — цель которой конверсия в регистрацию пользователя. Поэтому давайте выпишем минусы первой сессии на которые влияет онбординг.

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

Из этого следует, что новый онбординг должен дополнять и усиливать собой первую сессию, либо нужно переделывать остальные части первой сессии в цельную историю для пользователя.

Мы решили вообще уйти от слайдов, нужно было показать юзеру работу приложения уже в онбординге («Aha moment»), попутно познакомив его со сторонним приложением, чтобы когда дойдет дело до ключевого экрана - большинство пользователей продолжали регистрацию.

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

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

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

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

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

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

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

Вот такой дизайн мы в итоге согласовали:

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

Дальше самое сложное — провести исследование и внести нужные правки в нужном месте.

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

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

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

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

Список критерий (требований) к вопросам:

Далее формируем сами вопросы

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

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

Чтобы не затягивать нашу статью и превращать ее в войну и мир, основные правила составления вопросов для ux-исследования вы можете погуглить сами). Я лишь скажу то, чего я не встретил в интернете, но по моему мнению это очень важно.

Что важно знать перед самим интервью:

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

Цветами в таблице представлены итерации тестирований.

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

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

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

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

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

Делаем версию для A/B теста и выкатываем (дробим на эксперименты).

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

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

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