Дизайн входа и регистрации в мобильных приложениях: сделайте шаг создания аккаунта понятным
Практическое руководство по дизайну входа и регистрации в мобильных приложениях: когда нужен аккаунт, как создавать удобные формы и полезные способы восстановления доступа.
Экран входа невелик, но сильно влияет на опыт: он может помочь вернуться к задаче или прервать человека до того, как он поймёт, зачем нужен аккаунт. Хороший дизайн мобильного аккаунта рассматривает аутентификацию как часть пути в продукте, а не как препятствие, которое каждый обязан преодолеть при запуске.
Сценарий должен ясно объяснять свою цель и варианты выбора, запрашивать только нужные сейчас сведения и спокойно вести дальше, если что-то пошло не так. Детали важны и для новых посетителей, и для вернувшихся пользователей, которые могли забыть выбранный способ входа.
Главные выводы
- Просите создать аккаунт в первой значимой точке, где он даёт понятную пользу или действительно необходим.
- Объясняйте каждый способ входа привычными словами и чётко отделяйте создание нового аккаунта от доступа к существующему.
- Делайте формы короткими, ясно подписывайте поля и позволяйте менеджерам паролей и вставке работать как ожидается.
- Описывайте ошибки текстом и предлагайте полезный следующий шаг, сохраняйте корректно введённые данные и давайте восстановить доступ без обвинений.
Выберите момент, когда аккаунт становится полезным
Начните с задачи, ради которой человек пришёл. Если основные функции работают без аккаунта, дайте сначала изучить продукт и предложите вход при переходе к функции, которой нужны сохранённые настройки, доступ с разных устройств, совместная работа или транзакция. Рекомендации Apple по дизайну интерфейсов советуют по возможности откладывать вход и объяснять пользу, если аккаунт обязателен.
Запрос в контексте понятнее, чем барьер сразу при запуске. Например, приложение для чтения может дать просмотреть книги, а затем попросить создать аккаунт при выборе синхронизации списка чтения. Если аккаунт необходим с самого начала, объясните причину до показа полей. Объяснение должно быть конкретным и соразмерным: «Создайте аккаунт, чтобы сохранять проекты и открывать их на другом устройстве» полезнее, чем «Присоединяйтесь к нашему сообществу».
- Отделяйте обязательные сведения от необязательных данных профиля.
- Для гостевого оформления заказа или разовой задачи подумайте, можно ли отложить создание аккаунта до получения непосредственной пользы.
- После успешной аутентификации возвращайте человека к действию, которое он собирался завершить.
Сделайте варианты входа понятными и узнаваемыми
Человек должен понимать, создаёт ли он аккаунт или возвращается в существующий. Дайте двум путям разные подписи, визуально выделите основное действие и разместите альтернативные способы так, чтобы их можно было сравнить без перегрузки экрана. При необходимости используйте названия поставщиков и утверждённый платформой вид кнопок; одна общая подпись «Продолжить» не объясняет, что произойдёт дальше.
Предлагайте только те способы, которые продукт поддерживает и может сопровождать. Электронная почта, ключ доступа или вход через платформу могут подходить разной аудитории. Показывайте их как варианты, не утверждая, что один способ всегда самый простой или безопасный. Объясните, если нужны дополнительные сведения.
Вернувшиеся пользователи могут не помнить свой способ входа. Сделайте восстановление и другие варианты входа заметными, объясните, что делать, если адрес электронной почты связан с другим способом. Подсказки по связыванию аккаунтов помогают сохранить доступ к существующему аккаунту.
Делайте формы короткими и совместимыми с инструментами пользователей
Запрашивайте только поля, необходимые для создания аккаунта или доступа к нему. Используйте постоянные подписи, а не только текст-подсказки внутри полей, выбирайте подходящий тип ввода и клавиатуру, ясно показывайте следующее действие. Если для регистрации нужны разные сведения, группируйте связанные поля и отложите необязательные настройки до перехода в продукт.
Аутентификация должна работать с автозаполнением и менеджерами паролей. Используйте стандартные названия и семантику полей, избегайте нестандартного поведения, мешающего подставлять учётные данные. Не блокируйте вставку пароля: человек может пользоваться менеджером паролей или другим инструментом. Рекомендации WCAG предусматривают возможность заполнения полей входа браузерами и сторонними менеджерами паролей.
Поведение различается между устройствами и менеджерами паролей, поэтому проверяйте сценарий на поддерживаемых платформах и разрешайте исправлять данные вручную. После неудачной попытки по возможности сохраняйте полезные несекретные значения, например адрес электронной почты.
- Используйте видимую подпись вроде «Адрес электронной почты» и понятную подпись для пароля.
- При необходимости позволяйте показать или проверить пароль, но не делайте эту кнопку единственным способом исправить ввод.
- Разместите основную кнопку рядом с полями и назовите её по действию, например «Создать аккаунт» или «Войти».
Продумайте ошибки, восстановление и следующий визит
Полезное сообщение об ошибке указывает затронутое поле или неудавшийся шаг словами и объясняет, как продолжить. «Что-то пошло не так» недостаточно, если адрес электронной почты имеет неверный формат или поле пустое. Критерий успешности WCAG 2.2 3.3.1 требует определять обнаруженные ошибки ввода и описывать их текстом; один цвет или значок не должен передавать всё сообщение.
Используйте нейтральный тон и размещайте подсказку для поля рядом с ним. Например, при неверном формате адреса можно написать: «Введите адрес электронной почты в формате [email protected]». При неудачном входе продукт может сказать: «Не удалось войти с этими данными. Проверьте адрес и пароль или сбросьте пароль». Не раскрывайте конфиденциальные сведения об аккаунте в сообщениях об ошибках; подбирайте формулировки с учётом конфиденциальности продукта и защиты от злоупотреблений.
Объясните, что происходит после запроса сброса пароля, дайте вернуться ко входу и помогите найти ранее использованный способ. При следующих посещениях ясно показывайте состояние входа и путь к настройкам аккаунта, выходу и помощи. Если аккаунт можно создать в приложении, сделайте удаление аккаунта легко находимым.
- Связывайте ошибку с соответствующим полем и делайте её заметной без опоры только на цвет.
- Размещайте действия восстановления рядом с формой входа и не заставляйте без необходимости начинать всё сначала.
- Проверяйте состояния первого и повторного использования, включая изменившиеся адреса и недоступные способы входа.
Практическая проверка сценария аккаунта
Пройдите сценарий как новый пользователь, вернувшийся пользователь и человек, восстанавливающий доступ. Проверяйте экраны в контексте. Библиотека мобильных паттернов помогает командам сравнивать, как формы организуют поля, подписи и действия.
- Можно ли получить полезный результат без входа, если аккаунт не обязателен?
- Объясняет ли экран, зачем нужен аккаунт и какие сведения обязательны?
- Может ли человек различить регистрацию, вход, альтернативные способы и восстановление доступа?
- Остаются ли подписи полей видимыми и работают ли автозаполнение и вставка учётных данных?
- Называют ли ошибки проблему словами, сохраняют ли полезный ввод и предлагают ли следующий шаг?
- Возвращается ли человек после успеха к начатой задаче?
Частые вопросы
Должно ли мобильное приложение требовать аккаунт до знакомства с продуктом?
Только если аккаунт действительно нужен для основной функции. Если люди могут сначала просмотреть или попробовать продукт, дайте им это сделать и предложите вход, когда он даст ясную пользу или потребуется для конкретного действия.
Следует ли разрешать вставку и автозаполнение менеджером паролей в полях пароля?
Да. Используйте узнаваемые подписи и семантику полей, не блокируйте вставку или автозаполнение. Эти возможности помогают людям пользоваться привычными инструментами для учётных данных; поведение может различаться на устройствах и в менеджерах паролей, поэтому проверяйте сценарий на поддерживаемых платформах.
Что должно быть в сообщении об ошибке входа?
Опишите проблему словами, укажите затронутое поле или шаг и предложите практическое следующее действие. Сохраняйте нейтральный тон и не раскрывайте конфиденциальные данные аккаунта.
