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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ао геомир

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

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