23 правила для дизайна процесса регистрации и входа в систему

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

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

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

Правила для регистрации

1. Запрашивайте минимально необходимую информацию для создания аккаунта

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

Если ваша форма регистрации состоит более чем из двух страниц — у вас будет большое количество отказов.

2. Отметьте обязательные поля и сгруппируйте их

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

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

3. Ограничьтесь стандартными требованиям к паролю

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

4. Внедрите подтверждение правильности заполнения полей и показывайте возникающие ошибки

Самые ненавистные формы — это те, которые заставляют человека заполнить все детали, а потом показывают ошибки в самом верху. И одновременно с этим пропадает придуманный пароль («‎безопасность»‎).

 Понятное указание человеку на его ошибки гарантирует, что он не уйдет.

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

1. Подождите клика на поле
2. Проверьте введенные данные
3. Если случилась ошибка — покажите ее, но не возвращайтесь к этому полю (не нарушайте пользовательский путь заполнения формы).
4. Когда пользователь фокусируется на ошибочном поле (и поле не пустое) проверьте раскладку и нажатые клавиши. Если поле заполнено верно — выделите его зеленым (но не закрывайте поле ввода сообщением об ошибке).

Эта логика должна предотвратить любые неприятности с валидацией.

5. Не блокируйте доступ к аккаунту из-за неподтвержденной электронной почты

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

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

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

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

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

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

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

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

7. Вход через социальные сети должен быть нормой

Я не знаю, почему не становится больше сайтов, предлагающих единый вход в систему? Для простых подписок, таких как интернет-магазин или пробные версии продуктов, проще всего зарегистрироваться через facebook / twitter / google. Однако в этом процессе есть дополнительные правила, которым вы должны следовать:

1. Зона покрытия

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

2. Приоритезация

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

3. Объединение

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

4. Напоминание

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

5. Приватность

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

8. Клавиша Tab должна направлять к следующему полю

Звучит просто, но иногда Tab не приводит пользователя к следующему полю. Ожидается же обратное. Протестируйте свою форму и посмотрите, выделена ли какая-либо ссылка или тег помощи при вводе. Используйте атрибут tab-index для помощи.

Ниже несколько дополнительных предложений в зависимости от ваших систем и требований:

• Электронная почта пользователя должна быть идентификатором пользователя для входа в систему

Я смотрю на вас, сайты, которые используют имена пользователей. Конечно, сегодня мне нравится имя «ThorButOaks69», но запомню ли я его с бесчисленными комбинациями прописных, строчных и цифровых символов? Я помню свой адрес электронной почты, но не имя пользователя. Позвольте мне выбрать имя пользователя после входа в систему!

• После успешной регистрации отправьте приветственное письмо

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

Правила для входа в систему

9. Примените встроенную проверку для поля электронной почты

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

Просмотр базы данных — это рискованная игра.  В нем применяется примечание по безопасности из правила 6 про регистрацию.

10. Переносите электронную почту из поля ввода при входе в поле ввода сброса пароля

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

11. Предложите сброс пароля после третьего неправильного ввода

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

 12. Отправьте ссылку для сброса пароля, а не пароль, сгенерированный системой.

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

1. Пользователь выбирает сброс пароля
2. Пользователь получает в электронном письме ссылку для сброса пароля
3. Пользователь кликает по ссылке
4. Пользователь вводит новый пароль дважды
5. Пользователь получает доступ к аккаунту

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

Это приводит нас к правилу 13.

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

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

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

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

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

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

15.  Система единого входа как вариант входа в систему

Опять же, должно быть нормой. Должны применяться стандартные правила пункта 7 со следующими добавлениями:

1. Если пользователь пытается использовать систему единого входа с адресом электронной почты, которого нет в системе, укажите это и спросите, хочет ли он создать учетную запись с этим адресом.
2. Если пользователь пытается использовать единый вход с существующим адресом электронной почты, выполните аутентификацию и добавьте единый вход в учетную запись. При успешном входе сообщите об этом пользователю.
3. Старайтесь не давать более 3-х вариантов единого входа — это больше запутает пользователя, чем поможет. Я не помню, пользовался ли я Facebook, Google или Twitter или чем-то еще.
4. В системах единого входа для мобильных приложений — НЕ выходите из приложения, чтобы открыть facebook / google в стандартном браузере и провести аутентификацию. У большинства пользователей есть эти приложения — используйте их. Я не хочу вводить комбинацию имени пользователя и пароля только для того, чтобы уберечь себя от ввода другой комбинации адреса электронной почты и пароля.

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

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

Для двухэтапной аутентификации лучшими комбинациями являются:

1. Электронная почта + телефон
2. Электронная почта + дополнительная электронная почта
3. Электронная почта + push-уведомление

По моему опыту, самый быстрый вариант — это электронная почта + push. Это работает всегда. Пусть все будет просто. Аутентификатор Майкрософт добавляет глупый шаг в виде ввода кода, сгенерированного системой. Если у меня есть доступ к обоим устройствам (входа и проверки), мне просто нужно нажать на подтверждающее сообщение. Не заставляйте меня разгадывать судоку!

17. Поймите когнитивную нагрузку пользователя для более глубоких маршрутов и разработайте «выходы» для ошибок

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

18. Постоянный вход в систему должен быть нормой для нечувствительных сайтов

Если ваш сайт не содержит конфиденциальной информации, разрешите постоянный вход в систему. Это особенно актуально для сайтов интернет-магазинов. Постоянный вход в систему позволяет пользователю вспомнить сайт и действия, которые он совершил. Вы являетесь UX-преступником, если автоматически выходите из системы через определенное время. Сессия может истечь, но действия пользователей (например, добавленные в корзину предметы) сохранятся. Вы можете ограничить доступ к личной информации с помощью запроса пароля вне зависимости от срока действия сеанса. Amazon является прекрасным примером: вы частично вошли в систему, и аутентификация запрашивается только тогда, когда вам нужно получить доступ к личной информации.

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

Правила для пути входа в систему

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

19. Не заставляйте пользователя входить в систему, если он может выполнить свои действия и без входа

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

1. Запросите электронную почту
2. Проверьте, существует ли почта в системе, пока пользователь переходит к следующему шагу. Если у пользователя есть учетная запись, предложите ему войти в систему с сообщением, что это упростит его дальнейшие действия (проверьте, привязаны ли к учетной записи адрес доставки и платежная карта).
3. Если пользователь желает войти в систему, откройте модальное окно с формой и параметрами единого входа. Поскольку вы уже знаете, использовал ли пользователь систему единого входа в последний раз, разместите эту опцию. Порядок должен быть таким:

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

4. Если попытки входа в систему не увенчались успехом, вежливо сообщите пользователю, чтобы он не беспокоился и что вы свяжете транзакцию с его учетной записью (и сделайте это!). Пользователь должен выйти из процесса покупки плавно. Убедитесь, что он закрывает модальное окно самостоятельно. Если вы закроете модальное окно сами, это его разозлит.

20. После входа в систему, если у пользователя есть незавершенные элементы из предыдущего сеанса, ЗАМЕНИТЕ их на новые!

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

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

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

21. Быстрое создание учетной записи после завершения основного пути

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

22. Дайте возможность посмотреть статус заказа без запроса логина

Пользователь может проверить статус своего заказа двумя способами:

1. Ссылка в электронном письме. Ссылка на статус заказа должна отправляться с каждым электронным письмом с подтверждением заказа и письмом с его обновлением.
2. Форма на сайте, позволяющая искать заказ по комбинации его номера + электронная почта

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

23. Брошенные корзины должны быть доступны по ссылке без входа в систему

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

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

Большинство пользователей ждут, что они будут регистрироваться и входить в систему так, как описано в статье. Как продуктовые менеджеры, мы ограничены технологическим пространством для проведения изменений. Но могу вас заверить, что внедрение правил, рассмотренных в статье, улучшит UX вашего сайта или приложения и увеличит конверсию. Протестируйте нововведения методом A/B и посмотрите, как отреагируют ваши пользователи.

Спасибо за внимание!