Как мы проектировали идеальный пользовательский опыт для OTP-поля

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

Меня зовут Антонина, я дизайнер интерфейсов ЮMoney. Мы изучили десятки исследований — от Baymard Institute до Google web.dev. Единого документа с лучшими практиками не нашлось: источники противоречили друг другу или оказывались слишком общими.

Тогда мы провели собственное исследование: сопоставили авторитетные материалы, разобрали реальные кейсы и сформулировали практические рекомендации. В этой статье разберём самые распространённые проблемы проектирования OTP-полей — от базовых до менее очевидных, — объясним, почему те или иные решения работают и к чему приводят ошибки. А в конце соберём все рекомендации в удобный чек-лист, который поможет быстро проверить ваше решение.

Что такое OTP-поле и в чём его особенности

OTP (One-Time Password) — одноразовый код из 4–6 цифр. В отличие от обычного поля ввода, оно имеет фиксированную длину, принимает только определённые символы и действует ограниченное время. Любая ошибка в интерфейсе здесь критична: пользователь теряет время, раздражается и может отказаться от действия.

Лучшая практика — автоподстановка

Идеальный сценарий — когда код вообще не нужно вводить. Современные браузеры умеют автоматически подставлять OTP из смс или push-уведомлений. Достаточно добавить атрибут: autocomplete=»one-time-code».

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

Общие рекомендации для OTP-полей

На основе анализа авторитетных источников выделили ключевые рекомендации.

Одно поле или несколько ячеек? Главный вопрос при проектировании OTP.

Сравнили одно поля ввода (Single Input) и отдельные ячейки (Segmented): плюсы и минусы подходов.

Single Input (одно поле)

Segmented (отдельные ячейки)

Рекомендации:

• Веб-приложения: одно поле, стилизованное под ячейки с помощью CSS — проще и надёжнее.

• Нативные мобильные приложения: сегментированные поля благодаря их наглядности.

• Мобильный веб и PWA: универсального решения нет — выбор зависит от аудитории и требований к доступности.

Автофокус

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

Корректная вставка кода

При копировании кода из смс система должна вставлять его с первой ячейки независимо от положения курсора. Это предотвращает пропуски и соответствует рекомендациям Google, Apple и UX-исследований.

Подпись к полю

Используйте постоянную подсказку (hint) вместо плейсхолдера. Плейсхолдер исчезает при вводе, и пользователь может забыть формат. Пример: «Введите 4-значный код из смс».

Доступность (a11y)

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

Что важно учитывать:

• Активное поле чётко выделено цветом, обводкой и контрастом.

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

• Сообщения об ошибках заметны и содержат инструкции по исправлению.

• Навигация с клавиатуры логична и предсказуема.

• Форма протестирована со скринридерами (VoiceOver, NVDA, TalkBack).

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

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

Кнопка повторной отправки и таймер — ключевые элементы OTP-формы. Рекомендации:

• Таймер отображает время до повторной отправки: «Новый код через 30 сек».

• По истечении времени активируется кнопка с текстом «Получить новый код в смс».

• При нажатии на кнопку поле очищается — ввод начинается заново (работает при неполном вводе и при ошибке).

• Добавьте информацию «Почему смс не приходит?» — это снижает раздражение пользователя.

Пример блока повторной отправки:

Пример запроса нового кода при ошибке:

Редактирование номера телефона

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

Рекомендация: всегда давайте возможность легко вернуться назад и исправить номер. Лучше реализовать это как активную ссылку или кнопку на экране ввода кода — например, «Изменить номер» или «Не тот номер?». Это снижает раздражение, когда код не приходит, и предотвращает отток пользователей. 

Запрет пропуска ячеек при быстром наборе

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

Рекомендация: используйте события input или keyup вместо change — это обеспечит корректное переключение фокуса при любой скорости набора.

Обработка ошибок

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

Когда убирать сообщение об ошибке

• При исправлении до валидного состояния — немедленно. Это ключевой принцип, подтверждённый исследованиями Baymard Institute. Если ошибка остаётся после корректного ввода, пользователь не понимает, решена ли проблема.

• При начале ввода или удалении символа — сообщение должно исчезать. Даже если поле ещё не исправлено полностью, это даёт понять, что система «слышит» пользователя и готова помочь.

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

Нужно ли очищать поле при неверном коде?

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

Автоотправка

Для 4–6-значных кодов большинство интерфейсов используют автоотправку после ввода всех цифр. Это ускоряет процесс, но создаёт риск преждевременной отправки при исправлении ошибки.

Решение: debounce (задержка) 500–800 мс после последнего ввода — это даёт время на исправление.

Фокус при ошибке

При ошибке в OTP-поле возможны два подхода:

• Фокус остаётся на текущей позиции — минимальное вмешательство в действия пользователя (используется реже).

• Фокус на последней ячейке — удобно начинать исправление с конца (самый распространённый вариант).

Главное правило: при любом подходе сохраняйте свободу перемещения между ячейками — клик, стрелки, Tab. Жёсткие блокировки и принудительное перенаправление только раздражают. Лучше мягко направлять, но не запрещать.

Выводы и практические советы

На основе исследования и анализа авторитетных источников мы сформулировали ключевые принципы проектирования OTP-поля.

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

Чек-лист: проектирование OTP-поля

На основе исследований мы составили краткий чек-лист для проектирования и ревью OTP-форм.

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