Как помочь пользователю войти в продукт и «не сломаться»

Дизайнер «Авито» рассказывает на примере использования принципов проектирования пользовательского опыта

Как помочь пользователю войти в продукт и «не сломаться»

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

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

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

Как пользователи обычно воспринимают вход в продукт

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

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

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

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

  • Они состоят из 200+ экранов.
  • Объединяют 30+ сценариев.
  • Чтобы пройти все ветки, нужно сделать 80+ подкапотных проверок.

Что может произойти при прохождении сценариев

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

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

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

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

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

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

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

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

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

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

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

💡 Совет

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

О чём важно помнить, если хотите сделать понятный интерфейс

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

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

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

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

Чтобы лучше разобраться, как сделать понятный интерфейс, который обучает пользователей и несёт ценность для бизнеса, расскажу про наш кейс.

Кейс: как погружение в контекст повышает удовлетворённость пользователя и меняет отношение к продукту

У нас есть две системы защиты профиля на этапе авторизации:

👉 Двухфакторная аутентификация (2ФА)

👉 Внутренняя проверка от Авито

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

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

Во втором случае, при выключенной 2ФА — может сработать внутренняя проверка от Авито, если действия пользователя будут распознаны как подозрительные. Отключить внутреннюю проверку нельзя.
Кейс. Пользователь отключил 2ФА, чтобы не вводить код из смс при каждом входе с нового устройства — он считает эту защиту излишней и она ему мешает. Но по какой-то причине наша внутренняя система безопасности при следующем входе распознаёт его действия подозрительными, он попадает на внутреннюю проверку Авито, и мы запрашиваем у него код из смс.

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

Так раньше выглядели экраны 2ФА и внутренней проверки Авито— они практически идентичны
Так раньше выглядели экраны 2ФА и внутренней проверки Авито— они практически идентичны

Расскажу, как мы решили этот кейс с помощью изменений в интерфейсе.

Проанализировали обращения в поддержку и поняли, что люди не понимают разницы между 2ФА и внутренней проверкой. Думают, что мы по ошибке просим у них проверочный код, хотя 2ФА они отключили.

Мы поставили себе такие цели: снизить количество обращений в саппорт, убрать негатив и объяснить, чем отличаются внутренняя проверка Авито и 2ФА.

Подготовили ТЗ для редактора. Чтобы сделать интерфейс более понятным, мы решили доработать тексты для обоих сценариев и привлекли к работе редактора.

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

Вот что мы хотели донести, и какие тексты у нас получились
Вот что мы хотели донести, и какие тексты у нас получились

Выкатили обновлённые интерфейсы для обоих экранов. Теперь они выглядят так:

Новые экраны для 2ФА и внутренней проверки
Новые экраны для 2ФА и внутренней проверки

Результат. Объяснили, в чём разница между проверками, добавили ценности для пользователей и прогнозируем уменьшение нагрузки на поддержку.

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

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

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

✅ Ценность для бизнеса. Прогнозируем уменьшение нагрузки на саппорт. Будем следить за обращениями, чтобы узнать, помогли ли изменения в интерфейсе повлиять на удовлетворённость пользователей.

Вместо выводов

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

👉 Думаю о пользователе, становлюсь на его место. Зачастую именно профессиональная деформация сильно этому мешает.

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

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

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

👉 Проверяю решения на UX-тестах, коридорках или через Яндекс.Толоку — без этого иногда сложно понять, как на самом деле пользователи интерпретируют увиденное.

2121