Проектируем авторизацию в приложении по номеру телефона

Авторизация по номеру телефона используется в подавляющем большинстве e-com приложений, и через неё проходит основная доля клиентов, которые совершают заказ. Несмотря на кажущуюся простоту, процесс этот отличается от сервиса к сервису, и есть множество деталей, которые стоит учитывать, чтобы клиенту было удобно
Станислав Хрусталёв
Станислав Хрусталёв
Автор Hard Client. Пишу об управлении клиентским опытом. Собираю лучшие CX-практики. Оцениваю сервисные модели компаний

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

Структура статьи

Статью я разбил на смысловые блоки в соответствии с этапами клиентского пути и функциональными элементами:

Общие моменты

5 гайдлайнов

Здесь я собрал несколько пунктов, которые важны, но не вписываются в следующие, более узконаправленные разделы.

Авторизация не блокирующая

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

Пример ❌ Кофемания

Единый процесс авторизации

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

Пример ✅ Wildberries

Без лишнего шума

Лучше вывести процесс ввода номера на отдельный экран. Не размещайте поле ввода наравне с прочими элементами неавторизованной зоны: это может размыть фокус внимания.

Пример ❌ Lamoda

Без captcha

По возможности откажитесь от необходимости ввода captcha и reCaptcha. Как минимум в случаях, когда клиент не демонстрирует какое-то странное поведение.

Пример ❌ Sela

Альтернативные способы авторизации

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

Пример ✅ SimpleWine

Заголовок формы ввода номера

10 гайдлайнов

Достаточно большой

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

Пример ❌ Baon

Содержит призыв к действию

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

Пример ✅ ВкусВилл

Подсвечивает ценность

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

Пример ✅ Додо Пицца

Конкретизация ценности

Если вы мотивируете клиента авторизоваться с помощью бонусов, хорошо, если вы подсветите не абстрактные «бонусы», а конкретное число, которое он получит.

Пример ✅ Эльдорадо

Сопровождается пояснением

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

Пример ✅ Ecomarket

Отталкивается от позитива

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

Пример ❌ Baon

Highlight приватности

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

Пример ✅ Broniboy

Highlight скорости процесса

Если процесс авторизации в вашем приложении простой и не займёт много времени, подсветить этот факт заранее также может быть полезно.

Пример ✅ Улыбка Радуги

Без дублирования посыла

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

Пример ❌ Магнолия Доставка

Консистентная тональность

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

Пример ❌ Rostic’s

Placeholder поля ввода номера

11 гайдлайнов

Добавлен в поле

Для облегчения понимания placeholder в поле ввода номера телефона всё же лучше добавить.

Пример ❌ igooods

Не дублирует заголовок

Если в заголовке вы уже призвали пользователя ввести номер телефона, дублировать этот посыл в placeholder’е может быть излишне.

Пример ❌ TSUM Collect

Отличается от вводимого текста

Текст placeholder’а должен отличаться от вводимого текста, чтобы не ввести пользователя в заблуждение. Чаще всего для этого его делают полувыцветшим.

Пример ✅ Маркет Деливери

Выровнен по вертикали

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

Пример ❌ Street Beat

В формате номера телефона

Хорошая практика — подсветить в placeholder’е формат ввода номера: это позволит сделать интерфейс более интуитивным.

Пример ✅ Каталог КБ

Цифры в номере placeholder’а

Часто после +7 в качестве символов на российском рынке можно встретить нули либо девятки.

Пример ✅ Дикси

Цифры единообразны

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

Пример ❌ Шаверма по-питерски

Использование прочих символов в номере

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

Пример Baon

Placeholder – только маска?

Встречаются кейсы, когда вместо номера в placeholder’е оставляют только маску форматирования. Что думаете по этому поводу?

Пример Буше

Без хайлайта обязательности

Если на экране у вас есть лишь одно поле, которое нужно заполнить, подсвечивать факт обязательности в placeholder’е с помощью звездочки излишне.

Пример ❌ Столплит

Постепенное исчезновение placeholder’а

Если в качестве placeholder’а используется номер телефона, интересная механика – отображать оставшиеся символы placeholder’а по мере ввода номера пользователем.

Пример ✅ ВкусВилл

Активация поля с номером

6 гайдлайнов

Автоактивация

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

Пример ✅ М.Видео

Код страны введён по умолчанию

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

Пример ✅ МегаМаркет

Хайлайт страны флагом

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

Пример ✅ No One

Наличие первой девятки?

Пункт дискуссионный: хотя первая 9 и есть во всех российских номерах, начать ввод с 916 может быть привычнее, чем с 16.

Пример Утконос

Поле выделяется

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

Пример ✅ Детский мир

Поле не выглядит неактивным

И уж точно поле не должно выглядеть так, будто оно неактивно и не поддерживает ввод данных.

Пример ❌ Бронницкий Ювелир

Ввод номера телефона

16 гайдлайнов

Без повторного ввода: UserDefaults

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

Пример ✅ Wildberries

Без повторного ввода: Device ID

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

Пример ✅ Ozon

Без переключения раскладки

Не отображайте символьную раскладку при вводе номера телефона. Не заставляйте пользователя отдельно её переключать.

Пример ❌ Буквоед

Фиксация раскладки

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

Пример ✅ Яндекс.Маркет

Автоподстановка сохранённых данных

Промаркируйте поле ввода, как phone number, на уровне среды разработки, чтобы клиент мог вставить сохранённый на девайсе номер телефона в одно касание.

Пример ✅ Burger King

Без разных типов данных

Лучше не объединять ввод номера телефона, email’а, номера карты лояльности и других данных в одном поле: это делает его автозаполнение невозможным.

Пример ❌ Lamoda

Тип данных корректен

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

Пример ❌ Лента

Использование меню над клавиатурой

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

Пример ❌ Flor2U

Код страны vs. вставка номера

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

Пример ✅ Sunlight

Форматирование ввода

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

Пример ❌ belle you

Ограничение по числу символов

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

Пример ❌ Rendez-Vous

Курсор отображается при вводе

Базовый момент: отображайте курсор при вводе номера телефона. Его отсутствие может дезориентировать пользователя.

Пример ❌ KDV Online

Быстрая очистка поля

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

Пример ✅ РИВ ГОШ

Видимость кнопки очистки

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

Пример ✅ Зоозавр

Кнопка очистки визуально вторична

Функция кнопки очистки ввода номера телефона вторична относительно целевого действия. Это должно отражаться и в том, как она выглядит.

Пример ❌ Sunlight

Стирание символов форматирования

При стирании номера вручную символы форматирования лучше удалять автоматически, чтобы не создавать лишних действий для клиента.

Пример ✅ Галамарт

Кнопка подтверждения номера

17 гайдлайнов

Проверка при нажатии на кнопку

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

Пример ❌ METRO

Достаточно большая

Сделайте кнопку достаточно большой, чтобы клиент не испытывал затруднений, пытаясь нажать на неё.

Пример ❌ Буше

Легко дотянуться

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

Пример ❌ SimpleWine

Активна по умолчанию?

Как считаете, стоит ли делать кнопку активной по умолчанию, когда номер еще не введён?

Пример СберМаркет

Без общего текста

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

Пример ❌ Утконос

Целевое действие понятно

Убедитесь, что целевое действие из текста кнопки будет понятно клиенту и не вызовет вопросов.

Пример ❌ Духи.рф

Управление ожиданиями в тексте

В тексте кнопки можно подсветить следующий шаг: что произойдёт после того, как клиент нажмёт на неё?

Пример ✅ SimpleWine

Highlight типа проверки

Хорошей практикой будет не просто рассказать про следующий шаг, а ещё и подсветить тип проверки: будет это SMS или входящий звонок.

Пример ✅ FlowWow

Текст vs. следующий шаг

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

Пример ❌ ЦЕХ85

Подсказка, если номер не введён

Если номер телефона ещё не введён, текст кнопки может содержать призыв это сделать.

Пример ✅ Stockmann

Размер текста vs. кнопки

Спроектируйте кнопку так, чтобы текст соотносился по размеру с контейнером: не был слишком мелким или слишком крупным.

Пример ❌ ВсеИнструменты.ру

Кнопка не перекрывается клавиатурой

Если кнопка перекрывается экранной клавиатурой при вводе, для перехода к следующему шагу придется отдельно её скрывать. А это лишнее действие для клиента.

Пример ❌ Иль де Ботэ

Кнопка — часть клавиатуры

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

Пример ✅ Эльдорадо

Без дублирования кнопки

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

Пример ❌ Магнит

Вход vs. регистрация

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

Пример ❌ Яндекс.Маркет

Кнопка — отдельный объект

Кнопку на экране лучше реализовать в виде отдельного объекта. Лучше если она не будет прилипать и не будет являться составной частью поля ввода.

Пример ❌ Холодильник.ру

Выбор типа проверки номера

Встречаются кейсы, когда клиенту предлагают выбрать способ проверки: по звонку или по SMS. Как считаете, стоит ли давать такой выбор?

Пример Gipfel

Типы проверки номера

7 вариантов

Получение кода по sms

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

Пример ✅ М.Видео

Получение кода через push

Способ даже удобнее, чем sms, так как приложение может само обрабатывать входящий push, вставлять его и проводить проверку: клиенту вообще не требуется ничего делать.

Пример ✅ Мой Ашан

Проверка через Telegram

Некоторые сервисы проверяют подлинность номера через Telegram: нужно лишь активировать бота и поделиться контактами в один тап.

Пример ✅ Шаверма по-питерски

Использование FaceID

Авторизацию можно упростить за счет биометрии: подключив FaceID, клиенту при входе в аккаунт не потребуется вводить номер: достаточно будет лишь взглянуть на смартфон.

Пример ✅ Ozon

Последние цифры номера входящем звонке

Этот метод менее удобен: звонок более заметен, чем sms (а это часто может быть неудобно), клиенту приходится запоминать цифры номера и вводить их вручную.

Пример AliExpress

Проверка через код от автоответчика

Этот способ ещё менее удобен, так как приходится не только запоминать код, но и отвечать на звонок. А это удобно далеко не во всех случаях.

Пример FARFOR

Вход по паролю

Это устаревающая и менее удобная практика. Часто пароль длиннее, чем код, его можно легко забыть и шанс того, что он будет сохранён в KeyChain у клиента — далеко не стопроцентный.

Пример Авито

Подтверждение отправки sms

14 гайдлайнов

Предусмотрено

Базовый момент: при переходе к шагу ввода кода имеет смысл подсветить факт того, что sms было отправлено.

Пример ❌ Gipfel

Визуально вторично

Текст подтверждения — не ключевой элемент экрана, поэтому не должен визуально «кричать».

Пример ❌ Духи.рф

Однозначно

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

Пример ❌ Улыбка Радуги

Содержит номер телефона

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

Пример ❌ Леонардо

Номер выделен

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

Пример ✅ DNS

Номер форматирован

Желательно, чтобы номер телефона был форматирован. Отсутствие форматирования ухудшит восприятие и затруднит проверку.

Пример ❌ Askona

Номер не разбит на части

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

Пример ❌ Adamas

Номер не скрыт

Скрывать номер телефона, на который отправлен код, не совсем целесообразно, так как клиент не сможет его проверить.

Пример ❌ Бронницкий Ювелир

Возможность изменить номер

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

Пример ✅ СберМаркет

Иллюстрация

Текст подтверждения отправки sms можно дополнительно проиллюстрировать, подсветив формат сообщения.

Пример ✅ Sunlight

Highlight срока доставки

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

Пример ✅ Henderson

Без срока действия кода

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

Пример ❌ Novex

Без указания числа символов

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

Пример ❌ Uzum Market

Без лишних слов

Чем меньше текста, тем лучше. Если клиент и так уже ввёл свой номер, слово «телефона» в подтверждении можно опустить.

Пример ✅ Кофемания

SMS с проверочным кодом

18 гайдлайнов

Сообщение приходит быстро

Отправка sms по возможности должна осуществляться моментально, без каких-либо значимых задержек для пользователя.

Пример ✅ СберМаркет

Отправитель понятен клиенту

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

Пример ❌ Вкусно – и точка

Отправитель — название бренда

Чтобы избежать проблем с восприятием, в качестве отправителя sms лучше указать название бренда.

Пример ✅ Sunlight

Код в начале текста sms

Код лучше разместить в начале текста, чтобы он был виден в уведомлении, когда sms будет получено, и клиент смог увидеть его без необходимости открывать сообщение.

Пример ✅ Мой Ашан

Код корректно распознается

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

Пример ❌ Триал-Спорт

Пояснение к коду

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

Пример ❌ Магнолия

Без транслитерации

Хотя транслитерация и позволяет увеличить число символов в сообщении, лучше отправлять sms с более кратким текстом, но на языке клиента. Это позволит облегчить восприятие.

Пример ❌ Wildberries

Без специфических терминов

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

Пример ✅ Золотое Яблоко

Без сокращений

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

Пример ❌ IDOL

Адаптация под контекст целевого действия

Имеет смысл подсветить не только что это проверочный код, но и контекст целевого действия: для чего именно он используется.

Пример ❌ BAON

Адаптация под контекст источника запроса

Текст sms лучше адаптировать под источник запроса и пояснять, для входа куда именно используется код.

Пример ✅ Sokolov

Адаптация под стадию customer journey

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

Пример ❌ Flor2U

Без дублирования названия сервиса

Название сервиса имеет смысл дублировать, только если оно транслитерировано в названии отправителя. Дублировать его в тексте один-в-один нет смысла.

Пример ❌ Магнит

Без перехода на сайт

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

Пример ❌ Cozy Home

Аспект безопасности

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

Пример ✅ М.Видео

Сообщение о безопасности вторично

При этом сообщение о безопасности не стоит выносить, как основной посыл в тексте. Оно должно лишь дополнять основной посыл.

Пример ✅ Мой SPAR

Без согласия с политикой

Редко в sms также можно встретить и согласие с условиями программы лояльности. Текст этот уместнее разместить на первом шаге процесса авторизации.

Пример ❌ Подружка

Highlight срока действия?

Как считаете, насколько ценно и полезно будет клиенту узнать в sms, в течение какого срока будет действовать проверочный код?

Пример FlowWow

Ввод проверочного кода

27 гайдлайнов

На отдельном экране

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

Пример ❌ Respect

Полноэкранный интерфейс

Ввод кода лучше реализовать в формате полного экрана, чтобы не отвлекать клиента от ввода фоновыми элементами, как в случае с попапом.

Пример ❌ ЦУМ

Призыв к действию в заголовке

Заголовок можно выполнить в формате призыва к действию — вводу проверочного кода.

Пример ✅ Спортмастер

Без дублирования заголовка

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

Пример ❌ Л’Этуаль

Код числовой

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

Пример ❌ Жизньмарт

Автоактивация поля

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

Пример ❌ Пятёрочка

Автоподстановка кода

Поле должно быть промаркировано, как one-time code, на уровне среды разработки. Это позволит клиенту ввести код в один тап из автоподсказки при получении sms.

Пример ✅ Спортмастер

Цифровая раскладка клавиатуры

Как и в случае с номером телефона, лучше фиксировать клавиатуру при вводе кода именно на цифровой раскладке: остальные раскладки будут нерелевантны.

Пример ❌ Буквоед

Стандартное текстовое поле?

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

Пример 12STOREEZ

Слоты для ввода кода

Гораздо чаще для задачи ввода кода используются слоты: они и глазу приятнее, и своим видом подсвечивают, сколько символов будет в коде.

Пример ✅ Flor2U

Размер слотов

Свободного пространства при вводе кода много, поэтому можно не мельчить и сделать слоты достаточно большими. 50-70% пространства по ширине будет нормально.

Пример ✅ Burger King

Поле выглядит активным

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

Пример ❌ Леонардо

Без счётчика символов

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

Пример ❌ Sokolov

Количество символов в коде

По возможности не мучайте клиента необходимостью вводить длинный проверочный код. Четырёх символов будет достаточно.

Пример ❌ Юла

Горизонтальное центрирование

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

Пример ❌ Fitness Formula

До поля легко дотянуться пальцем

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

Пример ❌ Леонардо

Размер поля vs. контента

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

Пример ❌ Самокат

Наличие курсора

При активации поля должен появляться курсор. Иначе есть риск, что клиент не поймёт, что оно активировано.

Пример ❌ МегаМаркет

Позиция курсора по умолчанию

При активации поля курсор должен находиться на первом слоте. Иначе можно ввести клиента в заблуждение.

Пример ❌ Sokolov

Текущий слот выделяется

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

Пример ✅ Бристоль

Видимость выделенных символов

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

Пример Poison Drop

Автоматическая проверка

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

Пример ✅ Спортмастер

Согласие на обработку данных?

Как считаете, есть ли смысл размещать согласие на обработку персональных данных именно при вводе кода?

Пример ЦУМ

Сообщение о безопасности?

Как считаете, стоит ли в интерфейсе ввода кода сообщать о том, чтобы клиент никому его не сообщал? Важный момент или перебор?

Пример Burger King

Возврат через кнопку «назад»

Предусмотрите возможность вернуться с шага ввода кода к экрану ввода номера телефона. Чаще всего это реализуется за счёт кнопки «назад».

Пример ✅ BUNGLY

Возврат через edge swipe

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

Пример ✅ Утконос

Возврат через кнопку смены номера

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

Пример ✅ igooods

Валидация и обработка ошибочного ввода

34 гайдлайна

Проверка кода осуществляется

Базовый момент: проверка кода должна осуществляться корректно. У всех она работает? Нет, не у всех.

Пример ❌ Respect

Скорость проверки кода

Проверка должна осуществляться моментально, без какой-либо значимой задержки для клиента.

Пример ✅ Яндекс.Еда

Анимация во время проверки

Если проверка всё же занимает какое-то время, ожидание можно скрасить ненавязчивой анимацией.

Пример ✅ KDV Online

Без сбоев в процессе авторизации

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

Пример ❌ INCITY

Сообщение об ошибке присутствует

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

Пример ❌ Впрок

Цветовая индикация ошибки

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

Пример ❌ Sokolov

Highlight поля

Первый пример цветовой индикации — выделение поля ввода красным цветом. Чаще всего выделяется обводка.

Пример ✅ Burger King

Highlight символов

Можно подсвечивать и сами символы. Это позволит привлечь внимание к выделенным данным.

Пример ✅ Яндекс.Еда

Highlight текста ошибки

Часто встречающаяся практика — выделить сообщение об ошибке красным цветом, привлекая внимание именно к нему.

Пример ✅ FlowWow

Иконка в сообщении об ошибке

Часть клиентов могут не различать цвета. В этом случае помочь привлечь внимание может небольшая иконка, добавленная в сообщение.

Пример ✅ Бристоль

Иконка релевантна контексту

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

Пример ❌ BUNGLY

Изменение иллюстрации

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

Пример ✅ Ярче Плюс

Анимация ошибки

Восприятие также можно улучшить, дополнив изменение цвета анимацией. Например, дрожанием символов.

Пример ✅ SUNLIGHT

Констатация факта ошибки

Первое, что должно быть в сообщении — констатация факта, что произошла ошибка.

Пример ✅ O’STIN

Конкретизация проблемы

Не стоит делать текст слишком общим. Вместо того, чтобы сказать, что «что-то пошло не так», уточните, в чём именно заключается проблема.

Пример ❌ Novex

Призыв к действию

Помимо того, чтобы просто констатировать факт ошибки, клиенту можно предложить её решение, подсказав, как её скорректировать.

Пример ✅ МегаМаркет

На языке клиента

Убедитесь, что сообщение отображается на том же языке, что и остальной интерфейс приложения. Иначе это может вызвать проблемы с восприятием.

Пример ❌ Линии любви

Текст понятен широкому кругу клиентов

Используйте общепринятые формулировки. Предложение «Введён некорректный код» будет понятно более широкому кругу клиентов, чем «не валидные данные».

Пример ❌ IDOL

Соответствует Tone-of-Voice сервиса

Сообщение об ошибке в коде должно соответствовать тональности всего сервиса. Если вы в целом общаетесь с клиентом на «ты», то и здесь можно покреативить.

Пример ✅ Достаевский

Без системного текста

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

Пример ❌ Золото 585

Широкий спектр ошибок

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

Пример ✅ Сантехника-Онлайн

Текст ошибки рядом с полем ввода

Если текст ошибки — часть основного экрана, лучше разместить его рядом с полем, в котором она допущена.

Пример ❌ Акушерство

Текст ошибки не прилипает к полю

При этом не стоит располагать текст максимально близко к полю ввода — так, что он начинает визуально «прилипать» к нему.

Пример ❌ Cozy Home

Текст ошибки не дублируется

Как считаете, уместно ли дублировать текст ошибки в рамках одного экрана. Я считаю, что нет, но рад буду услышать ваше мнение.

Пример ❌ СберМаркет

Текст ошибки легко читается

Убедитесь, что текст ошибки располагается на однотонном контрастном фоне и выполнен в достаточно большом размере шрифта, чтобы облегчить восприятие при чтении.

Пример ❌ Flor2U

Фокус на поле ввода при ошибке

При ошибочном вводе поле не должно деактивироваться: лучше, если у клиента будет возможность сразу продолжить ввод.

Пример ❌ Азбука Вкуса

Очистка поля ввода при ошибке

В отличие от номера телефона, поле ввода кода в случае ошибки лучше очищать. Особенно если символы скрыты.

Пример ❌ ADAMAS

Кнопка очистки поля?

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

Пример Cozy Home

Текст ошибки исчезает при начале корректировки

После того как некорректные данные уже стерты, и клиент начал ввод нового кода, текст ошибки лучше скрывать, чтобы не вводить его в заблуждение.

Пример ✅ Эльдорадо

Ошибка исчезает со временем

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

Пример ✅ Бетховен

Визуальный таймер исчезновения ошибки

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

Пример ✅ igooods

Сообщение не блокирует экран

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

Пример ✅ BUNGLY

Сообщение не требует лишних действий

Более того, сообщение об ошибке не должно вынуждать клиента совершать лишние действия и требовать закрытия.

Пример ❌ Бронницкий Ювелир

Количество оставшихся попыток?

Некоторые сервисы в случае ошибки подсвечивают, сколько у клиента осталось попыток. Как считаете, это больше плюс, чем минус или наоборот?

Пример Мой SPAR

Повторная отправка кода

15 гайдлайнов

Возможность предусмотрена

Если клиент по какой-то причине не получил SMS с кодом, дайте ему возможность запросить повторную отправку.

Пример ✅ Wildberries

Функция визуально вторична

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

Пример ✅ SimpleWine

Текст корректен

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

Пример ❌ М.Видео

Длительность таймера

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

Пример ❌ Галамарт

Таймер работает всегда

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

Пример ✅ Мой Ашан

Визуализация таймера

Таймер в текстовом формате также можно визуализировать. Это позволит улучшить восприятие.

Пример ✅ Азбука Вкуса

Контакты поддержки

Если клиент повторно запрашивает SMS, а оно всё не приходит, не стоит оставлять его с проблемой один-на-один: дайте ему возможность связаться с поддержкой.

Пример ✅ Азбука Вкуса

Часы работы поддержки

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

Пример ✅ O’STIN

Поддержка в контуре приложения

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

Пример ✅ ВкусВилл

Видимость кнопки повторной отправки

Раз уж на кнопку повторной отправки во время ожидания таймера нельзя нажать, можно её и не отображать. Это позволит разгрузить интерфейс.

Пример ✅ Сантехника-Онлайн

Таймер в кнопке

Если кнопка всё же отображается, её можно объединить с таймером. Это позволит оптимизировать пространство.

Пример ✅ МегаМаркет

Таймер не оторван от текста

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

Пример ❌ Кофемания

Highlight таймера

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

Пример ✅ КуулКлевер

Формат таймера при длительном сроке

Если таймер обнуляется в течение нескольких минут, лучше реализовать его в формате мм:сс. Ожидать 4:59 субъективно менее болезненно, чем 299 секунд.

Пример ❌ Улыбка Радуги

Повторная отправка в WhatsApp

Если sms по каким-то причинам не приходит, некоторые сервисы также позволяют клиенту запросить код через WhatsApp. Это повышает шансы на успешную авторизацию.

Пример ✅ Ecomarket

To be continued…

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

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

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

Поделиться
Отправить
Запинить

Обсуждение