Userflow, практические нюансы.
Все (ладно, почти все) знают, что такое userflow. Это карта сайта, или отдельного сценария. Может содержать детальные экраны, или очень условные вайфреймы,
Пример с dribbble:
Зачем, когда, и как делать Userflow?
"Ну как, нарисовал дизайн, закинул все вместе и нарисовал стрелочек. А потом презентовал коллегам/заказчику/разработчикам и все счастливы".
Да, это вполне работает. Презентовать сценарий с помощью useflow — хорошая практика.
Но это все равно, что использовать машину как аудиоплейер. Сел, послушал музыку, вышел, и поехал на метро. Юзерфлоу могут гораздо больше:)
Я часто использовал флоучарты (они бывают разные, не только userflow):
- Чтобы придумать интерфейс, которого еще нет. То есть, решить, какие вообще будут скрины, и пр.
- Чтобы создать определенный пользовательский опыт/конверсию.
- Чтобы разобраться в очень сложной бизнес-логике.
- Чтобы разобраться в каких-то сложных взаимодействиях.
- Чтобы понять, какие метрики мне надо измерять.
Сегодня я напишу о userflow в работе над конверсией.
В среднем на фичу у меня получается вот столько схем:
Как использовать userflow в работе над конверсией?
В случае с конверсией мы начинаем с точки выхода и точки входа. Потом прорисовываем основной путь, потом дополнительные. Потом решаем, какие метрики будет замерять на каждом шаге.
Вокруг этого есть много нюансов.
1. Формулируем точку выхода
То есть, каков финальный и ценный для нас (!) шаг путешествия пользователя. Вопрос кажется банальным, но когда я спрашиваю некоторых дизайнеров... Ох.
"Финальная точка = оформление заказа". Разумно, но очень неконкретно. Что такое оформление заказа? :)
- Нажать на кнопку "оформить заказ"?
- Или попасть на страничку с формой оформления?
- Или вбить данные и нажать кнопку отправить? (а потом отвалиться и не оплатить заказ, отличная финальная точка :))
В данном случае, нам подойдет ответ "деньги пришли", полученный от платежного шлюза. Или от, бекенда — что заказ успешно создан.
С пользовательской точки зрения это уведомление о том, что заказ подтвержден и (если не была выбрана оплата курьеру) оплачен.
Пример из моей фичи. Конечный шаг, пользователь успешно подключи двухфакторную авторизацию. Часть схемы, где я рисовал именно с точки зрения пользователя.
То же самое, но с точки зрения скринов и метрик.
Шаги виззарда я решил в данном конкретном случае не раскрывать и показать одним прямоугольником (почему — единообразная метрика, и сами шаги ооочень простые, буквально из 1 поля каждый).
Обратите внимание, не посещаемость виззарда, а загрузка и отправка. Тут чисто технарский нюанс. Виззард находится на одном урле, и если я напишу посещаемость — мне могут измерить, сколько людей было в целом на виззарде. А мне нужны отдельные шаги.
2. Точка входа и контекст пользователя
Куда приземлится пользователь? Далеко не всегда на главную страницу. Например, в интернет-магазине чаще всего трафик идет на карточку товара.
Что делать, если я не знаю, как назвать скрин входа? Допустим, у нас сложный продукт, скринов пока нет никаких... Я могу назвать начало юзерфлоу не по скрину, а по состоянию пользователя.
Вот так это выглядело в части схемы, где я писал в терминах пользовательского опыта.
Всегда ли нужно рисовать эту часть, или можно обойтись без нее? Я рисую, когда ощущаю, что "уперся" и чего-то недопонимаю. Но это возможно, когда у вас хорошо развит "внутренний наблюдатель" и когда вы пользуетесь схемами давно. Поначалу есть смысл рисовать в пользовательских терминах почаще.
А вот так — в терминах скринов и метрик.
Контекст пользователя. Он помогает понять, кто идет по сценарию, откуда он пришел и что он уже знает про вас, ваш продукт и про данную фичу.
К примеру, если посетитель пришел из вашей группы в вк, или с подробного ролика на youtube — этот пользователь может уже все знать о вашем товаре.
И его не надо приземлять на справочную страницу, можно сразу вести к продаже.
Я описываю контекст, во-первых, точками входа, а во-вторых — разделением схем по группам пользователей (когда их несколько и они реально отличаются). Например для фичи с картинок выше — есть "воронка новичка" (подключающего 2FA впервые) и "воронка старичка" (у которого уже установлен/был установлен любой из методов 2FA на нашем сайте)
3. Основной путь между входом и выходом. От конца к началу.
После того, как определен вход и выход, нужно связать их между собой.
И здесь мы:
- Идем от конца к началу.
- Помечаем те шаги, без которых финальная точка (например, заказ) — невозможна.
- Рисуем по прямой, по вертикали (не по горизонтали).
- Если испытываем сложности — рисуем сначала в терминах пользовательского опыта, а уже потом — скринами и метриками.
Вот например, что получилось у меня. Слева — в терминах пользовательского опыта, в середине — экраны (необязательно, где-то и группы экранов), справа метрики.
Давайте разберем каждый упомянутый пункт и поймем, почему я предлагаю рисовать именно так.
Идем от конца к началу.
Не знаю, почему так получается, но при направлении от начала к концу — всегда хочется закопаться в детали.
Начинаешь думать, а какой из путей таки главный и пр.
Если же идти в обратном направлении — ты просто решаешь задачку "какой был предыдущийшаг, без которого этот — невозможен?". И все.
Только шаги, без которых финальная точка невозможна.
Нам нужна основа. Самый короткий путь от входа к выходу. Если не отвлекаться и нарисовать ТОЛЬКО КЛЮЧЕВЫЕ ШАГИ, без которых заказ просто невозможен — все последующие альтернативные пути мы нарисуем гораздо быстрее и легче.
Рисуем по прямой, по вертикали (не по горизонтали).
При такой компоновке гораздо проще ставить пометки "на полях". К примеру, те же метрики, как в моем случае. Плюс я часто записываю рядом с шагами схемы какие-нибудь задачки, данные, и прочие нюансы.
Плюс (спасибо Саше Бизикову за это соображение) вертикально ориентированные сценарии банально удобнее листать (скролл мыши, а не пробел плюс перетаскивание).
Сначала — пользовательский опыт, потом скрины.
В конечном счете, мы рисуем чтобы пользователь что-то понял, принял какие-то решения и что-то сделал. Если это не зафиксировать — легко упустить какие-то моменты, возможно — важные.
Вот что у меня получилось на этом этапе.
4. Дополнительные пути.
Чаще всего по сайту есть не один и не два пути. Например, в карточку товара можно попасть и с главной, и со страницы раздела, и с результатов поиска.
На этом шаге мы отмечаем такие пути. Я не могу показать альтернативные пути из этой моей фичи, поэтому покажу пример из работы моих студентов:
Небольшой пример с прошлого потока моего интенсива.
5. Цели и триггеры
Цель — это событие, по достижени/ которого мы считаем, что шаг юзерфлоу завершен. Триггер — это конкретный показатель, по которому срабатывает цель.
Они нужны, чтобы мы не только нарисовали фичу, но и смогли увидеть в цифрах, как посетители ей пользуются.
Например:
Цель — добавление в корзину.
Триггер — нажатие на кнопку (или событие в бекенде).
Тема целей и триггеров — очень обширная. Триггеров много, они разные. Одни настроить легче, другие сложнее. В реальной практике их будет много (целей может быть и сотня и полторы на большом сайте), поэтому их надо уметь правильно называть (а заодно уметь не плодить избыточные).
Поэтому, когда я учу воронкам конверсии, то посвящаю триггерам целую лекцию.
Заключение
Вот мы и разобрались с одним из многих способов применения userflow :)
Если появилось желание освоить написанное на практике — мы даем это все на онлайн-интенсиве по конверсии для дизайнера
и в результате находить в интерфейсе узкие места и точки роста. Влияя на них, можно принести много ценности бизнесу и пользователю :)
Открыть для вопросов и каментов:
И не забывай подписываться на мой канал о UX!