Userflow, практические нюансы.

Все (ладно, почти все) знают, что такое userflow. Это карта сайта, или отдельного сценария. Может содержать детальные экраны, или очень условные вайфреймы,

Пример с dribbble:


Зачем, когда, и как делать Userflow?

"Ну как, нарисовал дизайн, закинул все вместе и нарисовал стрелочек. А потом презентовал коллегам/заказчику/разработчикам и все счастливы".

Да, это вполне работает. Презентовать сценарий с помощью useflow — хорошая практика.

Но это все равно, что использовать машину как аудиоплейер. Сел, послушал музыку, вышел, и поехал на метро. Юзерфлоу могут гораздо больше:)

Я часто использовал флоучарты (они бывают разные, не только userflow):

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

Сегодня я напишу о userflow в работе над конверсией.

В среднем на фичу у меня получается вот столько схем:

Как использовать userflow в работе над конверсией?

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

Вокруг этого есть много нюансов.

1. Формулируем точку выхода

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

"Финальная точка = оформление заказа". Разумно, но очень неконкретно. Что такое оформление заказа? :)

  • Нажать на кнопку "оформить заказ"?
  • Или попасть на страничку с формой оформления?
  • Или вбить данные и нажать кнопку отправить? (а потом отвалиться и не оплатить заказ, отличная финальная точка :))

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

С пользовательской точки зрения это уведомление о том, что заказ подтвержден и (если не была выбрана оплата курьеру) оплачен.

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


То же самое, но с точки зрения скринов и метрик.

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

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

2. Точка входа и контекст пользователя

Куда приземлится пользователь? Далеко не всегда на главную страницу. Например, в интернет-магазине чаще всего трафик идет на карточку товара.

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

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

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


А вот так — в терминах скринов и метрик.

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

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

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

Я описываю контекст, во-первых, точками входа, а во-вторых — разделением схем по группам пользователей (когда их несколько и они реально отличаются). Например для фичи с картинок выше — есть "воронка новичка" (подключающего 2FA впервые) и "воронка старичка" (у которого уже установлен/был установлен любой из методов 2FA на нашем сайте)

3. Основной путь между входом и выходом. От конца к началу.

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

И здесь мы:

  • Идем от конца к началу.
  • Помечаем те шаги, без которых финальная точка (например, заказ) — невозможна.
  • Рисуем по прямой, по вертикали (не по горизонтали).
  • Если испытываем сложности — рисуем сначала в терминах пользовательского опыта, а уже потом — скринами и метриками.

Вот например, что получилось у меня. Слева — в терминах пользовательского опыта, в середине — экраны (необязательно, где-то и группы экранов), справа метрики.

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

Идем от конца к началу.

Не знаю, почему так получается, но при направлении от начала к концу — всегда хочется закопаться в детали.

Начинаешь думать, а какой из путей таки главный и пр.

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

Только шаги, без которых финальная точка невозможна.

Нам нужна основа. Самый короткий путь от входа к выходу. Если не отвлекаться и нарисовать ТОЛЬКО КЛЮЧЕВЫЕ ШАГИ, без которых заказ просто невозможен — все последующие альтернативные пути мы нарисуем гораздо быстрее и легче.

Рисуем по прямой, по вертикали (не по горизонтали).

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

Плюс (спасибо Саше Бизикову за это соображение) вертикально ориентированные сценарии банально удобнее листать (скролл мыши, а не пробел плюс перетаскивание).

Сначала — пользовательский опыт, потом скрины.

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

Вот что у меня получилось на этом этапе.

4. Дополнительные пути.

Чаще всего по сайту есть не один и не два пути. Например, в карточку товара можно попасть и с главной, и со страницы раздела, и с результатов поиска.

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

Небольшой пример с прошлого потока моего интенсива.


5. Цели и триггеры

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

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

Например:

Цель — добавление в корзину.

Триггер — нажатие на кнопку (или событие в бекенде).

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

Поэтому, когда я учу воронкам конверсии, то посвящаю триггерам целую лекцию.

Заключение

Вот мы и разобрались с одним из многих способов применения userflow :)

Если появилось желание освоить написанное на практике — мы даем это все на онлайн-интенсиве по конверсии для дизайнера

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

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

@Serebrennikov_i

И не забывай подписываться на мой канал о UX!