Проектирование смены Email

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

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

Важное примечание: в нашем сервисе пока не применяется двухфакторная аутентификация и Email является единственным обязательным идентификатором пользователя.

Распространённые причины смены Email

Причин для смены Email может быть не так много, но они достаточно весомые:

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

Задачи, которые стояли перед нами

  1. Дать пользователю возможность самостоятельно сменить Email.
  2. Снизить нагрузку на службу поддержки с просьбами о смене Email.
  3. Обеспечить определённый уровень безопасности, при котором злоумышленники не смогут завладеть чужим аккаунтом.

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

  1. Злоумышленник вошёл в чужой аккаунт → сменил Email → сменил пароль → восстановление пароля без Email невозможно…
  2. Пользователь ввёл неправильно Email → разлогинился → забыл пароль → восстановление пароля без Email невозможно…

Наконец сам процесс

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

Не забываем при этом указать где именно надо искать этот код подтверждения, когда можно запросить код повторно и заодно напоминаем проверить папку Spam.

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

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

Успех! Почта изменена. Показываем какой Email был и какой стал.

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

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

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

--

--

--

Cамый большой коллективный блог про дизайн на русском языке

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Mak

Alexander Mak

Senior Product Designer based in Budapest ⚡︎ https://www.behance.net/litazavr

More from Medium

Can Bad Design Kill?

Hierarchy in design and how to ACE it

4 Kind of products in need of UX designers

A man painting, holding a tablet

Qobuz wishlist feature design: a journey through UXUI