Вход в систему: популярные UX-паттерны

Что за дела! Кто это на той домашней странице? Вернувшийся пользователь? Ого! Похоже, нам нужно разработать шаблон входа в систему.

1. Терминология: Log in vs Login

Я часто путаю эти понятия, и не сомневаюсь, что допустила эту ошибку где-то в статье, но log in (войти) и login (вход) — это не одно и то же.

Войти (log in) — это глагол, например, "Пожалуйста, войдите (log in) на сайт коллекционеров камней".

Логин (login) — существительное, например, "Здесь находится страница входа (login) на сайт коллекционеров камней".

Итак, слон в комнате: если мы используем “sign up” (зарегистрироваться), почему бы нам просто не написать “sign in” для обозначения входа? Некоторые сайты действительно используют этот термин. Я же избегаю его, потому что он настолько сильно похож на “sign up”, что пользователь может перепутать эти два понятия. “Log in” отличается настолько, что вы точно не запутаетесь.

Откуда взялась фраза "log in"?

Капитаны использовали бревна (лаги — log), привязанные к веревке, для измерения скорости судна. Они записывали результаты измерений в свой бортовой журнал (log book), и этот процесс назывался logging in, по аналогии с sign in (отметиться в документе или книге посетителей). Затем фраза была адаптирована для цифровых аккаунтов.

2. Стандартный сценарий входа в систему

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

Примечание: Это не универсальная блок-схема, а скорее отправная точка для вашей собственной диаграммы.

3. Что такое технология единого входа (SSO)?

В двух словах, SSO — это когда вы используете Facebook, Google и т.д. для входа в свой аккаунт.

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

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

Вы можете прочитать больше о SSO и регистрации в этой статье.

4. Шаблоны входа

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

4.1. Базовый

Базовый экран входа содержит поля для ввода email (или другого уникального идентификатора, например, имени пользователя или номера телефона) и пароля.

4.2. Сначала SSO

Опции SSO располагаются сверху, а вариант "Войти с помощью email" под ними. Если вы выберете его, вы увидите базовый экран из первого пункта. В идеале у вас должно быть менее 3 SSO-опций.

Некоторые продукты выбирают подход "только SSO" и могут не иметь опции “Войти с помощью email”. Однако так делать не рекомендуется, поскольку некоторые пользователи до сих пор не доверяют SSO.

4.3. Гибридный

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

4.4. Пошаговый вход в систему

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

4.5. Волшебная ссылка

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

1. Вы вводите свой email, затем нажимаете кнопку отправить.
2. Вам приходит письмо со ссылкой.
3. Когда вы кликаете по ней, вы проходите аутентификацию и входите на сайт.

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

4.6. Вход в одно касание от Google

Мне очень нравится функция Google One Tap Login (автоматический вход), поскольку она значительно упрощает возвращение на сайт. Если пользователь вошел в свой Google-аккаунт и покинул сайт / приложение, а потом вернулся, на экране появится небольшое окошко с вопросом, хочет ли он войти в систему. Пользователю даже не придется нажимать на кнопку входа.

Обычно это решение используется в сочетании с SSO или гибридным дизайном.

Чтобы Google One Tap работал, необходимы следующие условия:

• пользователь вошел в свой Google-аккаунт
• пользователь ранее дал разрешение приложению на использование профиля своей учетной записи

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

5. Лейаут

Существует несколько вариантов лейаута страницы входа в систему, которые вы можете использовать.

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

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

5.1. Полностраничный лейаут с маркетинговым контентом

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

Такой подход используют Facebook, edX, Flaticon.

5.2. Полностраничный лейаут с разделенным экраном

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

Такого подхода придерживается eBay.

5.3. Полностраничный лейаут с формой в центре

Форма входа в систему с выравниванием по центру — классическое решение.

Такой подход выбирают Amazon, Kiva.

5.4. Модальное окно

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

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

Такой подход используют Twitter, Pinterest, Medium, Etsy.

5.5 Пошаговый вход

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

А на второй — поле для ввода пароля. Вы также должны показать здесь их предыдущий ответ, чтобы убедиться, что они вводят правильный пароль для правильного email.

Такое решение использует Google.

6. Обратная связь

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

6.1. Предварительная обратная связь

Предварительная обратная связь — это обратная связь, предоставляемая пользователю до того, как он отправит свои данные. Система выполняет базовую проверку, чтобы узнать, достаточно ли надёжен пароль и действителен ли адрес электронной почты (например, содержит ли он символ @ или ".").

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

6.2. Последующая обратная связь

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

Вы можете предоставить обратную связь разными способами.

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

Подход 2: Сообщить пользователю, что проблема связана с его паролем / адресом электронной почты.

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

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

Другой пример — сайт знакомств под названием Amy Markson не хочет, чтобы ревнивые супруги могли проверить, есть ли у их партнеров аккаунт.

Кроме того, вы можете ограничить количество попыток входа.

7. Безопасность

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

7.1. Контрольные вопросы

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

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

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

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

7.2. Двухфакторная аутентификация (2FA)

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

Существует множество различных способов настройки 2FA. Вот несколько из них:

• Yubikey. Физическое устройство, которое можно подключить к компьютеру для подтверждения личности.

• Код аутентификации. Приложение для аутентификации, например, аутентификатор Google, может сгенерировать временный уникальный код, который пользователь должен ввести на платформе.

• Одноразовый пароль (OTP). Пользователи получают в SMS или по электронной почте код, который они должны ввести на платформе для подтверждения своей личности.

• Аутентификация через приложение. Некоторые мобильные приложения можно использовать для аутентификации, когда вы входите в систему через браузер. Обычно браузер показывает QR-код, который затем сканируется в приложении, что позволяет авторизовать пользователя. (Whatsapp использует этот подход для WhatsappWeb).

7.3. Контрольный email

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

7.4. CAPTCHA и reCAPTCHA

CAPTCHA расшифровывается как Completely Automated Public Turing test to tell Computers and Humans Apart (Полностью автоматизированный публичный тест Тьюринга для различения компьютеров и людей) и используется в формах входа для того, чтобы определить, кто пытается войти в систему — человек или бот. Капча дает пользователю задание, которое может выполнить только человек. Эти задания принимают различные формы — от распознавания изображений до отметки чекбоксов.

К счастью, специалисты из Google создали reCAPTCHA V3, так что вашим пользователям больше не придется отвечать на вопросы о том, на каких картинках есть велосипеды 😂.

8. Стандартные поля формы входа

Ниже приведены некоторые стандартные поля формы входа в систему.

8.1. Уникальные идентификаторы

Это данные, которые отличают вас от других пользователей. К ним относятся email, номер телефона, номер социального страхования, номер налогоплательщика, имя пользователя и т.д. Каждая учетная запись должна иметь как минимум один уникальный идентификатор. Хотя имена пользователей не являются "уникальными" в юридическом смысле, их также можно считать уникальными идентификаторами.

8.1.1. Email

Email — это, пожалуй, самый популярный уникальный идентификатор, используемый большинством платформ.

8.1.2. Номер телефона

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

8.1.3 Имя пользователя

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

8.2. Пароль

Пароль — последовательность букв и / или цифр, которую знает только сам пользователь (или его менеджер паролей, или стикер над его столом 🤪).

8.3. Остаться в системе

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

9. Доступность

Несколько слов о доступности и формах.

• Убедитесь, что пользователь может перемещаться по форме с помощью клавиши Tab.
• Убедитесь, что существует более одного способа нажать на поле ввода (клавиша Tab / мышь).
• Убедитесь, что ваши поля ввода достаточно большие, чтобы по ним легко было попасть пальцем на мобильных устройствах.
• Убедитесь, что цвета соответствуют стандартам WCAG 2.0 AAA.
• Не используйте только цвет для обратной связи. Как минимум, вы должны также добавить текстовое сообщение и иконку.
• Подписи полей ввода должны оставаться видимыми всегда.

Подробнее читайте здесь.

10. Нужно ли вам перестраивать текущий процесс входа в систему?

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

Вот тесты, которые помогут вам понять, нужно ли менять текущий сценарий.

Тест 1: Пользовательское тестирование

Попросите участника войти в систему и понаблюдайте, какие действия вызывают у него затруднения. После этого спросите, что было самым сложным и сбило его с толку. Проведите этот тест 4-6 раз с разными участниками.

-> Если ни один из них не запутался и вошел в систему без посторонней помощи, тест пройден!

Тест 2: % входа в систему

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

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

[# пользователей, которые вошли в систему] ÷ [# пользователей, которые перешли на страницу входа] * 100

-> Если средний процент входа в систему выше X%*, тест пройден.

ПРИМЕЧАНИЕ: учитывайте не количество входов, а количество людей, которые вошли в систему. Один и тот же человек может войти в систему 1000 раз за месяц, что исказит результаты.

ПРИМЕЧАНИЕ: трудно определить разницу между ошибочным переходом на страницу входа и намеренным переходом с дальнейшим отказом от входа.

* Трудно точно сказать, каким должен быть "X", поскольку он может меняться в зависимости от отрасли и услуги. Вы, как компания, должны определить, что такое "Х" для вас. Цель всегда должна быть 100%.

Желаю, чтобы пользователи возвращались к вам как можно чаще! 😉