Как найти и максимально использовать незапланированное путешествие пользователя

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

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

На протяжении многих лет мы пробовали и тестировали множество инструментов в Venture Harbour, которые помогли нам улучшить циклы обратной связи. У наших продуктов есть потребности, которые требуют различных типов инструментов для раскрытия всех видов идей. От тепловых карт и инструментов регистрации посетителей (таких как Hotjar и Fullstory) до аналитических платформ, таких как Google Analytics и Amplitude.

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

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

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

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

Примечание . Чтобы вы знали, это макеты, основанные на реальных сценариях.

Превратите тупики в золотые прииски обратной связи

Тупики в пользовательском потоке распространены. Один из способов обнаружить их — проанализировать свои страницы выхода в инструменте отслеживания аналитики, таком как Google Analytics. Это позволит выделить общие страницы выхода на вашем сайте или в приложении и даст вам отправную точку для начала исследования.

Теперь нам нужно задать простой вопрос:

«Почему пользователи уходят в эти моменты?»

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

Пример: тупики в поиске

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

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

Ниже приведен пример тупикового поиска:

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

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

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

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

Пример: естественные тупики

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

Итак, теперь мы хотим убедиться в двух вещах:

1. Пользователь должен понимать, почему и что происходит;
2. Вовлекайте пользователей, пока они ждут данных.

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

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

Рекомендуемая литература : Как улучшить процесс проектирования с помощью персонажей на основе данных

Превратите серые области в идеи

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

Пример: Понимание своего «Другого»

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

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

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

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

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

Пример: Понять, что вы мгновенный поиск

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

Исходя из этого опыта, я задал себе следующие вопросы:

• Какой вывод из этого сценария?
• Могу ли я узнать, насколько распространен этот сценарий?
• Чего пытается добиться пользователь?
• Как мы можем помочь им добраться туда, куда они хотят?

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

Вот несколько способов привлечь пользователей:

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

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

Сделайте ваши сообщения об ошибках сильной стороной

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

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

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

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

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

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

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

Рекомендуемая литература : A/B-тестирование для мобильных устройств.

Во что вам обходятся резервные варианты?

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

Что дальше?

Почему бы не потратить несколько часов на то, чтобы изучить пути пользователя и задокументировать серые зоны, а также поискать тупики и сообщения об ошибках, которые (все еще) существуют в вашем продукте.

Вот несколько руководств для начала:

• Тупики
  Начните изучать свою аналитику и — если вы еще этого не сделали — освойтесь в ней. Страницы выхода обычно отслеживаются по умолчанию и дают вам отличное представление о том, на каком этапе ваши пользователи покидают сайт. Подумайте о том, на каком этапе пути будут находиться ваши пользователи, и подумайте, какие потребности у них могут возникнуть в эти моменты.
• Серые области
  Если вы еще этого не сделали, наметьте путь пользователя и начните выделять области, по которым у вас могут возникнуть вопросы. Рассмотрите моменты, в которых ваши пользователи принимают решения, и подумайте о вариантах, которые вы им предоставляете. Вспомните вариант «Другое» и подумайте, где могут быть какие-то довольно общие. Начните отслеживать эти варианты, чтобы увидеть, как часто они выбираются, а затем начните изучать способы получения отзывов от пользователей о том, чего они хотят.
• Ошибки
  Вы можете быстро выяснить, где в вашем приложении может отображаться ошибка. С сайтом/приложением, которое сохраняется, обновляется и работает в режиме реального времени, ошибки, возможно, являются ключевой частью вашей системы. Начните с выяснения того, какая область используется чаще всего, что может привести к тому, где чаще всего встречаются ошибки. Инвестируйте в сообщения об ошибках и начните собирать отзывы о том, почему они отображаются — как от вашей системы, так и от пользователя. Я бы также рекомендовал создать сообщение об ошибке по умолчанию с циклом обратной связи, который будет использоваться на сайте для любой новой функции, чтобы вы начали учиться на этих ошибках с первого дня.

Удачного резервного строительства!